►
Description
Ben Blum from the Research team presents "Types of Types in Rust" from 10 Forward
Help us caption & translate this video!
http://amara.org/v/2FhS/
A
Hi
everybody,
my
name,
is
Ben
Blum
I
was
an
intern
on
the
rust
team.
This
summer
and
I
did
a
bunch
of
assorted
work,
some
of
it
on
the
type
system
and
some
of
it
on
the
runtime
and
today
I'm
going
to
talk
to
you
about
the
type
system,
because
the
work
I
did
on
that
is
a
little
bit.
Flashy
er,
as
you
can
see,
the
presentation
is
called
types
of
types
in
rust
and
I
will
soon
explain
what
that
means.
A
So,
first
I'm
going
to
give
a
little
overview
of
what
types
of
types
also
known
as
kinds
are
in
rust.
I'm
going
to
talk
about
how
they
interact
with
traits,
which
is
our
interface
type
class,
object
everything
that
is
great
in
one
package,
part
of
our
type
system
and
then
I'm
going
to
get
a
little
more
focused
and
talk
about
how
they
can
be
used
as
existential
types
and
the
work
that
I
did
to
make
them
a
little
friendlier
with
our
kinds.
A
Then
I'll
talk
about
the
specific
stuff
that
I
did
and
I'll
give
some
motivation
and
tell
you
why
it's
great,
and
instead
of
just
not
wanting
to
do
it
at
all,
why
I
did
want
to
do
it
anyway,
so
before
I
get
started,
I
will
make
an
announcement,
which
is
that
we
have
a
new
runtime
and
it
is
written
in
rust.
I
remember
getting
here
last
summer,
starting
to
work
on
the
C++
runtime
and
noticing
that
our
compiler
was
written
in
rust.
So
well,
why
don't
we
just
switch
over?
It
is
to
rust.
A
Well,
that
would
be
a
lot
of
work.
So
I,
just
you
know,
did
a
bunch
of
C++
work
last
summer,
but
now
it's
really
exciting,
because
not
only
are
we
self
hosted
in
the
compiler,
but
also
in
the
runtime
I
spent
a
bunch
of
weeks
doing
runtime
work,
but,
as
I
said,
it
wasn't
very
flashy
and
it
was
basically
just
implementing
behind
the
scenes
plumbing
to
make
the
stuff
that
I
implemented
last
summer
still
work
on
the
new
runtime.
A
A
A
A
Then
it
satisfies
the
freeze
kind,
which
means
that,
as
long
as
it's
stored
in
an
immutable
location,
the
entire
thing
is
immutable.
You
can't
mutate
any
part
of
it.
There's
this
static
kind,
which
is
reasoning
about
the
lifetime
of
certain
data,
meaning
that
it
will
never
go
out
of
scope,
for
example,
a
pointer
to
something
that
lives
on
a
stack
frame
or
a
garbage-collected
pointer,
doesn't
fulfill
the
static
lifetime.
A
Only
sort
of
global,
constant
values
can
fulfill
the
static
lifetime,
there's
also
the
copy
kind,
which
means
you
can
implicitly
copy
the
stuff
like
owned
pointers,
because
to
copy
those
would
require
a
deep
traversal
of
the
entire
type
and
copying
the
whole
thing
that
doesn't
satisfy
copy
but
stuff,
like
you
know,
integer
or
garbage-collected
pointers.
Those
are
fine
to
copy.
A
Actually,
the
copy
kind
is
dead,
long
live
the
clone
kind,
but
for
the
sake
of
this
presentation,
assuming
that
the
copy
kind
still
exists
will
make
explaining
some
things
easier,
so
I'm,
assuming
that
it
still
exists
all
right.
So
the
nice
thing
about
kind
bounds
is
usually
you
don't
have
to
worry
about
them,
they're
automatically
derived
by
the
compiler.
So
if
you
write
a
type
such
as
an
option
of
a
T,
the
compiler
automatically
derives.
Oh,
do
you
want
to
satisfy
some
kind
K
with
this
option
of
T?
A
So
how
are
they
used
here?
Are
some
examples
to
get
them
into
your
heads,
I
mentioned
message
passing
and
send
are
linked
in
fact,
message.
The
message
passing
interface
explicitly
uses
the
send
kind,
because
the
message
passing
has
you
know,
unsafe
internals
putting
send
on
the
interface
is
sort
of
the
glue
that
makes
it
all
safe
on
the
outside,
safe
to
the
users.
So
if
you
want
to
do
message
passing
this
is
the
basic
interface,
you
have
a
function
which
will
give
you
a
stream
which
is
a
pair
of
a
port
and
a
channel.
A
A
So,
yes,
the
send
bound
ensures
that
once
one
task
sends
data
on
a
channel,
that's
data
:
T
there
on
the
bottom
line.
That
task
is
no
longer
allowed
to
access
it.
The
only
task
that
you
will
be
able
to
access
it
as
the
receiver.
In
effect,
it
means
the
sender
is
giving
up
ownership
of
the
data
now
on
to
the
freeze
kind.
A
This
is
useful
for
an
interface
which
allows
you
to
share
state
between
tasks,
because
if
you
only
have
message
passing,
you
might
have
to
copy
large
vectors
of
things
more
times
than
you
know.
You
have
computational
power,
for
you
might
instead
want
to
share
stuff.
We
allow
you
to
share
stuff
as
long
as
it
you
can
reason
about
it
being
immutable,
so
we
have
a
type
called
arc
which
stands
for
atomically
reference
counted
rapper
and
you
can
put
stuff
in
an
arc
as
long
as
it
satisfies
both
the
send
bound
and
the
freeze
ban.
A
A
Thanks
to
the
two
kind
bounds
send
ensures
that
once
you
construct
an
arc,
the
only
way
to
access
the
data
is
through
the
handle
and
the
freeze
bound
ensures
that
when
you're
sharing
it
across
tasks,
nobody
is
ever
able
allowed
to
mutate
it,
which
would
cause
data
races
and
crashes
and
seg
faults,
and
so
on
and
security
vulnerabilities.
We
don't
want
that.
A
A
A
A
So
you
can
use
this
generic
pet
object
as
though
it
were
a
pet.
You
can
get
its
name.
You
can
get
its
number
of
legs.
You
can
ask
if
it's
well-behaved,
but
you
can't
do
dog
specific
things
with
the
generic
pet.
That
would
be
wrong
when
you
do
this.
It
generates
a
virtual
table
of
function,
calls
on
the
spot
for
the
generic
pet
value.
A
So,
in
back
to
type
theory
lingo
for
a
moment
this
is
an
existential
type,
it
means
sort
of
an
opaque
type
that
presents
a
generic
interface
and
in
really
formal
type
theory
lingo
it
is
pronounced.
There
exists
some
X
of
type
T
such
that
some
interface
of
X,
again
object
or
any
programmers
will
be
familiar
with
this
as
just
treating
an
interface
as
an
object
which,
in
C++
always
generates
a
V
table.
A
I'll
take
a
moment
to
point
out
that
closures
in
rust
are
sort
of
a
special
case
of
trade
objects.
The
value
of
a
closure
is
the
environment.
That
is
the
values
that
are
captured
in
the
closure
and
V
trait
for
a
closure
would
if
it
existed,
looks
something
like
this.
There
is
one
function
and
it
is
called
it
takes
some
arguments
and
it
returns
a
value.
A
So
everything
that
you
can
do
with
traits
that
I'm
talking
about
in
this
presentation,
you
can
also
do
with
closures
but
I'm
going
to
focus
on
traits,
because
closures
are
just
a
special
case,
so
I'm
not
going
to
bother
to
present
what
it
would
look
like
for
closures,
also
in
rust.
A
key
thing
about
traits
trait
objects,
that
is,
is
that
they're
dynamically
sized
when
you
create
a
trait
you
generate
a
virtual
table
of
function,
calls,
and
you
also
have
the
the
value
next
to
it,
a
dog,
but
you
might
also
have
a
generic
pet.
A
That's
a
bird
and
while
the
bird
is
smaller
than
a
dog,
so
the
the
trait
object
for
a
bird
would
take
up
less
space
in
memory
than
a
dog.
So
if
you
want
to
carry
around
these
traits
in
rust,
you
have
to
hide
them
behind
a
pointer.
You
a
bear.
Trait
itself
is
not
a
type
so
like.
In
the
previous
slide,
I
wrote,
ampersand
pointer
to
Alan
Turing
as
pointer
to
pet
you're,
not
allowed
to
do
that
without
the
ampersand
and
I'll
continue
to
do
it
in
the
rest
of
this
talk.
A
Okay,
so
now,
let's
talk
about
what's
contained
inside
opaque
object
types.
First,
before
I
happened
to
it
this
summer
there
were
some
defaults
and
you
couldn't
really
budge
them.
You
had
to
use
them
as
they
were.
If
you're,
using
an
owned
pointer
to
a
trait
object,
it
can
only
contain
send
able
values,
and
this
with
this
is
what
enabled
you
to
send
opaque
traits
between
tasks.
A
A
A
And
I
fixed
it
with
a
mechanism
that
is
called
kind
bounds
like
putting
kind
bounds
on
a
type
parameter
to
a
function
which
I
presented
earlier
in
the
message
passing
interface
and
so
on.
Now
you
can
also
put
kind
bounds
on
a
trait
on
a
type
itself.
So,
thanks
to
me,
if
you
want
to
reason
about
the
stuff
that's
contained
inside,
of
an
opaque
trait,
you
can
write
the
name
of
the
trait
type
called
tilde
pet
colon.
A
A
Likewise,
this
the
analogous
restrictions
and
capabilities
apply
for
the
other
built-in
kinds,
all
right
so
I'm
going
to
make
a
non
copyable,
Alan,
Turing
and
I'm
going
to
assume
that
the
stuff
inside
the
dog
initializer
is
a
non
copyable
which
makes
him
non
copyable.
So
this
is
on
the
second
line.
I
have
the
same
cast
as
before,
a
generic
pet,
which
is
non
copyable
and
on
the
third
line,
I'm
trying
to
make
a
copy
of
a
pet
out
of
non
copyable
alan
turing,
and
now
the
compiler
will
give
an
error.
A
That
says,
cannot
capture
non
copyable
value
in
trait
bounded
by
copy,
because
I
tried
to
violate
the
restriction
imposed
by
the
bound
okay.
So
what
is
this
good
for?
This?
Is
the
motivation
slide
and
if
you
take
one
thing
away
from
this
presentation,
I
would
like
it
to
be
this
bolded
bullet
point,
which
is
that
now,
thanks
to
the
thanks
to
the
various
concurrent
data
structures
we
already
have,
you
can
now
match
up
kind
bounds
on
your
trait
objects,
with
kind
bounds
required
by
are
required
by
our
concurrent
data
structure
interfaces.
A
A
So
I
have
a
Alan
Turing,
which
is
a
dog
I,
have
Ada
Lovelace,
which
is
a
cat,
and
I
have
Albert
Einstein,
which
is
a
bird
and
presumably
they
all
have
their
own
numbers
of
legs
and
their
own
well
behaved
admitting
and
now
I'm
going
to
put
them
in
a
list.
I'm
casting
each
of
the
three
of
them
to
a
pet
which
fulfills
both
the
send
and
the
freeze
bound
and
I'm,
assuming
that
in
the
construction
of
them
they
fulfilled
that
bound.
A
So
now,
I
have
a
list
and
since
on
type
on
primitive
types,
like
list
kind,
bounds
are
automatically
derived.
We
know
the
whole
list
satisfies,
send
and
freeze
so
now,
I
can
pass
it
to
the
ARC
constructor
and
I
can
now
clone
the
arc
and
share
it
among
threads.
And
now
all
my
different
threads
are
sharing
handles
to
the
same
underlying
list
to
a
bunch
of
different
types
of
voila.
A
I
will
end
with
a
bit
of
perspective,
a
sort
of
about
rusts
mission
by
posing
the
question.
Well
can't
C++
already
do
this.
You
could
just
make
a
list
of
objects
which
you
can,
which
is
really
easy
in
C++,
store
that
in
a
global
location
or
whatever
and
spawn
off
a
bunch
of
threads
to
access
it,
so
I
don't
get
it
what's
so
great
about
being
able
to
do
it
and
rust
like
duh.
You
should
be
able
to
do
this,
and
my
answer
to
that
is
well.
A
A
So
what
this
really
means
is
that
we
are
rising
to
the
challenge
of
being
as
expressive
as
C++
in
certain
features
without
compromising
on
our
safety
guarantees,
in
this
case
no
data
races,
because
if
you
did
the
same
thing
in
C++,
there
would
be
nothing
to
statically,
prevent
you
know,
mutating
the
pets
giving
them
a
dog
treat
or
whatever,
while
other
well.
Other
tasks
were
accessing
them,
which
would
cause
security
vulnerabilities,
so
hooray,
we
have.
We
have
risen
to
the
challenge
and
I
think
that's
really
great.
A
I
would
like
to
thank
certain
people,
first
and
foremost
in
no
particular
order
well
in
alphabetical
order.
I
will
thank
Brian
Anderson
and
also
applaud
him
on
the
heroic
effort
to
have
a
run
time
written
in
rust,
and
also
thank
him
for
the
guidance
that
he
provided
while
I
was
working
on
the
runtime
this
summer
and
next
I
will
thank
Nico
motoki's.
A
I
would
like
to
thank
the
other
interns
that
I
worked
with
for
their
heroic
efforts
on
the
run
time
and
servo.
Two
of
you
are
sitting
right
there.
More
of
you
are
sitting
right
there,
the
to
rust
ones
are
sitting
in
the
front
and
a
servo
one
in
the
back
and,
of
course,
the
rest
of
the
rust
team
for
being
a
great
community
and
for
being
really
supportive.
It's
really
a
pleasure
to
work
with
you
guys
and
I
hope
that
it
doesn't
end
here.
A
The
consequence,
however,
is
that
whenever
you
want
to
call
clone
on
something,
it's
not
just
something
that
the
compiler
can
automatically
generate
code
for
it
has
to
generate
a
call
to
perhaps
some
user
provided
stuff,
so
in
particular,
if
you
wanted
to
put
the
clone
bound
on
a
trait
or
on
a
closure
that
would
require
emitting
another
entry
in
the
V
table
for
clone,
and
we
don't
have
code
to
do
that.
Yet
we
want
to,
but
it's
hard
because
it
involves
more
code
generation.