►
Description
Rust’s type system provides tools to ensure safe memory management, and safe concurrent access to data. What if we used those same tools to encode and enforce other API constraints?
We can leverage affine types (non-Clone structs) to enforce that a user performs a series of operations in a certain order; or we can use structs as tokens representing the user’s ability to perform certain actions. And everything’s checked at compile time.
We’ll see how these techniques let us encode complex API constraints, and make them self-documenting by preventing disallowed behaviour at compile time.
About Andrea Lattuada:
I’m a PhD student and Research assistant in the Systems Group, Dept. of Computer Science at ETH Zürich. I have past industry experience with type-heavy programming languages and now work with Rust on safe, reliable, distributed data processing.
A
Hi
everyone,
thanks
for
the
introduction
and
yes
I-
am
the
laziest
in
the
sense
that
my
workplace
is
literally
across
the
street
from
here.
So
it's
like
two
minutes:
walk
I'm,
I'm,
Andrea
I
am
a
PhD
student
in
eight
months
now
at
the
Systems
Group
at
the
department
of
computer
science
at
ETH,
and
we
work.
We
rust
a
lot
in
the
group,
especially
in
my
part
of
the
group,
and
it's
been
a
really
really
good
experience.
It's
been
a
lot
of
fun.
A
This
talk
is
about
it
stemmed
from
my
master
thesis,
but
it's
intended
to
talk
more
about
how
we
can
leverage
the
type
system
to
make
as
more
confident
in
how
we
use
our
high-level
API.
So
we
know
that
rust
helps
us
in
making
sure
that
we
don't
make
mistake
when
managing
memory
or
when
we're
doing
concurrent
access.
But
can
we
use
those
tools
to
make
things
better
when
we
are
designing
api's?
A
And
this
is
the
point
we
have
an
API,
we
can
document
it
and
explain
how
we,
the
user,
should
approach
it,
but
we
know
we
can
also
try
and
see
if
we
can
make
sure
that
the
only
way
to
use
an
API
is
the
right
way
to
do
it.
So,
let's
look
at
a
bit
of
an
API,
we
may
want
to
send
a
letter
and
we
want
it
delivered
quick.
A
So
we
probably
ask
a
delivery
company,
so
we
ask
company,
they
send
us
delivery
lorry,
we
order
a
delivery
and
they
come
to
us
to
pick
up
our
letter.
We
of
course
have
a
letter
as
well.
The
letter
has
any
interesting
content
hopefully,
and
we
probably
want
to
put
it
in
an
envelope,
so
we
assume
that
we
have
a
way
to
getting
a
pre
stamped
envelope
for
our
letter.
So
we
take
a
letter.
We
fall
there
and
we
put
it
in
the
envelope
and
then
now
the
delivery
person
is
right
outside.
A
So
we
tell
them
yeah
we're
done.
We
close
the
envelope,
and
we
put
the
letter
in
the
in
Deloria
I-
was
wondering
whether
I
could
say
series
while
going
through.
All
of
this
and
I
didn't
really
manage
that
it's
very
good
so
and
then
we
said
we
tell
them
with.
We
don't
have
anything
else
for
you
and
the
driver
goes
on
their
way.
So
what
we're
doing
here
is,
of
course
this
is
a
representation
of
what
an
API
could
be.
A
We
have
a
series
of
steps
to
perform
to
achieve
a
certain
certain
result,
and
what
we're
doing,
if
you
squint
hard
enough,
is
that
we
are
managing
resources,
so
the
lorry
driver
was
waiting
for
us
is
a
resource.
We
have
a
short
amount
of
time
to
give
them
their
letter.
We
have
one
letter
because
we
wrote
it
by
hand
for
some
reason
and
and
then
we
also
have
one
envelope
which
we
ordered.
A
First
of
all,
we
have
a
function,
for
example
use
name,
they
take
the
string,
it
doesn't
take
a
reference.
So
when
we
call
this
function,
we
are
gonna
relinquish
ownership
over
the
string
and
then
when
we
call
this
function
with
our
string
name,
then,
because
we
are
giving
away
ownership,
then
if
you
try
to
compile
this
Russy
will
complain
will
say
you
gave
away
this
piece
of
data
you're
not
allowed
to
use
it
anymore.
A
A
So
drop
is
a
special
trait
that,
if
implemented
for
a
certain
structure,
will
get
invoked
just
before
the
piece
of
data
gets
dropped,
and
these
examples
are
slightly
contrived,
of
course,
we're
getting
some
data
from
somewhere,
and
then
we
have
an
if
statement
the
only
issue,
eliza's
data,
if
that
value
is
more
than
three
and
then
we
try
to
print
out.
This,
of
course,
doesn't
work
because
of
lexical
scoping.
But,
more
importantly,
once
the
piece
of
data
in
the.
If
statement
goes
out
of
scope
that
dr.
A
gets
dropped
and
that
memory
gets
the
okay,
so
we
have
a
way
to
manage
a
resource
and
make
sure
that
the
resource
we
are
holding
so
memory
gets
released
at
the
end.
So,
as
we
were
saying,
for
we
are
still
managing
resources,
even
in
higher
level
API.
So
if
you're
writing
an
API
to
send
a
letter,
we're
still
managing
resources,
it's
just
a
different
kind
of
resources.
It's
not
memory
anymore!
It's
the
time
of
the
driver,
it's
the
letter!
A
So
let's
try
and
model
that
ridiculous
API
from
before
as
Ross
code.
Pretty
simply
we
have
a
letter
that
contains
some
text.
Then
we
have
an
envelope
that
we
order
and
is
pre-stamped
and
optionally
contains
a
letter
once
we
put
it
in
in
the
letter
and
we
have
a
handle
to
our
lorry,
and
this
is
a
handle,
because
this
write,
this
lorry
could
be
a
shared
resource.
It
could
be
there
in
front
of
our
apartment,
building
waiting
for
multiple
people
to
give
their
mail
to
them.
A
So
implementation
wise.
We
can
start
with
just
a
way
to
make
a
letter
from
a
string
and
then
for
the
envelope.
We
need
a
couple
of
things.
We
need
a
way
to
put
the
letter
in
the
envelope
and
then
we
need
a
way
to
obtain
a
new
envelope.
That's
already
pre
stamped
the
handle.
We
need
again
all
of
things.
We
need
a
way
to
obtain
this
large
driver,
so
let
me
go
through
it
in
the
right
order.
So,
first
of
all
we
need
once
we
have
the
driver
there.
A
A
So
how
would
we
use
this
in
a
Maine
somewhere?
We
make
a
letter
dear
Rose.
First,
we
grab
an
envelope.
We
put
the
letter
in
the
envelope
we
order
Lori,
we
tell
the
driver
his
letter
and
then
with
we're
done
and
they
go.
So
what
could?
What
could
go
wrong
in
that
code?
I'm
gonna
focus
on
three
main
things,
and
these
things
are
first
of
all,
we
have
one
copy
of
the
letter,
but
right
now
we
have
nothing
enforcing
us,
no
preventing
us
from
making
a
copy
of
the
letter.
A
Second,
we
have
one
envelope
and
we
have
one
letter
if
we
put
the
first
letter
in
the
envelope,
but
then
develop
is
used,
but
we'll
see
how
this
may
go
wrong
and
of
course,
we
also
may
end
up
with
an
empty
envelope
that
we
end
up
giving
to
the
driver
without
having
put
any
any
letter
in
it.
And,
finally,
we
may
forget
to
tell
the
driver
we
are
done.
So
how
does
this
look
in
code?
A
First
of
all,
they
do
placate
copy
right
now.
The
first
good,
because
earlier
I
showed
you
has
add
a
single
letter
in
it,
and
now
we
still
every
single
letter
in
gear
as
fast
but
two
envelopes
we
just
construct
them
by
putting
it
them
in
a
batch
vector,
we
ordered
a
pickup
and
then
we
try
and
put
the
same
letter
into
two
different
envelopes.
If
you
look
at
the
code
that
does
this
that's
what
I
said.
A
If
you
look
at
the
code
that
does
this,
we
have
the
screen
the
letter
that
is
cloneable,
so
we
can
make
copies,
which
is
now
exactly
the
correct.
Considering
that
these
letter,
which
is
a
minimal
example
here,
could
actually
represent
us
all.
You
know
on
two
important
resources
in
the
array
in
the
API
and
specifically.
A
Specifically
because
we
are
putting
the
same
letter
into
two
envelopes,
we
are
going
to
end
up
making
two
copies
of
this.
So
is
there
a
wave
to
prevent
us,
and
there
is,
of
course
it's
we
don't
make
letter
cloneable
anymore
and
when
we
we
change
the
wrap
function
a
little
bit
in
a
way
that
when
we
get
a
letter
from
the
API
client,
we
get
ownership
over
it
so
that
the
client
is
not
able
to
touch
the
letter
anymore.
A
This
also
prevents
the
risk
of
somebody
putting
the
letter
in
the
envelope
and
then
attempting
to
modify
it
while
it's
in
their
mouth,
which
is
ridiculous,
of
course.
So
if
we
do
this,
then
what
happens
when
we
make
this
call.
This
is
the
same
code
as
before
we
end
up
with
rust,
lovey
complaining
that
we
move
the
letter
in
the
previous
iteration
of
the
loop.
We
already
used
this
letter.
We
cannot
use
it
again,
so
first
problem
solved.
A
We
know
how
to
prevent
to
make
copies
of
things
that
are
not
actually
copyable
in
the
real
world.
Second
problem:
we
have
some
good
and
again
we
have
a
single
envelope
this
time,
but
we
try
to
use
two
letters.
First
letter
is
dead,
your
response
one,
but
then
we
change
this
code
a
little
bit.
Maybe
later
we
don't
really
really
understand
how
it
works
anymore.
So
we
make
a
new
letter
called
D
or
a
th,
and
then
we
try
to
wrap
the
new
letter
in
this
same
envelope.
A
What's
happens
here,
of
course
is
we
are
all
writing
the
letter
we
are
dead
before
which
again
in
the
real
world
makes
no
sense.
Is
there
a
way
we
can
prevent
this?
And
of
course
there
is,
we
can
put
an
assert
and
say
if
there
was
a
radial
letter
in
the
envelope,
just
stop
at
run-time,
say
something's
wrong
and
panic,
but
maybe
we
can
do
better.
A
A
An
empty
envelope
doesn't
ever
have
any
letter
in
it
and
a
closed
envelope
always
has
a
lot
organs
and
we
change
the
code
a
little
bit
so
empty
envelope,
wraps
a
letter
in
the
envelope
and
returns
us
a
closed
envelope
and,
even
importantly,
this
method
is
only
defined
on
rough
envelope
and
consumes
sorry
on
empty
envelope
and
consumes
the
empty
envelope.
So
once
we've
called
this
on
empty
envelope,
these
envelope
is
not
available
to
us
anymore.
This
is
done
by
not
defining
self
as
a
reference
of
course.
A
Secondly,
when
we
hand
the
letter
to
the
driver,
we
want
to
make
sure
we
hand
the
closed
one,
the
one
completed
with
the
letter
inside
and
so,
instead
of
just
x
any
envelope,
we
expect
a
close
one,
and
this
enforces
the
correct
order
of
operations
we
put
letter
into
the
envelope,
and
then
we
give
the
closed
envelope
to
the
driver.
Of
course,
this
requires
a
bit
of
a
change
to
this
as
well.
So
if
you
look
at
the
main
for
this,
we
need
to
do
at
all
changes
again.
A
So
if
we
try
this
and
this
envelope-
and
you
may
have
noticed
the
problem
already-
this
is
gonna
not
compile,
because
we
tried
to
give
the
empty
envelope
and
rust
is
preventing
us
from
doing
this
and
helpful
fully
is
actually
saying
I
expected
an
envelope
completed
with
the
letter
inside
I
got
an
empty
envelope
and
also
we
mail
it
away.
Maybe
we
want
to
use
wrap,
which
is
really
cool,
because
it's
pointing
us
in
the
right
direction
in
terms
of
documentation,
we
don't
need
to
document
this
explicitly.
A
The
compiler
is
going
to
tell
us
where
to
look,
and
so
of
course
you
just
change
it
a
bit
and
try
to
put
the
closed
envelope
and
give
it
to
the
driver
hey.
This.
Is
this
good?
But
again
we
are
trying
to
put
the
same
to
put
two
different
letters
in
the
same
envelope,
but
with
the
changes
we
made,
Russy
is
gonna
prevent
us
from
doing
so
again,
and
here
it's
helping
us
again
enforcing
that
we
are
following
the
right
steps
and
we
are
not
doing
anything.
That
sounds
sensible.
So
two
is
done
three.
A
How
we
make
sure
that
we
don't
forget
how
to
tell
the
driver.
We
are
done
well,
I,
say
we
give
the
letter
to
the
driver,
and
then
we
just
focus
and
forget
about
this,
of
course,
is
not
gonna
result
in
the
letter
being
completely
correctly
delivered,
but
of
course
we
can
just
implement
drop
for
the
handle
and
make
sure
that
every
time
the
handle
goes
out
of
scope,
we
are
making
sure
to
release
all
resources
and
send
everything
we
had
in
the
buffer
and
when
lorries
top
tier
whatever.
A
This
gives
the
information
to
the
driver
to
just
leave.
So
we
fix
this
as
well,
and
what
we
fix
here
is
three
things.
We
are
ensured
that
some
things
can
only
be
done
once,
and
this
happens.
A
lot
in
AP
is,
or
at
least
only
once
in
a
certain
context.
For
example,
when
a
shared
HTTP
connection,
we
made
sure
that
we
are
following
the
correct
order
of
operations
when
we
are
doing
something
and
we
guaranteed
that
we
drop
a
resource
when
we
don't
need
it
anymore.
Even
if
you
forget
about
doing
explicitly.
A
So
many
missions
I
forget
about
sometimes
sometimes
so,
of
course,
the
trouble
here
is
that
when
you
try
to
enforce
correct
ordering,
if
you
have
multiple
ways
from
getting
to
a
beans
in
terms
of
the
steps
you
need
to
do,
the
number
of
states
you
may
go
have
to
go
through
is
a
lot
and
you
may
end
up
with
a
lot
of
different
stocks,
representing
all
the
states.
Of
course,
there's
a
bit
of
a
trade-off.
A
Sometimes
it's
useful
to
just
have
a
lot
of
strikes
and
force
the
API
precisely,
and
sometimes
it's
just
better-
to
put
in
a
little
bit
of
runtime
checks
and
better
documentation.
So
two
really
quick
examples
on
how
this
works.
In
practice.
Let's
say
we
are
writing
an
HTTP
response
on
a
connection.
We
have
the
response
and
we
represent
two
states-
writing
the
headers
and
writing
the
body.
If
you
know
HTTP
once
you've
written
the
address,
you're
not
allowed
to
write
more.
So
when
you
started
with
writing
the
body,
you're
not
allowed
to
write
more
others.
A
If
you
have
already
sender
that's
a
way,
so
we
can
get
started
on
that
starts.
Writing
the
address,
and
then
we
get
an
object
that
only
allows
us
to
write
errors.
Once
we
are
done,
we
call
body
which
consumes
this
current
object
and
gives
us
another
thing,
which
is
the
way
to
write
the
body.
We
write
as
many
chunks
of
the
body
as
we
want,
and
then
we
say
we
are
done
and
of
course,
if
we
forget
to
say
we
are
done,
we
have
dropped,
setting
us
and
flushing
this
through
the
connection.
A
So
I
have
another
examples,
but
we
are
50
minutes
so
I'm
gonna
skip
over
this
and
just
say
that
the
point
of
this
is
Russ
gives
us
a
few
really
good
tools
to
make.
Api
is
clear,
and
sometimes
even
self-documenting
as
we
see
so
we
can
leverage
these
at
various
levels-
IRAs
management,
but
also
at
higher
levels
at
API
design.
So
there's
my
top.
Thank
you
very
much.