►
Description
Felix S Klock II from the Rust developer team is presenting the state of the rust project in May.
In this issue we will debate on DST, Mut Apocalypse, String, end of ~ time and so many things!
Stay tuned!
Help us caption & translate this video!
http://amara.org/v/2Fh0/
A
Okay,
so
yes,
this
will
be
in
English,
because
my
French
is
nowhere
near
where
you
guys
are
at
so
I
thought.
I
would
just
go
over
a
couple
things
that
happened
since
the
last
meet
up
in
the
language.
A
B
A
A
Think
it's
not
gone,
but
the
libraries
at
this
point
it's
it's
on
its
way
out
and
then
the
I
think
that
cmr
had
the
best
word
for
this
other
thing.
This
is
not
a
change
in
the
language,
it's
actually
just
a
source
of
lots
and
lots
of
discussion.
Recently,
the
so-called
mute
apocalypse.
A
Okay,
so
this
will
the
first
one
will
do
really
quickly.
So
there
was
this
big
change
to
the
internals,
the
libraries
in
terms
of
how
we
structured
them,
but
I
user.
The
language
probably
sees
no
change
here
at
all
I'm
referring
to
the
lib
standard
facade.
So
as
a
user
of
the
language,
when
you
pull
in
the
standard
libraries,
you
often
start
off
your
coat
with
something
like.
A
A
There
is
implicitly
inserted
a
extern
great
reference
to
standard
and
that
external
crater
pants
is
still
there
and
standard
is
still
there,
but
the
structure
of
it
now
is
that,
instead
of
having
one
big
crate
for
standard
where
all
the
code
lives
instead,
now
it's
a
facade
over
many
smaller
crates
and,
to
be
honest
view,
I'm,
not
quite
sure
in
terms
of
the
actual
implementation
technology.
A
What
that
means
in
terms
of
whether
that
you
still
end
up
with
a
huge
binary
for
the
lip
standard,
great
when
it
all
gets
linked
together,
but
in
terms
of
editing
the
code,
if
you're
someone
hacking
on
the
library's.
Just
it's
useful
be
aware
of
this
facade
situation
where
now
there's
many
smaller
sub
crates
and
in
particular,
there's
one
called
limp
or
where
many
libraries
such
as
option
or
stir
others
like
Becker
slice
and
whatnot.
They
have
their
core
functionality
in
lib
core
and
then
there's
some
extra
stuff.
A
That's
gets
bolted
on
by
other
traits
and
whatnot,
and
then
everything
that's
pulled
together
into
one
composite
whole
for
that
piece
of
functionality
like
auction
or
back
or
whatnot,
and
then
re
exported
through
standard.
So
the
main
thing
I
want
to
mention
here
is
that
there's
been
times
recently
so
I'm
a
bad
person
and
I
don't
use
rust
doc
like
I,
don't
even
use
that
I
forget
running
rostock
I,
don't
even
look
at
the
web
pages
for
it.
A
I
don't
like
web
browsers
for
some
strange
reason:
I
really
shouldn't
be
working
here,
so
I
instead
go
straight
to
the
code
for
things,
and
so
there
was
this
shift
recently
where
I
went
to
go,
look
up
what
some
function
did
I
wanted
to
see
its
documentation.
I
tried
to
pull
up
its
source
code
and
I
couldn't
find
the
method,
because
I
was
searching
within
the
source
code
at
live
standard.
It
took
me
a
while
to
realize
that
I
needed
to
go
look
somewhere
else
for
it.
A
So
if
you're
having
on
internal
library,
just
be
aware
that
this
has
been
broken
down
to
many
sub
pieces
and
you'll
have
to
look
in
potentially
a
couple
different
places
to
find
what
you're
looking
for,
if
you
want
to
see
source
code,
but
that's
all
I'm
gonna
say
about
that.
It's
just
been
a
sort
of
interesting
internal
exchange.
Yes,
I.
A
Believe
the
main
reason
this
was
done
is
that
there's
some
pieces
of
functionality
that
we
want
to
offer
to
end
clients
who
don't
want
to
have
to
assume
certain
other
pieces
of
functionality.
So,
for
example,
if
you're
implementing
an
OS
kernel,
you
don't
necessarily
want
to
provide
support
for
failure
as
a
built-in
thing
that
libraries
can
call
out
to,
and
so
the
reason
for
this
refactoring.
I
believe
the
goal
is
that
lib
core
will
provide
functionality
that
is
truly
like
minimal
in
terms
of
it.
Won't
anything
within
here
can
call
out
to
fail
and.
B
A
That's
right,
so
that's
that's
exactly
my
understanding
of
what
the
motivation
for
this,
because
some
people
wanted
to
deploy
rust
in
certain
context,
and
they
were
unhappy
that
standard
had
so
many
so
much
stuff
built
into
it
that
they
couldn't
readily
deploy
it
in
those
contexts
that
embedded
environments
and
whatnot.
So
this
is
meant
to
for
wood
core
and
then
some
of
the
other
freestanding
crates
are
meant
to
provide
a
path
for
those
kinds
of
clients
to
pick
and
choose
which
creates
they
need
and
not
have
to
pull
an
all
a
standard.
A
So
yeah,
I
said,
like
I
said
before.
I
don't
know
if
that
means
that
everything
gets
ends
up
getting
duplicated
in
village
standard
when
it
pulls
everything
in.
I
suspect
it's
probably
something
where
dynamic
libraries
don't
get
duplicated
and
aesthetically
link
once
the
our
lib
format
that
pose
probably
get
you
know,
code
duplicated
into
the
our
lid
for
standard.
A
Yeah,
but
I
mean
in
terms
of
the
object
code,
its
generated
yeah,
I
know
I
don't
mean
cutting,
I
don't
think
the
codes
not
cut
and
pasted.
Obviously
not
no.
No
I
was
more
concerned
about
just
what
it
means
nervous
wreck
code
that
you
end
up
with.
Of
course,
if
you're,
you
know
just
making
a
final
prop
program,
no
final
binary!
You
don't
care
about
any
of
that.
Any
that
those
details.
A
It
depends
if
it's
gnarly,
if
you're
off
your
goal,
is
just
to
distribute
our
lib
an
hour
lib
for
just
for
lip
standard
without
any
other
three
stinging
libraries
and
it's
not
a
bug,
it's
actually
what
you
want.
I
just,
don't
know.
What's
what
the
situation
is
now
I
haven't
tried
to
deploy
in
such
contests?
A
Okay,
next
the
detail,
ding
of
things
I,
don't
know
how
much
history
I
was
just
sitting
here
wondering
to
myself
how
much
history
to
get
into
this
about
y
tilde
used
to
exist
and
why
we're
getting
rid
of
it.
I
think
just
to
make
this
nice
and
quick
I'll
go
over
what
the
changes
were,
and
then
people
can
come
up
to
me
and
talk
to
me
about
it
afterwards.
They
want
to
get
more
into
the
heavy-duty
details
about
why
things
were
the
way
they
were.
A
This
change,
though,
the
point
the
main
point
I
want
to
get
across
is
that
the
length
we
are
trying
to
make
the
language
more
uniform
in
a
number
of
places
and
to
get
rid
of
certain
special
case
constructs.
That's
if
nothing
else,
the
detail
dating
of
certain
constructs
that
I'm
about
to
show
you
hopefully
I
can.
A
We
had
a
rule
like
this.
If
you
had
a
tie
and
by
type
I
mean
something
that
the
compiler
knew
the
size
of
statically.
So
if
you
had
a
type
like
I
32
for
a
32-bit
integer
or
a
type
like
I,
64,
I
64
to
bowl
containing
to
64-bit,
integers,
otherwise
notice,
you
know
128
bits
of
stuff
right
there.
These
things
like
this
er
types
they
have
sizes
and
the
compiler
assert
operations.
It
knows
about
for
them.
So
these
are
examples
of
some
type
that
I'll
just
labeled
T.
A
So
these
are
possibilities
and
there's
many
others.
There
was
a
rule
in
the
past
very
recent
past
that
for
any
type
T
and
by
that
I
mean
a
sized
thing
that
has
static
sizing,
prime
minus
about
you
could
write
down
tilda
tea
and
that
represented
a
pointer,
an
owned
pointer
to
a
tee
on
the
heat
on
a
special
portion
of
the
heap
that
was
dedicated
to
things
that
you
could
potentially
send
between
different
tasks.
And
this
thing,
since
it
was
a
pointer
to
you,
know
some
other
size
type,
it
always
had
itself.
A
A
In
general,
most
types
you
write
down
in
rust,
there's
a
notion
of
ownership
for
them
like
when
I
write
down
the
type
I
32
and
I
right
al
Qaeda
stack
of
locals
on
my
stack
frame
for
that
I'm
expression,
expressing
ownership
of
that
I
own,
the
I
32
that
I
have
in
that
stack
dream
anyway.
The
point
is
that
was
the
notation
for
allocating
some
type
like
these
or
many
others,
structures,
enums
etc.
On
the
heap.
Then
there
was
a
couple
other
interesting
cases.
There
was
in
particular
a
vector
type.
A
Their
mental
model
was
whenever
I
see,
tilde
I
can
take
it
off
and
I
get
a
tight
like
I
can
deconstruct
it
the
same
way
and
look
at
that
and
mentally
think
of
whatever
is
behind
the
tilde,
whatever
comes
after
it
as
a
type
as
well,
and
the
problem
with
that
kind
of
reasoning.
Are
these
these
two
cases
exactly
when
I
say
till
the
T,
where
T
is
a
size
type
I
knew
for
some
tea?
A
B
A
Are
special
cases
and
a
big
problem
with
that?
Is
that
when
you
had
some
people
trying
to
explain,
you
don't
need
to
use
this
form
till
the
t.
In
fact,
you
probably
should
avoid
it,
and
you
should
avoid
tilde
people
heard.
That
said,
wait
I'm
supposed
to
avoid
these
two
things,
and
then
the
response
was
no.
No
I
don't
mean
that
tilde
I
mean
this
tilde
up
here,
and
it's
very
confusing
at
that
kind
of
conversation.
A
So
for
many
reasons,
but
I
like
to
think
of
those
being
the
ones
that
I
can
really
get
my
heart
and
soul
behind.
We
shifted
the
language
of
it
so
that
we've
gotten
rid
of
these
tilde
constructs
instead
in
our
brave
new
world,
instead
of
writing
till
the
T
as
a
type
and
likewise
the
way
to
write
expressions
of
this
type
was
the
same
tilde
and
then
some
expression,
for
example,
till
the
three
or
tilde
open.
A
Our
brave
new
world,
what
you're
right
said
for
the
type
is
box
of
tea,
because
it
represents
a
boxed
thing
on
the
exchange
heap
and
for
the
expression
format.
You
write
a
lowercase
box
and
then
the
expression
there's
technical
details
for
why
there's
a
key
word
here.
This
is
actually
a
keyword
box.
I
don't
want
to
get
into
it
right
now,
except
the
simplest
answer
I
can
give.
A
You
is
that
this
is
our
path
going
forward
for
supporting
placement
new
arm
type
things
I
mean
it
already
gives
us
the
very
literal
meaning
of
placement
new,
as
originally
written
in
C++,
but
we
want
to
be
able
to
override
it
and
have
special
behaviors
the
same
way.
C++
offers
for
certain
types
lots
of
details.
I
don't
want
to
get
into.
Did
your
question
Simon.
A
That's
correct,
my
understanding
is
that
I
believe
that
I
don't
know
the
exact
plan
going
forward
in
terms
of
whether
these
two
will
be
tightly
intertwined,
but
I
definitely
know
that
this.
This
format
has
written
here,
yields
this
kind
of
thing
and
then
there's
a
different
form.
That
would
look
something
like
box,
open,
paren
and
then
the
special
type,
a
description
of
the
type
you're.
A
Sure
of
that
it
might
be
that
the
goal
is
that,
in
fact,
maybe
that
yields
a
thought
to
T
and
there's
an
optional
type
parameter
here,
signifying
the
distinction
I'm,
not
one
hundred
percent
I,
don't
remember
to
be
honest:
what
the
current
plan
is
there,
but
it
doesn't
matter
because
we
don't
really
have
good
support
for
this
format
yet
anyway,
so
pretend
I,
didn't,
say
anything
about
that
and
just
keep
in
mind.
This
translates
to
this
direction.
A
So
if
you're,
looking
at
old
code
bases,
you
know
if
you
go
to
bite
and
if
you
go
to
somebody
asked
me
recently
about
my
ncurses
library
and
I,
haven't
upgraded
that
in
months,
like
I,
haven't
tried
to
compile
it
against
rust
and
months.
So
you
know:
there's
lots
of
old
code
lying
around
up.
There
that'll
make
use
of
these
three
things.
So
if
you
see
this,
it
gets
turned
into
box
of
tea.
B
A
And
there's
other
slight
distinctions
like
the
representation
of
this
is
weight
was
represented,
was
a
single
word
pointing
to
a
structure
on
the
heap
that
carried
the
capacity
of
the
vector,
its
actual
allocated,
length,
initialized
leg
and
then
the
actual
payload
of
the
series
of
elements
that
it
points
to.
So
that
was
so.
This
was
this
was
one
pointer
pointing
to
something
that
had
three
plus
K
words
on
it,
this
one
here
it
shifts
things
around
a
little
bit
so
that
this
thing
is
three
words
long.
It
carries
its
own.
A
No,
yes,
this
carries
its
own
capacity
and
it's
had
it's
initialized
length
at
a
pointer
to
the
payload.
There
were
details
about
why
we
did
it
this
way.
The
simplest
one
is
that
it's
expensive
to
out
even
an
allocating
and
zero
sized
version
of
this
is
expensive
because
you've
got
the
pointer
and
you
have
to
actually
allocate
on
the
heap
something
that's
three
words
long.
A
So
if
you
mean
an
array
of
zero
of
FMT
vectors,
you
had
to
fill
it
for
every
one
element
on
the
array
had
to
allocate
a
separate,
tiny
object
and
with
this
version,
what
you
do
instead,
if
you
make,
if
you
want
to
make
an
array
of
empty
vectors,
you
just
make
the
array
initialize
it
all
at
once.
You
don't
have
to
make
individual
allocations
for
HP
each
payload
because
use
null
for
the
zero
initialize
things.
That's
an
example
of
why
we
did
this
this
way
and
then
push
turb.
A
The
current
story
here-
and
this
is
still
a
source
of
ongoing
discussion-
is
what
to
name
stir,
because
the
part
of
story
that
I
haven't
talked
about
here
is
for
everyone
of
reach.
Twenty
three
types
where
this
piece
is
the
own
thing
on
the
heap.
This
is
the
own
vector
own
global
vector,
and
this
is
the
own,
or
this
was
the
old
oval
vector,
and
this
is
the
own
growth
string.
There
was
a
corresponding
borrowed
type
that
uses
ampersand,
ampersand
t
a
slice
type
of
ampersand
bracket
and
a
third
type
of
ampersand
stir.
A
So
the
question
now,
for
some
reason
it
was
really
easy
to
do
this
renaming
in
terms
of
getting
people
to
sign
on
to
this
shift,
but
would
stir
I
just
said:
this
fell
right
down:
ampersand
TR
till
the
team.
There's
now
there's
a
corresponding
efforts,
antsy
for
for
an
alias
share,
an
alias
borrow
thing
appoints
to,
and
likewise
there's
a
borrowed
slice
and
finally,
there's
a
borrowed
string
slice.
The
question
is:
okay,
we
found
the
translation
of
Vista
box.
A
The
question
is:
what
should
we
called
niche
over
here
on
this
side?
What
should
stir
be
calm
and
there
is
a
big
thread
on
github,
with
lots
of
ideas
and
lots
of
puzzles
I'm
not
going
to
get
into
which
ones
were
saying
and
which
ones
weren't
I'll
just
tell
you
where
we
are
right
now
today
and
say
it
is
absolutely
temporary,
as
in
the
plan
of
record.
Is
that
a
temporary
and
if
we
happen
to
keep
the
way
things
are
today
it's
for
no
good
reason,
the
other
than
inertia.
A
So
right
now
till
the
stir
gets
translated
to
something
called
sturb
up,
meaning
that
it's
a
string.
That's
got
an
allocated
buffer
of
stuff
and
thus,
if
you
can
grow
it
by
writing
into
that
buffer,
as
opposed
to
a
slice
where
you
can't
grow
a
slice,
you
just
have
it's
it's
a
pointer
into
some
free
allocated
space
and
you
don't
have
any
control
or
knowledge
about
what
lies
outside
those
bounds.
So
slice
you
can't
grow
or
shrink.
So
that's
how
those
things
are
translated.
Now
and
finally,
let
me
talk.
A
We
talk
mute
apocalypse
now,
I'm
debating,
but
what
I
really
want
to
get
into
this,
that
much
I
just
even
writing
down
the
stir.
Buff
thing
like
I
thought
that
debate
was
hard
and
you
talkable
apocalypse
has
sort
of
become
even
worse,
I'll
quickly
outline
at
least
the
big
ideas
of
what's
happened
and
what
was
proposed.
A
I
guess
so,
nothing's
changed
know
what
so
everything
I
just
have
talked
about
so
far
are
changes
that
in
the
language,
since
the
last
time
we
met
a
month
ago,
I
think
roughly,
this
is
not
a
change.
That's
happened
in
the
language
since
we
met
it's
a
discussion
of
a
potential
change
in
the
future,
but
it's
possible
that
nothing
will
happen
in
it
that
we
won't
change
anything,
that's
one
of
the
options
and
the
tables
did
not
change
this
at
all.
A
A
A
The
points
is
that
in
Nico's
blog
post,
you
made
a
point
of
saying
that
there
are
some
problems
that
come
up
where,
if
you
have
some
gave
us
a
couple
examples
one
was.
He
gave
an
example
of
refactoring
code
where
your
started
with
some
code.
That
looks
something
like
this.
Maybe
there's,
let's
see
here
without
the
mute
notation,
he
first
noted
a
situation
where,
if
you
try
to
refactor
your
code
and
introduce
a
sub
a
subroutine
somewhere.
A
That
just
says
that
infectious
says
this
is
a
shared
reference
to
Y
and
a
shared
reference
to
Y
is
one
that
many
people
could
have
their
hands
on
and
plus
you
don't
have
the
right
to
mutate
x3.
So
that's
not
good.
You
can't
express
an
alias
access
that
way
and
if
you
say
ampersand
you
problem
there
is
that
the
original
programmer
didn't
write.
Let
you
why
they
only
wrote
let
why,
and
so
you
can't
take
that
kind
of
you
can't
do
that
kind
of
borrow
either.
A
Access
and
immutable
in
the
sense
of
I
can't
change
Y
itself.
I
can
change
if
Y
points
to
something
me
to
bleah,
or
why
is
a
structure
that
has
a
field
that
points
to
something
natively?
If
I
have
money
at
least
access
to
that
structure,
I
still
have
the
right
to
me.
Two
things
at
points
too:
I
just
don't
have
the
right
to
mutate
the
thing
itself,
so
we
pointed
out
there's
this
idea
of
immutable
but
nalea
stacks
s
and
he
gave
a
couple
different
potential
names.
A
So
this
is
sort
of
an
interesting
notion
to
try
to
pull
out
this
annales
access
to
data,
and
then
he
pointed
out
in
his
blog
post.
The
next
example
he
gave
involving
closures.
He
actually
pointed
out
that
the
way
we
implement
closures
today,
they
already
have
support
for
this.
This
kind
of
construct
in
the
language
itself,
not
in
the
language,
but
in
the
type
system
for
the
language
we
already
have
it
implemented.
So
this
led
Niko
to
sit
to
ask.
A
Immutable
distinction
may
not
matter
so
much
as
much
as
focusing
on
shared
versus
on
a
list
so
nico
put
forth
the
proposal
to
get
rid
of
the
mute
keyword.
He
had
a
bunch
of
proposals
that
he
put
up
there,
the
one
he
said
was:
maybe
we
should
get
rid
of
the
new
keyword
all
variables
he
declare
are
implicitly
mutable
and
the
control
over
whether
you're
a
lot
of
mutated
or
not.
A
The
borrowed
sugar
can
figure
out
based
on
what
you've
done
with
it,
whether
you've
actually
given
up
shared
access
to
it
and
thus
I
should
be
treated
immutably
or
if
you
kept
unique
access
to
it,
kept
on
alias
access
to
it,
and
thus
you
can
mutate
it
safely.
So
one
of
his
proposals
was
to
just
get
rid
of
the
new
keyword
to
stop
saying
letting
mute,
you'd
still
say,
ampersand,
something
it
would
bite
me
ampersand
unique.
It
might
never
see
in
my,
but
just
focusing
on
that
part
of
things.
A
A
Language
doesn't
stop
you
from
making
certain
kinds
of
types
where
you
don't
have
the
new
keyword,
but
there's
still
some
mutable
state
owned
in
that
part
of
the
system.
In
particular,
the
cell
data
type
is
one
where
you
can
have
a
structure,
some
sort
of
structure
here
inside
of
it
there
can
be
a
cell
of
integer
and
what
essentially
happens
is
that
I
can
pass
Z
around
with
a
shared
access
to
it,
and
people
will
have
that
pointer
to
Z
are
free
to
mutate,
the
cell.
A
It's
a
special
it's
a
special
type
it
submitted
with
unsafe
code,
but
it's
ensures
that
you
still
can't
get
data
races
in
the
sense
of
you
can't
anoint
put
certain
kinds
of
types
in
a
Cell.
Basically,
so
it
ensures
that
you
aren't
going
to
get
into
certain
kinds
of
problems
they
were
hit
if
you
just
allowed
unfettered
construction
of
such
things,
so
the
community
at
large,
a
lot
of
people
invested
a
lot
of
time.
Learning
about
this
problem
and
then
proposing
counter
proposals
for
trying
to
basically
get
rid
of
this
case.
A
A
A
If
you
assume
our
current
approach,
the
closures,
but
they
pointed
out
that
our
current
approach,
the
closures,
isn't
necessarily
what
we
want
long
term
anyway,
and
that
a
shift
to
a
different
kind
of
closure,
an
unboxed
closure
where
you
don't
have
don't
physically
take
references
all
the
time
and
said
you
copy
values
in
or
move
values
in
much
more
often
gets
rid
of
the
problems
that
nikka
was
pointing
out.
A
So
that's
sort
of
a
quick
or
attempt
at
a
quick
overview
of
this
space
of
discussion,
because
there's
a
lot
of
noise
about
it
and
it's
gotten
a
lot
of
people.
A
little
tired.
I
mean
the
reddit,
the
reddit
page
for
a
rust.
I
noticed
today
said
something
like
rusts
is
tired
of
talking
about
mutability.
They
change
the
title
page
for
it,
because
they
just
got
frustrated
with
this
discussion,
how
many
subreddits,
or
how
many
self-posts
were
coming
out.
The
people
addressing
this
question
so
my
take
on
this
is
that
I
don't
know.
A
What's
going
to
happen.
I
was
personally
most
interested
in
a
side
thread
of
Nico's
discussion,
which
was
the
idea
that,
since
we
already
have
support
for
this
tight
anyway,
when
we
add
support
for
it
in
the
language
without
getting
rid
of
anything
else,
we
have
and
I've
been
looking
a
little
bit
at
that.
But
the
reality
here
is
I.
Don't
want
to
complicate
the
language
too
much,
which
is
a
big
fear
that
people
have
historically
rust,
had
many
pointer
types
and
many
a
lot
of
syntax
for
different
pointer
types.
A
There
was
the
at
sign
for
garbage
collected
storage.
There
was
the
tilde
for
own
stuff
and
there's
still
the
ampersand
for
a
borrowed
reference
and
we've
come
quite
a
ways
to
try
to
reduce
the
number
of
syntactic
concepts
and
trying
to
make
them
all
look
like
library
types
and
the
question
is
with
the
introduction
of
a
type
like
this.
This
is
actually
buy
you.
Anything
even
Nico
didn't
want
to
just
add
unique
without
getting
rid
of
something
else
his
for
he
stayed
in
his
blog
post.
A
He
said
he
wanted
to
consider
getting
rid
of
Glen
mutes
and
replacing
efforts.
Have
you
with
something
else,
but
even
he
said
of
like
the
four
options
he
put
down,
he
was
like
if
the
one
that
he
was
arguing
board
didn't
pass,
muster
that
he
didn't
want
to
change
anything.
So
my
suspicion
is
given
how
much
commotion
there's
been
in
the
community.
Is
that
I
just
wasted
all
of
your
time?
A
Let
mute
it's
obvious
once
you've
worked
with
the
compiler
for
a
while,
if
it's
possible,
just
because
the
compiler
internally
uses
tricks
like
this
all
over
the
place,
but
still
it's
worth
being
aware
of,
but
some
of
the
reasoning
principles
that
you
might
think
you
can
apply
if
you're,
just
somebody
who
knows
about
the
lambda
calculus
and
assumes
Oh
functional
programming,
this
kind
of
looks
like
functional
programming,
I
guess,
I
get
referential,
transparency
and
I
can
just
substitute
equals
4
equals,
and
the
answer
is
no.
No.
A
We're
not
we're
not
at
that
point
and
I
don't
plan
to
be
at
that
point.
These
markers
are
about
something
a
bit
more
subtle
than
that
okay,
so
that
was
sort
of
my
overview
of
some
big
crazy
things.
A
Think
that
that's
the
big
story
here
is
that
our
documentation
tutorial
still
need
improvement.
I
think
my
undersized
recently.
My
understanding
is
that
there
is
treatment
of
this
distinction
of
what's
called
interior
mutability
versus
inherited
mutability.
It
is
treating
the
tutorial,
but
I
haven't
looked
at
that
section
recently,
I'm
not
sure
if
I
ever
looked
at
it
like
it
was
added
after
I'd
already
read
through
the
tutorial.
You
know
in
state
at
that
point,
so
my
suspicion
is
that
there's
two
things
I
think
that
might
happen.
A
One
is
that
the
documentation
needs
to
be
improved,
but
also
I
suspect.
We
might
see
a
shift
in
the
terminology
we
use
internally.
I
suspect
that
it
might
part
of
the
problem
might
be
that
we're
using
terms
that,
like
even
just
saying
interior
versus
inherent
those
are
two
words
that
sound
very
similar
to
each
other.
So
maybe
we'll
see
a
shift
where
we
start
choosing
better
words
for
things
or
maybe
not
I,
don't
know,
but
yeah
I.
Think
I.
Think.
The
biggest
lesson
here
is
about
education.
More
than
anything
else,.
C
D
A
I
think
Nick's
working
on
it
I
think
it's
very
spending
all
is
I'm
on
in
New
Zealand,
so
DST
stands
for
dynamically
sighs
types
and
in
fact,
I
can
refer
back
to
an
earlier
slide.
A
That's
not
the
size
of
statically
and
the
reason
that
this
is
really
important
is
that
so
these
are
two
interesting
special
cases
when
you
take
off
the
tilde,
but
the
big
one
is
trade
objects,
because
Nico
noticed
that
you
know
this
is
kind
of
interesting
that
these
two
things
have
a
size
are
sorry,
these
two
things
have
a
dynamically
known
size
and
you
could
represent
them.
I
mentioned
before
I
think
that
the
current
representation
for
these
two
things,
or
at
least
this
first
one
I,
think
the
second
one
as
well.
A
It's
just
a
pointer
to
a
capacity
length
and
the
payload
data
when
Nikko
pointed
out
is
that,
with
some
wisdom
fiddling
around
you
could
switch
things
around
so
that
for
an
unsigned
behind
one
of
these
sigils,
you
could
represent
that
as
a
pointer
to
the
payload
plus
an
additional
word
on
the
pointer
itself.
That
represents
a
metadata
in
particular
for
arrays
and
for
Strings.
It
would
represent
the
length
of
the
thing,
but
the
cool
part
is
that
for
trade
objects,
that
extra
metadata
word
would
represent
the
veet
able
to
do
method
dispatch.
A
So
that's
DST
in
a
nutshell,
dynamically
size
types
and
the
important
thing
is
that
adding
that
to
the
language
will
make
it
to
that.
Right.
Now,
right
now,
if
you
want
to
implement
some
methods
or
some
traits
for
a
type,
you
often
have
to
duplicate
code,
where
you
have
to
write
down,
make
one
implementation
for
box
of
array
or
for
tilde
array
and
make
another
communication
for
a
borrowed
array.
Even
though
the
actual
code
you
write
down
for
all
the
methods
is
the
same
code
for
both
cases.
A
The
only
reason
why
you
had
to
make
the
two
separate
implementations
is
because
the
info
forum
needs
to
have
infiltrate
for
tight,
as
in
t
as
an
assize
thing
and
Nico's
proposal
for
DST
lets.
You
actually
express
infiltrate
for
both
size,
t
or
fir
and
unsigned
T,
and
so
you
get
to
you,
get
to
not
repeat
yourself
and
just
write
down
the
input
once
for
all
possible
kinds
of
arrays,
be
they
owned,
arrays
or
slices
to
arrays
and
hopefully
also
for
other
kinds
of
smart
pointer
types.
A
That's
the
big
one
is
that
we
are
looking
forward
to
having
many
kinds
of
smart
pointers
in
the
language
reference
counted,
garbage
collected,
they'll
all
be
expressed
using
either
box
or
something
like
box
GC
of
TRC
of
tea,
etc.
So
you
don't
want
to
have
to
rewrite
all
your
impulse
for
every
single
pointer,
type,
variance
and
DST
is
part
of
the
story
that
gets
us
there.
Ok
sum.
B
C
C
A
I
think
that
once
you
have
DST
there's
a
uniform
story,
so
the
reality
is
that
DST
gives
you
a
uniform
story
for
all
this
stuff
in
a
sense,
so
I
said
before
how
a
pointer
to
a
size
thing
becomes
one
word
and
then
a
pointer
to
a
nun
size
thing
that
comes
to
words,
and
so
what
you'll
see
is
that
you'll
explain
this
construction
and
this
construction
and
this
construction
via
DST
you'll,
say
in
this
case
you
decompose
it
as
a
borrower
pointer
to
what's
this
thing.
Is
it
a
size
thing?
Okay,
then?
A
That
means
you
use
the
size
type
path
in
terms
of
your
reasoning
about
what
this
does
in
terms
of
mapping
to
one
single
word
of
memory,
it's
a
pointer
just
to
that
thing
versus
the
unceasing
swear.
Oh,
you
have
ampersand
and
you
have
a
brackets
here,
and
that
means
that,
and
it's
brackets
without
it
without
an
explicit
length,
so
you'll
explain
that
by
saying
it's
a
nun,
size
thing.
A
So
the
important
detail
there
is
that
there's
a
unified
story
where
this
becomes
one
word,
and
each
of
these
becomes
two
words
and
in
one
version
of
the
proposal
we
actually
kept
all
these
sin
taxes
and
in
a
sense
they'll
still
be
around
after
DST
lands.
In
particular
I
said
that
till
the
team
goes
to
box
of
tea.
A
The
problem
is
that
they're
not
very
useful,
because
the
way
DST
dictates
things
what
you
end
up
in
a
new
box
of
the
array
or
box
of
stir.
Is
you
end
up
with
a
pointer
to
the
payload
and
then
another
word
for
the
metadata,
which
would
just
be
the
length
of
the
thing
you
have
and
you
don't
necessarily
have
the
ability
to
grow
or
shrink
it
easily.
A
The
back
and
stir
buff
representations
are
special.
These
are
specialized
representations
for
these
two
special
cases,
because
you
want
three,
you
want
both
the
capacity
and
the
length
because
you
want
it
pre-allocate
extra
space
to
grow
and
shrink
within.
If
you
do
it
with
box,
the
DST
story
doesn't
give
you.
A
The
two
words
doesn't
give
you
the
length
and
the
capacity
you
only
get
to
have
one
of
them,
and
so
the
answer
there
is
that
you
could
I
believe
you'll
be
able
to
write
it
down,
and
there
was
debate
internally
for
a
long
time
as
to
whether
it
would
be
useful
to
be
able
to
write
it
down
whether
our
library
should
still
continue
to
try
to
push
to
use
the
equivalence
of
these
types.
A
But
at
this
point
the
community
has
pushed
back
enough
and
presented
a
pretty
compelling
argument
that
you
won't
want
to
use
box
with
array
or
stir
in
most
cases.
In
most
cases,
you'll
want
to
use
back
and
stir
buff
the
most
compelling
counter
case.
The
most
compelling
counter
argument
that
I
have
to
that.
So
this
is
three
words,
and
this
is
three
words,
and
this
will
be
two
words
for
none
size
type,
and
likewise
this
will
be
two
words,
and
this
will
be
two
words.
A
The
only
compelling
case
I
have
to
use
box
of
tea
with
on
size
thing.
Is
that
they'll
be?
There
are
rules
that
let
you
take
an
array
of
these
thing
up
an
array
of
these
things
like
I'm,
talking
about
a
vector
of
boxed
vectors
or
a
vector
of
box
strings.
There
are
rules
that
what
you
take
that
and
amelie
transmute
it
to
a
borrowed,
a
vector
of
borrowed
vectors
or
a
vector
of
borrowed
stirs
because
keep
in
mind.
This
is
words.
A
This
is
two
words,
so
an
array
of
length
K
is
going
to
be
K
times
two
words
long.
You
can't
amelie
transmute,
an
array
of
that's
an
array
of
X
is
going
to
be
K
times
three.
You
can't
just
take
that
and
amelie
transmute
that
to
a
borrowed
array
of
borrowed
vectors,
it
doesn't
work
because
the
size
is
don't
let
the
layouts
don't
match
up.
You
have
to
do
something
to
convert
each
one
of
those
entries
from
a
three-word
thing
to
have
to
word
thing,
so
this
is
the
best
thing.
A
The
best
reason
I
had
the
push
to
keep
using
box.
Even
with
these
two
cases,
and
it's
pretty
hard
to
support
that.
It's
a
question
of
whether
that
case
arises
sufficiently
often
to
warrant
making
your
whole
standard
library
had
to
deal
with
these
cases.
I,
don't
know
what
that
answered
your
question.
It
was
probably
way
detailed.
My.
C
A
We
definitely
I
think
want
that
and
sterba,
although,
like
I
said
there
was
some
debate
internally
about
you
want
them
as
concepts
regardless.
The
question
is
whether
you
want
to
ever
encourage
use
a
box
of
this
and
box
of
that.
You
definitely
want
that
concern,
but
even
if
you
had
box
of
this
and
lots
of
that,
you
want
that
can
disturb
up
as
concepts
what
rust
used
to
do,
since
it
recognized
that
box
of
achenbach
sister
are
not
useful
and
that
these
two
things
that
these
were
things
are
useful.
A
The
conceptual
hack
they
used
was
to
use
the
same
notation
to
represent
these
very
different
things.
They
basically
Graydon
horror
I,
think
recognize
that
these
two
things
are
so
useful.
Let's
give
them
a
really
sweet
sugar,
but
the
problem
with
that
reasoning
is
that
it
makes
it
really
hard
to
one
learn
the
language
and
to
it
complicates
things
like
DST,
where
you
really
like
to
be
able
to
have
a
uniform
treatments
for
everything
on
the
other
side
of
the
tilde
or
everything
on
the
others.
Other
side,
the
ampersand.