►
From YouTube: Intern Presentation: Rust Typeclasses
Description
Lindsey Kuper from the Research team presents “Rust Typeclasses Turn Trait-er.”
Help us caption & translate this video!
http://amara.org/v/2FhI/
A
All
right
so
hello,
my
name
is
Lindsay
Cooper
and
I
am
a
PhD
student
in
the
programming
languages
group
at
Indiana,
University
and
I'm
also
an
intern
on
the
rest
team.
Here
at
his
own
research
and
I'm,
going
to
be
telling
you
about
my
work
on
the
rest
type
class
system
and
the
work
I've
done,
extending
the
tech
class
system
to
a
trait
system.
So
when
I
started
this
project,
I
didn't
really
know
what
type
classes
or
traits
were
and
I
suspect
that
some
of
us
are
in
the
same
situation.
A
So
what
I'm
going
to
do
in
this
talk
is
cover
both
of
those
notions
and
then
we'll
take
a
look
at
how
they
manifest
and
rust.
So,
first
of
all,
a
few
words
about
rest.
So
if
you're
unfamiliar
with
rust,
which
this
room
I
see
in
the
audience,
is
mostly
rust,
interns
and
full
timers.
But
hopefully
there
are
some
people
listening
to
art.
A
I
would
say
it
feels
kind
of
like
si
would
feel
if
it
had
strong
typing
pattern,
matching
type
inference
and
a
lot
of
features
that
encourage
modularity
and
higher
River
programming
and
you'll
see
some
of
what
I
mean
by
that
in
a
minute,
but
all
that's
really
kind
of
just
the
beginning,
and
there
will
be
more
talks
from
the
other
interns
in
the
coming
days
about
some
of
the
other
parts
of
the
language.
But
the
part
I'm
going
to
talk
about
is
one
of
those
modularity
encouraging
features,
which
is
the
type
class
system.
A
So,
first
of
all,
what
our
type
costs
so
type
classes
are
an
idea
that,
as
far
as
I
know
originally
came
from
Haskell
and
the
bog-standard
example
that
everyone
always
uses
to
explain
type
classes
is
what's
called
an
EQ
equality
type.
So
what
I'm
going
to
do
here
is
show
some
code
and
rust
and
explain
it
and
then
we'll
see
how
it
looks
in
comparison
to
Haskell,
so
Russ
just
had
a
basic
type
class
system.
A
Since
the
0.1
release,
which
came
out
in
January
and
this
code
bit
I'm
going
to
show
here,
runs
under
0.3,
which
is
the
most
recent
release.
It
also
runs
against
the
head
of
the
tree,
modulus
and
syntax
changes,
and
if
you
want
to
see
what
it
looks
like
with
those
changes,
it's
in
our
test
suite
on
github-
and
it
can
put
you
to
that
liquor
so
rust
as
when
I
showed
up
this
spring
on
interface
and
I
face
was
just
a
collection
of
method
signatures.
A
So
what
we
have
here
is
an
interface
called
equal
and
it
has
an
is
EQ
method.
I'm,
sorry,
the
small
that
we
apply
to
some
value
and
some
other
argument,
and
we
get
back
a
boolean
value
telling
us
if
they're
equal.
So
we
also
have
an
implementation
of
the
equal
I
face
here.
So
I
have
an
enum
type
called
color
with
four
variants:
cyan,
magenta,
yellow
and
black,
and
if
we
want
to
implement,
is
EQ
for
that
type
to
see.
A
If
two
things
are
the
same,
you
just
check
that
they're
the
same
variant
and,
incidentally,
the
shows
off
how
pattern
matching
works
in
rest.
So
perhaps
more
interestingly,
we
can
also
divide
another
type,
a
color
tree,
that's
the
type
of
binary
trees
of
colors
and
and
then
to
write,
is
EQ
for
color
trees.
Well,
if
they're
both
leaves,
then
we
call
is
EQ
on
the
colors
and
leaves
and
if
they're,
both
branches,
that
we
call
is
EQ
on
the
sub
trees
and
in
the
implementation
of
the
equal
interface
for
color
trade
notice.
A
That,
although
like
we're
making
three
calls
to
the
is
EQ
method,
they
aren't
all
the
same
method.
The
X
dot
is
EQ
y
is,
is
a
call
to
the
one
that
we
have
implemented
earlier
and
the
other
two
are
recursive
calls.
So
if
it
is,
EQ
method
is
essentially
being
statically,
overloaded
and
then
finally,
there's
a
case
at
the
bottom,
where,
if,
if
we
have
a
leaf
and
a
branch
or
a
branch,
a
leaf
that
we're
trying
to
compare
well
clearly,
those
two
are
not
equal.
A
So
in
that
case
we
can
just
return
false,
and
here
are
a
bunch
of
examples
of
calls
to
is
EQ.
So
I
said,
I
was
going
to
compare
this
code
to
Haskell.
So
let's
take
a
look
at
how
similar
they
are
so
in
high
school.
You
could
write
using
the
class
keyword.
You
could
write,
what's
called
a
type
class,
and
here
we
have
a
type
class
with
an
easy
Q
method.
A
We
have
an
an
enum
datatype
khokana
and
we
have
an
implementation
of
the
equal
type
class,
looks
a
lot
like
rest
and
then,
similarly,
we
can
do
the
same
for
the
color
tree
type
and
in
fact
these
will
look
even
more
similar
in
the
rest
of
today,
because
I
think,
just
as
of
yesterday,
you
can
have
so-called
static
methods
and
rest,
which
means
that
you
could
call
them
in
something
that
looks
more
like
easy,
Q,
X,
comma
Y,
instead
of
the
X
dot,
is
EQ
of
Y
that
we
have
here.
Oh
so,
okay.
A
So
this
is
all
fine
and
good,
but
none
of
the
code
that
we've
written
so
far
really
takes
advantage
of
what
I
think
is
one
of
the
most
awesome
things
about
type
clasts,
which
is
the
following.
So
once
you've
gone
and
defined
as
EQ
for
these
different
types.
Well,
what
we
ought
to
be
able
to
do
now
is
have
other
methods
that
are
defined
in
terms
of
the
one
who
we
already
defined.
A
But
the
thing
that
I
just
did
in
Haskell.
This
has
not
been
possible
in
Russ
up
until
now,
so
what
I
have
been
working
on
is
making
it
possible
any
questions
so
far,
all
right,
one
aside,
is
that
you
could
argue
that
this
would
be
an
inefficient
way
to
implement
dis
equality
and
you'd
be
right,
but
there
fancier
examples
where
this
would
work.
For
instance,
in
the
rest
type
inference
engine,
we
have
an
interface
that
has
something
like
12
or
15
methods
and
the
end.
A
There
are
three
implementations
of
this
interface
and
all
three
implementations
are
required
to
implement
all
of
the
methods
in
the
interface,
even
though
most
of
them
are
the
same
in
two
or
even
all
three
of
these
limitations.
So
we
end
up
with
a
lot
of
copy-paste
code
and
that's
never
good,
okay,
so
stepping
aside
from
a
type
klutzes
for
a
moment,
look
look
at
traits.
A
So
when
I
shut
up
the
muzzle
of
the
summer,
I
thought
I
was
going
to
work
on
implementing
an
as-yet
unimplemented
piece
of
the
object
system
called
traits
and
I'll
illustrate
this
through
an
example
too.
So
the
idea
of
traits
has
been
around
for
I
guess
about
ten
years
and
I'll
give
a
reference
at
the
end
of
the
talk,
but
a
trait
as
edit
simplest
is
just
a
collection
of
methods,
possibly
also
fields,
and
they
come
in
two
flavors
that
provided
and
required.
A
A
What
to
take
note
of
here
is
that
the
puppy
class
derives
from
both
the
playful
and
hungry
traits
and
the
order
of
those
two
doesn't
matter
it
could
derive
from
those
in
either
order.
So
we
could
have
said
that
puppy
draws
from
hungry
and
then
playful
and
that's
crucial,
that
traits
are
composable
and
that
order
doesn't
matter
and
if
there's
a
conflict
between
the
two
like,
if
they
both
implement
a
method
with
the
same
name,
then
one
of
the
design
principles
of
traits
is
that
the
conflict
has
to
be
explicitly
resolved
in
some
way.
A
A
We
made
an
interesting
observation,
which
is
that
the
provided
methods
that
that
traits
have
are
analogous
to
the
default
methods
and
type
classes
and
that
required
methods
and
traits
are
analogous
to
what
we
had
in
interface
is
already
just
methods
that
are
just
signatures.
When
I
would
a
default
implementation,
and
we
were
really
excited
when
we
realize
this,
because
we've
been
thinking
for
a
while,
that
we
were
going
to
implement
trains.
A
But
we
thought
that
traits
and
interfaces
were
different
things,
or
at
least
they
were
different
things
in
previous
proposal
and
unifying
them
was
great,
because
not
only
did
it
mean
less
code
in
the
compiler,
but
it's
one
fewer
thing
for
our
users
to
have
to
learn.
So
the
plan
became
that
we
were
going
to
add
default
methods.
Interfaces
we'd
be
renamed
to
traits
it's
a
very
convenient
renaming
to
do,
because
it's
just
five
characters
and
Noorie
indented
required,
and
that's
why
the
title
of
this
talk
is
type
classes
turned
traitor.
A
B
A
Composition
and
implementation
coherence-
and
this
talk
has
just
been
focusing
on
default
methods,
but
if
you
want
to
learn
about
the
rest,
I'm
about
to
show
you
where
to
go
to
learn
more
so
some
references
for
type
classes,
there
are
a
couple
of
things
you
can
look
at
the
high
school
tutorial.
Has
a
nice
section
on
them.
The
real
world
haskell
book
has
a
chapter
that
I
borrowed
my
color
example
from
here
four
traits.
A
The
original
paper
on
traits
is
this
2003
paper
called
traits,
composable
units
of
behavior
and
and
then
in
terms
of
bringing
traits
and
type
classes
together
or
bringing
traits
and
interfaces
together.
What
you
should
know
about
is
in
rest.
We
have
some
stuff
on
the
development
roadmap
on
our
wiki,
particularly
there's
a
section
called
assistant
changes.
There's
my
proposal,
which
is
currently
being
implemented,
and
it's
in
progress
and
Patrick
did
a
blog
post
yesterday
called
the
gentle
introduction
to
traits
in
rust,
which
is
pretty
good,
and
this
is
on
the
way.
A
A
I
I
think
that
rest
is
more
grown-up,
as
the
language
as
you
might
expect,
but
one
really
cool
thing
is
that
there's
been
a
huge
up
spooning
in
community
participation
so
like,
for
instance,
last
year
we
had
about
40
people
in
our
IRC
channel
at
a
given
time.
Now
we
have
about
100
and
people
seem
to
be
really
excited
about
trades
and
we're
constantly
fielding
questions
from
people
about
whether
your.
B
C
B
A
A
Aside
from
that,
though,
I
guess
traits
are
interesting,
because
although
they
do
have
a
relationship
that
you
might
think
of
as
kind
of
like
a
subtyping
hierarchy,
they
are
tight.
So
the
the
kind
of
reuse
you
guys
like
there,
you
have
a
different
component
of
reuse
and
then
you
do
with
with
subtyping
here
so
fast.
C
A
So
the
concepts
first
Muslim,
P
plus
plus,
is
was
was
dramatically
shot
down
and
concepts
are
still
being
discussed.
There
is
sort
of
like
competing
factions
and
the
only
reason
I
know
about
this
is
because
one
of
the
competing
factions
happened
to
be
at
my
school.
So
but
I
I,
don't
know
too
much
about
the
concepts
proposal,
but
I
know
that
it's
not
in
the
language
officially.
A
A
C
C
What
I
do
is
I
write,
so
you
would
your
first.
Try
might
be
something
like
to
find
a
function
that
takes
a
T
and
call
T
dot
play
and
that
works
in
C++,
but
it
doesn't
work
in
rest
because
we
don't
we
type
check
templates
at
the
time
you
you
write
them
not
the
time
you
instantiate
them
so,
but
what
you
can
do
is
you
can
say:
okay,
I,
take
a
T
and
T
must
be
playful
and
then
I
can
call
dot
play.
C
A
A
Any
conflicts
have
to
be
resolved
explicitly,
so
you
won't
run
into
problems
with
not
necessarily
knowing
which
implementation
you're
going
to
be
running
until
runtime
in
rust.
Right
now,
we
don't
so
right
now
you
would
get
an
error
if
you
tried
to
compose
two
traits
and
they
had.
He
had
the
same
name.
Eventually,
we
would
like
to
have
some
well.
This
is
up
for
debate
actually,
but
one
thing
that
we
might
like
to
have
I'll
put
it.
A
That
way
is
some
kind
of
mechanism
for
fancier
conflict
resolution
and
we'll
see
if
we
need
it
we'll
get
there.
I
guess.
One
thing
that
comes
to
mind
is
that
a
lot
of
people
write
C++
for
their
whole
careers
without
ever
having
to
do
multiple
inheritance.
So
this
might
be
one
of
those
you
ain't
gonna,
need
it
things,
but
we'll
see
we'll
have
to
find
out
great
other
questions.