►
Description
Agenda ► https://rusty-days.org/agenda
Slides ►https://rusty-days.org/assets/slides/05-the-rust-borrow-checker.pdf
Playlist with all talks ► https://www.youtube.com/playlist?list=PLf3u8NhoEikhTC5radGrmmqdkOK-xMDoZ
Follow ►
Facebook: https://rusty-days.org/facebook
Twitch: https://rusty-days.org/twitch
Twitter: https://rusty-days.org/twitter
This video ►
The Rust compiler's borrow checker is critical for ensuring safe Rust code. Even more critical, however, is how the borrow checker provides useful, automated guidance on how to write safe code when the check fails.
Early in your Rust journey, it may feel like you are fighting the borrow checker. Come to this talk to learn how you can transition from fighting the borrow checker to using its guidance to write safer and more powerful code at any experience level. Walk away not only understanding the what and the how of the borrow checker - but why it works the way it does - and why it is so critical to both the technical functionality and philosophy of Rust.
A
All
right,
hello,
everyone
around
the
world.
Thank
you
so
much
for
having
me
today
here
at
rusty
days.
It
is
late
afternoon
here
in
seattle,
washington,
but
I
hope,
whatever
time
it
is
in
your
part
of
the
world,
you
are
doing
well
when
I
work
with
someone
who
is
just
learning
rust,
they
sometimes
question
whether
the
rust
borrow
checker
is
their
friend
or
their
foe.
A
A
A
A
When
I
work
with
someone
who
is
just
learning
rust,
they
sometimes
question
whether
the
rust
borrow
checker
is
their
friend
or
their
foe.
If
you
take
a
look
at
the
russ
subreddit,
you
will
see
common.
It
was
common
to
see
posts
like
this
newbie
question
regarding
the
borrow
checker
help
fighting
the
borrow
checker,
and
does
it
ever
get
easier
fighting
with
the
borrow
checker,
so
it's
common
to
feel
a
lot
of
frustration
when
you're
first
starting
with
rust.
A
A
I
say
the
borrow
checker
becomes
your
friend
through
gaining
experience
with
it
and,
along
with
getting
experience,
it's
also
very
helpful
to
understand
how
it
works
and
why
it
does
the
things
it
does
we're
going
to
dive
very
deep
into
that,
but
before
we
do,
let's
briefly
cover
who
I
am
I'm
nell,
shamrell
harrington.
I
am
a
senior
staff
research
engineer
at
mozilla,
if
you,
if
my
voice
sounds
familiar
to
you,
I
am
the
lead
editor
of
this
week
in
rust
and
host
of
the
this
week
in
russ
podcast
on
the
rust
station
station.
A
If
you
ever
want
to
get
in
touch
with
me
honestly,
twitter
is
the
best
go
ahead
and
tweet
me
at
nell
shamrell,
and
let's
get
back
to
the
presentation
first,
just
to
set
expectations,
we're
going
to
take
an
overview
of
the
rust
compiler.
In
order
to
understand
the
context
in
which
the
borrow
checker
works,
it's
important
to
understand
a
little
bit
about
how
the
rust
compiler
works
and
then
we
will
dive
very
deep
into
the
borrow
checker
after.
A
A
Now,
if
I
were
to
run
this
using
cargo
run,
I
would
see
these
five
numbers
one
through
five
printed
out
on
the
screen.
Now
this
seems
pretty
simple.
Cargo
builds
and
runs
this
piece
of
code
for
us,
but
there's
a
lot
that
happens
underneath
the
surface
in
the
compiler.
When
cargo
is
building
it,
there
are
five
general
stages
to
compiling
a
piece
of
code.
A
A
A
A
A
However,
as
you
watch,
people
gain
more
experience
and
rust,
they
tend
to
come
around
to
the
borrow
checker
and
realize
what
it
protects
them
from
doing.
So.
An
answer
to
the
question
is
the
borrowed
checker,
a
friend
or
a
foe.
I
say
the
borrow
checker
will
become
your
friend
through
experience
and
along
with
gaining
experience
with
it,
it's
very
helpful
to
understand
how
it
works
and
why
it
does
the
things
it
does
we're
going
to
dive
very
deep
into
that.
But
before
we
do,
let's
briefly
cover
who
I
am.
A
A
When
cargo
is
building,
there
are
five
general
stages
to
compiling
a
piece
of
code.
It
starts
with
lexical
analysis
of
the
code,
then
parsing
of
the
code
semantic
analysis
of
the
code.
This
is
where
the
borrow
checker
comes
in
optimization
of
the
code
and
finally
code
generation,
where
the
compiler
creates
that
executable
binary
of
our
code.
A
Let's
start
with
the
first
one
here,
lexical
analysis
during
lexical
analysis.
A
program
within
the
compiler
called
alexa
takes
the
raw
rust
source
code
called
a
lexeme
in
this
context
and
analyzes
it
and
then
splits
the
code
into
tokens
to
make
it
easier
for
the
compiler
to
parse
and
speaking
of
parsing.
A
A
A
The
next
thing
the
compiler
does.
Is
it
also
de-sugar
some
of
the
syntactic
sugar
that
makes
riding
rust
so
delightful.
For
example,
in
rust,
the
for
loop
is
a
piece
of
syntactic
sugar
for
an
iterator.
If
we
were
to
de-sugar
this
section
of
code,
it
would
consist
of
both
a
match
statement
and
a
loop.
A
The
functionality
of
this
code
is
identical
to
the
for
loop
in
our
original
source
code,
but
de-sugaring.
It
like
this
makes
it
easier
for
the
compiler
to
understand
and
optimize
it.
Something
I
like
to
say
is
sugar
code
is
for
the
human
who's
writing
and
reading
the
code
d.
Sugar
code
is
for
the
compiler,
and
at
this
time
the
compiler
also
resolves
any
imports
in
the
code.
A
So
if
you
are
bringing
in
an
external
crate
or
using
internal
crates
or
modules,
those
would
be
resolved
here
as
well
and,
finally,
after
the
compiler
does
all
these
things.
It
converts
that
abstract
syntax
tree
into
the
higher
level
intermediate
representation
or
h-I-r
some
people
say
here
some
people
say
h-I-r.
I
generally
prefer
h-I-r.
A
A
Definitions
are
primarily
top-level
items
within
the
crate.
This
is
identified
by
a
def
id
and
that
definition
defined
by
the
def
id
is
owned
by
the
crate
data
structure.
This
is
the
crate
we
are
compiling
with
rust.
This
data
structure
stores
the
contents
of
the
crate.
We
are
compiling
and
also
contains
a
number
of
maps
and
other
things
that
help
organize
the
content
for
easier
access.
Throughout
the
compilation
process,
this
crate
is
identified
with
a
crate
num.
A
So
looking
back
at
our
original
source
code,
let's
focus
on
this
section
here
that
for
loop
and
remember
that
this
loop
d,
sugars
into
a
match
statement
and
a
loop.
If
we
look
at
the
node
in
the
hir
that
represents
this
match
statement,
we
would
see
something
similar
to
this
now.
This
is
a
little
hard
to
read
for
humans.
So,
let's
break
it
down.
A
A
A
What
also
helps
us
do
that
is
what
is
called
a
span:
the
span
stores
the
file
path,
line,
numbers
and
column
numbers
of
the
original
source
code.
This
will
be
very
important
in
the
future
as
we
optimize
and
de-sugar
the
code.
If
we
encounter
a
problem
with
the
code,
if
the
compiler
encounters
a
problem
after
it
is
de-sugared
and
optimized,
we
still
want
to
be
able
to
show
the
user
where,
in
their
original
code,
that
they
wrote
that
the
error
was
generated.
A
If
we
were
to
have
a
problem
with
the
with
the
d
sugar
code
and
show
them
those
lines,
it
probably
wouldn't
mean
that
much
to
them,
because
it's
different
from
the
code,
they
originally
wrote
at
this
point.
The
compiler
then
takes
this
hir
and
lowers
it
again
into
the
mid-level
intermediate
representation,
also
known
as
the
mir.
A
A
A
A
A
local
in
the
mir
represents
a
place
in
memory
or,
more
specifically,
a
place
on.
The
stack
frame
in
this
case
underscore
5
corresponds
to
the
value
of
the
variable
result
and
like
in
the
nodes
in
the
hir.
We
have
a
span
the
piece
of
the
original
rust
source
code
that
each
node
in
the
mir
corresponds
to
again.
A
A
The
rust
compiler
uses
it
to
further
optimize
the
code
and
generate
the
machine
code
to
run
it
as
an
executable
before
it
uses
llvm.
The
rust
compiler
takes
the
mir
we
created
earlier
and
lowers
it
into
the
llvm
intermediate
representation
or
llvmir,
and
the
llvmir
is
pretty
unreadable
to
humans.
But
it
looks
something
like
this.
A
A
It
won't
be
considered
initialized
until
it
is
assigned
a
value,
and
if
we
look
at
the
mir
for
this
line
of
code,
we
can
see
that
x
is
represented
by
the
local
underscore
one
and
local
underscore
one
is
assigned
the
type
of
string.
So
this
is
the
mir
that
corresponds
to
this
line
of
code,
and
this
is
what
the
compiler
is
analyzing.
A
Now
that
x
has
a
value
it
is
considered.
Initialized
at
this
point,
so
x
is
initialized
and
the
borrow
checker
is
aware
of
that.
We
create
to
do
this.
We
create
a
new
place
in
memory,
local
underscore
2,
where
we
store
the
high
rusty
day
string,
and
then
we
move
the
value
stored
in
underscore
2
to
underscore
1..
A
A
A
A
A
So
let's
do
what
this
says:
let's
take
this
advice
and
change
this
line,
so
that
y
is
assigned
to
a
reference
to
the
value
of
x
rather
than
moving
the
value
of
x
into
y,
and
let's
go
ahead
and
run
this
again
and
once
the
compiler
builds
the
code
and
executes
it.
We
see
the
message
high
rusty
days
printed
out
twice,
rather
than
fighting
the
borrow
checker.
We
used
it
to
make
our
code
even
better.
A
A
Another
word
for
referring
to
the
lifetime
of
a
value
is
referring
to
the
variable
scope
and,
let's
see
how
this
plays
out
in
our
code,
and
let's
start
with
this.
First,
let's
start
with
the
second
line,
where
we
assign
the
value
of
x
to
this
high
rusty
day.
Strength
at
this
point
x
is
live,
it's
initialized.
Its
lifetime
begins
here
when
we
get
to
here
and
move
the
value
of
x
into
y.
A
A
A
A
A
A
That
means
that
once
we
drop
the
value
of
x
again
x's
lifetime
is
over
and
y
can
no
longer
reference
the
value
of
x
after
this
line.
So
at
this
point
in
this
last
line
x
would
be
dead.
Its
lifetime
is
no
longer
an
effect,
and
why
would
not
be
able
to
reference
it
again
in
order
for
this
code
to
compile
the
lifetime
of
x
must
last
at
least
as
long
as
the
lifetime
of
y
and
how
these
two
ways
the
overarching
way,
the
scope
and
the
lifetime
of
a
reference
relate
to
each
other.
A
A
Now,
as
I
move
toward
concluding
this
presentation,
I
want
to
make
sure
that
you
know
that
there
is
so
much
more
to
the
rust
compiler
and
the
borrow
checker
again.
If
you
want
to
know
more
check
out
the
guide
to
rust
c
development
for
more
information,
it
is
a
fantastic
resource.
It
has
been
so
helpful
to
me
as
I've
taken
my
own
steps
not
only
into
using
rust
but
hacking
on
the
rust
compiler
itself.
A
A
A
A
A
A
A
U-W-E-D-R-A-C-H-E
asks
is
x's
lifetime
extended
by
being
borrowed
by
y,
and
the
answer
to
that
is
no
x's.
Lifetime
will
end
when
we
drop
it,
even
if
it's
borrowed
by
why
I
would
the
nice
thing
about
the
borrower
checkers,
as
you
saw,
that
prevents
us
from
yeah
that
prevents
us
from
trying
to
compile
the
code
when
x's
lifetime
runs
out
before
y's
next
question
from
damien
on
youtube
is:
did
you
have
any
bad
habits
from
other
language
that
made
borrow
checker
unhappy?
If
so,
what
were
such
habits?
A
Yes,
I
came
from
the
ruby
world,
like
surprisingly,
a
lot
of
people
in
the
rust
world,
so
I
was
very
used
to
you
know
duck
typing.
I
was
very
used
to
not
really
paying
attention
because
I
had
the
garbage
collector
to
when
my
variables
went
into
scope
or
out
of
scope.
So
breaking
those
habits
was
hard.
I
was
definitely
it
definitely
took
a
few
months,
but
it
now
feels
like
the
rest
code.
I
write
is
so
much
safer
than
the
ruby
code.
A
A
A
A
I
could
see
it
if
we
made
a
good
case
for
it
if
we
did
not
have
to
give
up
any
of
the
safety
mechanisms
that
are
in
rust
right
now,
the
reason
so
many
people
love
rust,
especially
when
they
come
from
the
c
plus
plus
world,
is
they
feel
very
safe
because
they
know
the
compiler
will
tell
them
when
something
is
incorrect.
As
for
the
compiler
abstracting
and
referring
what
the
program
are
meant
to
do,
that'd
be
very
interesting.
I'd
love
to
see
a
prototype
of
that.
A
A
A
lot
of
times
I
see
in
you
know
the
rush
channels
and
slacks
that
I'm
in
that
people
ask
well
couldn't
what's.
Russ
does
just
be
done
by
c
plus
plus
programmers
who
are
committed
to
good
standards
and
writing
safe
code
and
really
experienced,
and
the
answer
to
that
is
the
thing
about
programmers,
as
you
all
know,
is
we're
all
human.
We
all
make
mistakes.
I
tell
people
about
the
time.
I
wrote
some
not
optimized
ruby
code
and
I
ended
up
ddosing
myself,
because
the
database
queries
it
was.
A
A
I
believe
when
you
try
to
use
y,
so
that
is
another
potential
way
to
solve.
The
problem
we
saw
in
our
code
would
be
to
add
a
specific
lifetime
into
it.
Next
question
comes
from
youtube.
Bart's,
hello
me
a!
I
sincerely
apologize
if
I'm
butchering
the
names
here,
how
much
would
borrow
checker
and
borrowing
by
be
affected
by
chalk
and
polonius
in
the
near
or
not
so
near
future?
A
That
is
a
great
question
and
I
think
that's
something
that's
still
being
figured
out
when
I
started
putting
this
talk
together.
I
worked
with
nico
matsukis
at
mozilla
who's
on
the
russ
core
team,
and
I
told
him
I'm
putting
together
a
talk
on
the
borrow
checker
and
he
said.
Oh,
let
me
send
you
your
talk.
My
talk
about
polonius,
so
polonius
would
change
things.
Chalk
would
potentially
I'm
not
as
familiar
with
chalk
as
I
am
with
polonius.
A
I
because
polonius
at
least
takes
a
different
approach
to
tracking
borrows
lens,
etc.
So
I
will
tweet
out
a
link
to
niko's
slide
deck,
which
will
go
into
more
detail
about
polonius
next
question
from
czecho
thief:
do
people
working
with
borrow
checker
find
this
has
changed,
how
they
think
about
the
systems
they
build.
A
Yes,
I
so
I
learned
I
did
take
computer
science
courses
in
college,
but
I
was
not
a
computer
science
major,
so
I
learned
most
of
my
programming
from
doing
it
and
I
started
with
web
programming
and
with
web
programming.
Yes,
memory
is
a
consideration,
but
when
you're
not
doing
back-end
system
programming,
you
don't
consider
it
as
much
now
that
said
before
I
was
at
mozilla,
I
was
at
chef
software,
as
you
can
see
in
the
photo.
A
But
when
I
found
rust,
it
forced
me
to
think
through
ahead
of
time
of
how
my
program
would
interact
with
memory
and
how
the
scopes
of
my
variables
and
such
would
work
through,
and
it's
very
much,
I
think,
of
rust.
As
someone
has
said
this,
I
don't
remember
who
is
compiler
driven
development,
so
I
write
some
code.
I
try
to
build
it
and
I
see
what
the
compiler
tells
me
and
then
I
try
to
correct
my
code
and
I
go
back
and
forth
and
iterate
on
that.
A
So,
yes,
it
has
made
me
think
a
lot
about
the
systems
that
I
build.
Next
question
is
michael
ward,
which
of
the
upcoming
changes
to
rust.
Are
you
and
or
mozilla
most
excited
to
see?
I
can
tell
you
one,
I'm
working
on
personally,
which
is
adding
the
ability
to
use
a
stream
with
async
or
adding
the
stream
function
of
async
code
into
the
standard
library.
There
are
code.
A
So
async
is
an
area
that
has
a
lot
of
my
focus
right
now
and
it
works
well
the
way
it
is,
but
I
can't
wait
to
innovate
on
that.
I'm
working
on
drafting
an
rfc
now
regarding
moving
the
stream
trait
into
the
standard
library.
So
async
streams,
I
would
say,
is
what
I
am
personally
most
excited
about
right
now,
michael
lezzowski
asks
how
do
you
rate
the
rust
community
comparing
to
ruby
well
most
of
my
experience
with
the
ruby
community.
A
Was
you
know,
five
or
six
years
ago
and
there's
a
lot
of
people
who
migrated
from
the
ruby
community
to
rust,
like
steve,
klobnick,
sean
griffin,
etc.
So
it
feels
like
a
lot
of
the
community
leaders
are
the
same.
I
would
say
what
I
love
it's
I
ruby
community
is
very
good,
but
I
love
the
most
about
the
rust
community
is
that
we
are
a
community
that
considers
empathy
and
personal
maturity
to
be
as
important
as
technical
excellence,
and
you
know,
ruby
community
has
some
of
that,
but
other
technical
communities
I've
been
into.
A
A
Let's
see
here
next
question
ethan,
really
how
much
do
extra
checks
russ
does
affect
cup.
I
think
he
meant
compilation
performance,
I'm
not
sure.
Actually,
so
let
me
get
back
to
you
on
that.
One
ecs
means
entity
component
system
answer
that
is,
I
don't
know,
I'm
not
as
familiar
with
those
systems.
I
think,
but
I'm
very
curious,
michael
ward,
on
youtube
asks.
Are
there
any
known,
borrow
checker
improvements
that
will
vastly
improve
ergonomics
like
non-lexical
lifetimes
did.
I
am
sure
there
are
some
in
the
works.
A
I
don't
know
of
any
specific
ones
off
the
top
of
my
head
right
now
s
burnham
on
twitch
asks
since
since
russ
doesn't
have
a
rpl,
do
you
find
new
rust
stations
often
use
the
compiler
as
a
testing
mechanism,
I.e,
attempting
to
compile
fix,
compile
again?
Is
there
a
better
way
to
experiment
in
rust?
Well,
I
can
tell
you
when
I
was
in
new
york
station.
That
is
exactly
what
I
did.
I
would
write
a
small
piece
of
code
see
what
the
compiler
did
with
it.
Compiler
aired
out.
A
I
would
change
it
and
I
would
make
the
compiler
be
able
to
use
the
small
piece
of
code
before
moving
on
to
the
next
one.
That,
honestly,
for
me,
has
been
the
best
way
to
learn
the
best
thing
about
the
rust
compiler
and
someone
will
be
doing
a
talk
about
this
at
russ.
Conf
in
august
is
that
the
compiler
itself
is
a
tutor.
It's
an
automatic
tutor
and
the
error
messages
are
very
helpful
because
again
they
not
only
tell
you
what
was
wrong.
A
A
A
I
would
say
I
do
when
I'm
putting
in
a
ton
of
explicit
lifetimes,
I
kind
of
feel
like
I'm
flailing
against
the
borrow
checker,
rather
than
really
you
know
using
it
to
understand
why
it
does
what
it
does.
So,
yes,
a
lot
of
explicit
lifetimes
in
a
small
amount
of
code.
That
tells
me
there's
probably
a
different
way
that
I
can
structure
it
and,
as
you
say,
stop
and
rethink
your
types
and
logic.
What
I
would
also
suggest
doing
is,
you
know,
pause.
A
You
know
obviously
read
the
compiler
error
messages
and,
if
you're
trying
to
do
a
lot
of
explicit
lifetimes
to
correct
that
error
message,
google,
the
error
message
itself,
there's
a
lot
of
stuff
on
stack
overflow.
I
believe
it's
russ
from
russ
community
member
burnt
sushi.
I
love
that
name
has
posted,
so
many
really
helpful
answers
on
it
and
the
best
thing
about
bert
sushi's
answers
is:
they
very
clearly
understand
how
the
rust
compiler
works
and
they
give
answers
along
those
lines.
So
that's
the
other
thing
I
would
do
is
yeah.
A
A
It
has
not
been
formally
proposed
yet
I
don't
think
we'll
support
it
in
the
initial
implementation,
but
it
is
possible
that
could
change
before
we
open
the
rfc
and
even
after
the
rfc
is
open
based
on
the
response
of
the
community
to
it
so
stay
tuned.
We
are
definitely
talking
about
that
and,
let's
see
here
mike
lesowski
says,
have
you
read
computer
systems,
the
programmer's
perspective?
If
not,
I
would
think
it
would
be
interesting
for
you.