►
From YouTube: Mutable borrows
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
hello,
welcome
to
this
tutorial
on
mutable
borrows
this
picks
up
where
the
ownership
and
shared
borrows
tutorials
left
off.
So
when
we
last
met
our
two
friendly
stick
figures,
they
had
just
learned
to
share
with
one
another
and
in
particular
we
were
able
to
give
a
reference
to
a
book
so
that
many
people
could
read
it
at
the
same
time.
A
So
here's
a
snippet
of
code
very
similar
to
the
one
we've
been
working
with
only
this
time,
the
helper
routine-
that
we
call,
which
is
called
update,
is
not
only
going
to
read
from
a
string
that
we
own
it's
going
to
write
to
the
string
that
we
own.
So
it
begins
by
saying
let
Muta
name
equals
I
left
out
here,
but
format,
bang,
let's
say,
and
that
will
allocate
the
string,
the
string
buffer
that
we
have
and
then,
when
we
call
update,
you
see
that
the
argument
is
no
longer
ampersand
string,
but
ampersand
mute
string.
B
A
On
the
other
side,
when
we
lend
it
out,
we
don't
write
ampersand
name.
We
write
ampersand
Muta
name
so
that
we
can
lend
out
a
mutable
reference
to
our
name,
so
it
in
terms
of
what
happens
at
runtime.
We
end
up
with
the
update
function.
Having
a
mutable
reference.
I
know
this
is
actually
the
same
at
runtime,
but
logically
mutable
references
behind
someone
differently.
So
you
may
not
have
noticed
that,
but
I
just
faded
the
book
a
little
bit.
A
That's
because
when
we
had
a
shared
borrow
and
a
shared
reference,
we
could
give
away
as
many
copies
of
that
shared
reference.
As
we
want
we're
going
to
see
the
mutable
references,
you
can
only
have
one
copy
of
them
at
a
time
and
while
there's
a
mutable
reference,
that's
active,
you
lose
access
to
the
original
variable.
So
while
we
have
this
mutable
reference
to
name,
we
can't
use
name
anymore.
A
So
that's
why
I've
faded
the
book
slightly
to
indicate
that
it's
only
accessible
now
through
this
mutable
reference
anyway,
update,
doesn't
care
about
that
update,
has
a
mutable
reference
and
it
can
go
ahead
and
use
it.
And
the
interesting
thing
is
when
it
makes
mutations
through
this
reference,
it's
actually
changing
the
string
that
the
function
main
owns
right
so
here
when
it
calls
name
dot,
pushed
err,
it's
actually
going
to
mutate
name
in
place.
A
So
that
means
that
the
variable
name
is
going
to
change
from
having
the
old
string
to
the
new
string,
which
has
some
new
text
appended
on
the
end.
And
that
means
then,
when
we
return
well,
this
mutable
borrow
is
going
to
end
again
update
didn't
own
the
data,
so
no
data
gets
freed.
It
was
just
borrowing
the
data
and
we.
B
A
Back
and
now
we
we
now
have
full
access
to
our
string
buffer.
Again,
that's
because
update
finished
with
that
mutable
reference,
it's
no
longer
in
use,
so
we
can
use,
we
can
use
it
again
and
it
only
it
has
new
contents,
and
so,
when
we
print
it
we're
going
to
see
something
different,
then
we
saw
the
first
time
and
of
course,
we're
still
the
owner.
So
when
main
returns,
that
means
that
this
data
is
going
to
get
free.
A
So
in
this,
in
the
last
two
tutorials
we've
now
seen
the
three
primary
ways
to
interact
with
data
in
rust.
Alright,
first
thing
we
saw
was
ownership.
If
you
own
some
data,
that
means
you
control
all
access
to
it
and
when
you're
finished
with
it
that
that
is
going
to
get
freed,
the
next
thing
is
always
shared
references.
A
If
you
have
a
shared
reference,
you
can
have
a
lot
of
different
copies
of
that
shared
reference
all
reading
from
the
data
and
all
active
at
the
same
time,
but
there's
no
way
to
mutate
the
data,
while
it's
being
shared,
or
at
least
you
have
to
go
through
special
api's
we
haven't
seen
yet,
and
the
last
way
that
we
just
saw
is
a
mutable
reference.
In
this
case,
the
only
way
to
access
the
data
is
through
that
mutable
reference
right.
A
We
lose
access
to
the
original
variable
temporarily,
and
so
we
know
that
that
mutable
reference
has
exclusive
access
else,
can
read
from
that
vert
data
and
no
one
else
can
write
to
that
data
unless
they
go
through
this
reference.
Okay,
so
we're
back
to
these
awesome
dogs,
again
I'm,
going
to
jump
back
to
play
and
then
try
to
give
you
a
feeling
for
these
mutable
reference
rules,
how
they
relate
to
actual
code.
So
here
we
have
our
example.
This
is
actually
the
ownership
example.
We
saw
before
where
we
give
ownership
twice
and
get
an.
B
A
We
can
write
ampersand
mute
on
both
places.
We
have
to
declare
the
string
itself
to
be
mutable,
and
then
we
can
actually
push
some
data
onto
the
string
right
and
let's
move
this
print
up
here
so
that
it
comes
after
and
we
can
see
the
effects.
So
when
we
run
this
now
we
started
with
fellow
Russ
stations
and
we
see
that
we're
going
to
get
we've
written
two
copies
of
the
word
foo
on
the
end.
B
A
And
now,
let's
try
to
run
this
code
now.
Well,
we
actually
get.
This
error
cannot
borrow
name
as
immutable
and
is
pointing
to
this
use
of
the
word
name.
So
this
is
a
illustrating
exactly
this
property.
I
was
referring
to
that
mutable
references,
while
they're
in
scope,
kind
of
get
a
exclusive
access
to
the
variable.
That's
underneath
them
alright.
So
here
we
created
the
variable
R,
which
is
a
mutable
reference
and
for
the
remainder
of
its
scope.
That
means
we
lose
access
to
this
variable
name.
B
A
A
Well,
naturally,
that's
not
allowed
so
here
I'm,
getting
an
error
right
here
where
I
tried
to
make
a
second
mutable
reference
to
the
same
variable
name,
but
in
that
case
the
first
reference
R
would
no
longer
be
exclusive
right.
We
could
use
our
or
our
two
and
we
want
to
guarantee
that
you
only
have
one
mutable
reference
at
a
time,
and
the
last
thing,
I'm
going
to
say,
is
at
the
first
version
of
this
code
and
the
code,
the
version
you
would
write
most
often
oops
created
a
reference
and
passed
it
in
as
a
parameter.
A
So
that's
effectively
a
kind
of
shorthand
for
making
this
explicit
variable
that
has
a
very
narrow
scope.
All
right,
tied
just
to
this
function
call.
So
that's
why
we
can
kind
of
repeat
this
as
many
times
as
we
like,
and
we
never
get
an
error
on
about
having
more
than
one
mutable
reference,
because
really
at
any
one
time
you
only
have
one
mutable
reference,
all
right.
A
Let's
go
back
to
the
slides,
so
we've
seen
now
what
the
rust
rules
are,
and
we
kind
of
have
a
feeling
for
how
a
mutable
reference
works
and
how
it
gets
exclusive
access
to
the
thing
being
mutated.
But
we
haven't
really
seen
why
and
so
to
explain
that
I
want
to
dive
a
little
bit
into
the
question
of
safety
and
by
safety.
A
What
I
mean
is
this
is
basically
the
key
rules
that
allow
us
to
avoid
using
a
garbage
collector,
while
also
avoiding
segmentation
faults
right
and
to
allow
us
to
have
threads
while
avoiding
data
races.
It's
basically
all
based
on
these
ownership
and
borrowing
rules
we've
been
talking
about
so
here
is
the
example.
I
want
to
go
through.
It
begins
like
many
of
our
examples
by
allocating
a
string
right
and
then,
if
you
look,
it
creates
a
reference
into
that
string,
called
slice
and
pushes
a
new
letter
onto
the
string.
A
So
before
the
string
address
station
now
it's
going
to
have
rest
stations
with
an
S
at
the
end,
and
then
it
prints
that
slice.
You
might
expect
this,
for
example,
to
print
us
stations
with
an
S
on
the
end.
But
what
actually
happens
if
you
if
this
code
were
to
run
well?
Let's,
let's,
let's
execute
it,
we're
going
to
kind
of
see
how
the
Machine
model
works.
So
the
first
thing
that
would
happen
is
we
create
a
string
and
a
string.
A
A
Now
a
slice
at
run
time
is
represented
by
a
reference
directly
into
the
data
buffer
of
the
string.
So
we
don't
really
even
know
where
the
original
string
was
all
we
have
is
the
data
at
our
fingertips
right
and
we
also
have
a
length
in
this
case
the
length
will
be
8
because
it's
the
RUS
station,
dr
and
now
we
want
to
push
an
S
at
the
end,
and
this
is
where
things
get
interesting.
Remember
I
told
you
our
buffer
was
full,
so
it
only
had
space
for
nine
letters.
Well
now
we
need
10.
A
A
It
says
recitations,
so
we'll
have
a
length
of
ten
and
a
capacity
of
eighteen,
but
now
we
have
two
buffers:
we
don't
really
need
the
old
one
that
had
the
old
data
so
we're
going
to
free
it
and
then
we're
done
with
the
push
stir
operation.
But
here
we
come
to
print
the
slice,
and
now
we
get
into
problems,
because
this
slice
is
still
referring
to
the
old
memory
right
when
the
buffer
was
copied.
The
slice
can't
get
updated.
A
Remember,
there's
really
no
link
between
the
slice
and
the
string
itself
and
that's
what
that's
what
we
call
it
dangling
reference
reading
from
freed
memory
is
undefined
behavior.
So
technically
this
program
could
do
anything.
What
it
usually
will
do
is
usually
it'll
print
us
station,
at
least
whenever
you're
testing
it,
but
once
you
get
to
your
customers,
computer
it'll
start
printing
secret
keys
from
their
memory
or
who
knows
what
right?
So
that's
not
a
good
situation
to
be
in,
and
we
would
really
like
this
code
not
to
execute
and
in
fact
in
rust
it
doesn't.
A
It
gets
a
compilation
error,
so
basically,
the
way
rust
solution
works
as
we've
seen.
Is
it's
a
kind
of
compile
time,
readwrite
lock
now
a
rewrite
lock.
Is
this
handy
thing
you
can
use
in
parallel
programming,
where
you
say
I
have
some
data
and
I
want
to
allow
either
a
whole
lot
of
readers
or
exactly
one
writer
with
with
no
readers
right,
no
other
threads
reading
at
the
same
time,
and
this,
this
is
how
you
can
avoid
data
races.
It's
also
exactly
the
model
that
rust
enforces
a
compilation
time.
A
Of
course,
there's
no
real,
lock
here
right,
it's
just
a
metaphor
to
help
you
kind
of
process
how
it
works.
So
if
we
look
at
our
example,
the
basic
rule
is
when
you
borrow
something
either
as
a
shared
borrow
or
a
mutable
borrow.
You
can't
mutate
it
through
the
original
path.
While
it's
borrowed
right
so.
B
A
When
we
make
this
slice
we're
going
to
borrow
the
variable
buffer,
actually
a
subset
of
the
buffer,
but
it's
not
an
important
distinction
here
and
we're
going
to
say:
let's
figure
out
how
long
this
is
called
the
borrows
lifetime.
How
long
is
that
reference
in
scope?
Four
slash
going
to
be
used
alright,
so
here
we
see
that
the
reference
is
created
by
the
ampersand
expression
it
gets
stored
in
this
slice
variable.
The
slice
variable
is
in
scope
until
that
closing
brace.
So
that
means
this
is
the
lifetime
of
our
borrow.
A
So
you'll
often
hear
this
word.
Lifetime
used
in
rest,
tutorials
and
so
forth.
A
lifetime
is
really
a
span
of
code
in
which
our
reference
is
used
right.
So
here
the
right
lifetime
is
starting
from
the
let
and
going
to
the
closing
brace
and
we
usually
give
lifetimes
names
I'm
just
going
to
give
this
one:
the
name:
tick:
L,
that's
rust,
notations
that
tickle!
That's
on
the
right
side
of
the
screen.
A
A
lifetime
is
a
name
that
begins
with
a
tick
right,
so
here
we'll
just
call
it
tick
dial
just
for
having
a
name
to
use,
and
then
we
look-
and
we
say
during
this
lifetime-
tick
L,
the
original
variable
buffer
is
locked
right.
So
you
it's
got
a
read
lock.
Essentially
that
means
no
one
can
write
to
it.
So
that's
exactly
why,
when
we
see
this
call
to
buffer
dot
push
stir
which
occurs
in
the
middle
of
that
lifetime,
we
can
call
it
an
error.
A
This
is
that
this
lock
only
lasts
as
long
as
the
reference
is
in
use.
So
here
we
have
a
variation
on
the
example
and
what
I'm
doing
is
I
I've
moved
that
code
we
had
before
into
a
loop.
Alright.
So
here
is
the
borrow
the
same
kind.
We
saw
before
that's
going
to
borrow
the
variable
buffer,
and
that
means
we're
going
to
have
a
lock
until
the
variable
slice
goes
out
of
scope
all
right,
but
here
the
variable
goes
out
of
scope
at
the
end
of
the
loop.
A
So
that
means
this
region
of
code
in
this
region
of
code
buffer
is
read
locked.
So
that
means
we
get
an
error
here
in
the
loop
if
we
try
to
call
buffer
up
push
stir
because
that
falls
within
that
region
of
code.
But
after
the
loop,
that's
perfectly
fine.
The
buffers
not
borrowed
here
right
so
mutability
in
rust,
as
you've
seen
a
number
of
times.
It's
really
a
property
that
isn't
fixed.
A
It
depends
on
where,
in
the
code
you
are
right,
the
same
data
becomes
immutable
during
the
loop
while
it's
borrowed
and
then
becomes
mutable
later
after
the
loops
over
okay.
So
that's
it
it's
time
for
the
exercise
as
usual,
I
want
you
to
go
down
and
click
below
on
the
exercise,
link
or,
if
you're,
not
in
the
into
rust
website,
go
ahead
and
grab
that
URL
from
the
lower
left
corner
and
do
the
same
thing
and
then
I'm
going
to
take
you
over
to
the
play
site.
Now,
I'll
walk
you
through
the
example.
A
You
can
give
it
a
try
and
come
back
and
see
the
solution.
Okay,
so
here
is
the
code
for
the
exercise
I'm
going
to
walk
through
it
and
then
we'll
look
at
the
challenge
that
you
have
to
solve.
So
the
first
thing
it
does
is
it
calls
this
two
words
function,
which
we've
seen
before
two
words
returns
a
pair
of
strings.
The
first
one
is
going
to
be
fellow,
the
second
one
rust
stations
and
these
get
packaged
up
into
a
pair
and
returned
right.
A
So
it
basically
makes
two
buffers
and
gives
ownership
of
both
of
them
back
to
its
caller.
Caller
is
going
to
store
those
buffers
into
two
separate
variables.
The
first
one
is
called
stir
one.
The
second
one
is
called
stir
two
and
then
it
calls
join
words.
You
see,
the
join
words
is
a
function
which
takes
two
string
arguments
and
it
takes
ownership
of
those
strings
and
what
it
does
is
the
prefix.
A
The
second
argument
and
pushes
that
character
onto
the
string
and
then
finally,
it
returns
ownership
of
this
string
back
to
the
caller
all
right,
so
ownership
will
flow
further
for
the
prefix
ownership
will
flow
kind
of
from
here
from
fellow
up
to
stir
one
into
the
join
words
function
where
we
have
ownership
here
and
then
we
return
it
here
and
that
actually
gets
assigned
back
into
stir.
One
right,
I
want
to
stop
for
one
second
and
talk
about
the
mute
keywords
here,
because
they're
kind
of
interesting.
A
First
of
all,
you
see
that
let's
go
back
to
the
main
function.
You
see
that
this
variable
stir
1,
which
is
inside
this
tuple.
The
can
be
declared
as
mute.
Really,
you
can
put
the
word
keyword
mute
now
to
any
variable
binding
wherever
it
appears.
So
here
we're
saying
the
variable
stir
one
is
mutable
and
the
reason
we're
saying
that
is
that
we're
going
to
assign
to
it
we're
going
to
move
out
from
it
here
and
then
reassign
it
here
all
right
so
because
we're
reassigning
it.
A
We
have
to
declare
it
as
mute,
since
that
introduces
the
possibility
that
if
we
read
from
it
twice
in
the
function,
might
we
are
actually
going
to
see
different
values
right,
because
this
new
assignment
is
going
to
have
the
concatenation
of
both
strings
in
a
second
interesting
thing.
Is
this
argument
is
declared
as
mute
and
when
you
declare
an
argument
is
moot
what's
sort
of
interesting
about
that
is.
It
looks
like
it's
part
of
a
function
signature,
but
actually
it's
really
kind
of
a
private
detail
of
joining
words.
A
The
caller
doesn't
care
because
the
caller
has
given
ownership
of
this
string
to
you,
so
they
can't
access
it
anymore
right.
So,
if
you
mutate
it,
it's
really
none
of
their
business.
So
when
you
see
mute
before
the
local
variable,
that
means
join
words
or
sorry
before
the
argument
name,
that
means
drawing
words
is
saying:
talk
to
itself
I'm,
going
to
mutate,
this
prefix
right.
Okay,
that's
what
this
code
is
doing
and
if
we
run
it,
we
expect
to
see
fellow
space
rust
stations.
Let's
do
that
yay
fellow
space
restrictions
great.
A
So
what
is
the
challenge?
The
challenge
is
to
convert
join
words
to
use
borrowing
instead
of
ownership
right.
So
the
idea
is
that
we
are
going
to
in
here.
Join
words.
Now
takes
ownership
of
two
strings
and
gives
back
a
third
or
ownership
of
a
string
we
want
it
to
do
is
to
mutate
these
strings
in
place
and
have
no
return
type
at
all
right.
A
So
these
two
arguments
should
be
some
kind
of
references,
so
there
should
be
no
ownership
transfer
happening
all
right,
I'm
going
to
leave
it
to
you
guys
to
go
ahead
and
give
that
a
try.
One
thing
I
want
to
point
out
a
lot
of
people
find
it
a
little
bit
tricky
to
get
everything
right.
So
you
might
like
to
take
a
look
at
this
hint.
If
you
get
stuck
just
open
that
URL
okay.
A
Good,
let's
go,
take
a
look
all
right,
so
we
said
we
want
to
do.
Is
mutate
the
strings
in
place
instead
of
giving
ownership
away,
and
then
we
want
to
stop
giving
ownership
back
so
I'm
going
to
do
this
in
pieces.
The
first
thing
I'm
going
to
do
is
say:
okay.
This
second
argument,
there's
really
no
reason
for
us
to
take
ownership
here.
We
actually
want
to
borrow
this
string
and
we're
only
going
to
read
from
this
string.
A
A
Basically,
we
were
doing
that
before,
because
we
were
going
to
take
ownership,
make
some
changes
and
give
you
back
a
modified
version,
but
now
we're
just
gonna
have
a
mutable
reference
directly
into
your
local
variable
and
mutate
it
right
there.
So
that
means
we
don't
have
to
have
a
return
type
at
all
and
take
away
I
should
tape.
A
A
One
last
point:
here:
you
see
this
keyword
mute.
We
actually
don't
need
this
keyword
here
at
all
and
that's
because
we're
not
reassigning
this
reference
right.
We're
not
changing
this
to
be
a
reference
to
some
other
string,
we're
just
mutating
the
data
that
the
reference
refers
to.
So
that
means
the
mute
here
suffices.
So
we
take
that
mute
away
and
we
run
the
code.
It'll
still
work,
just
fine,
okay,
great
okay,
so
that
was
the
challenge
I
just
like
to
make
a
few
other
minor
stylistic
adjustments.
A
First,
one
is
here:
you
see
I'm
taking
any
reference
to
a
capital
string.
That's
usually
not
a
very
useful
thing
to
do,
because
having
a
reference
to
an
entire
string
buffer,
isn't
usually
particularly
important,
it
doesn't
give
you
any
abilities
over
having
a
reference
to
a
subset
of
a
string
buffer,
at
least
a
shared
reference.
So
we
can
change
that
to
ampersand
stir
and
now
the
code
is
going
to
work.
Fine,
but
there's
one
other
thing
we
might
want
to
do,
which
is,
if
you're
pushing
an
entire
string.