►
From YouTube: 2020--12-03 RFC 2229 Interview
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
One
is:
is
this
really
issue
with
our
thing
or
more
of
something
we
need
to
deal
with
in
migration,
because.
C
B
C
Probably
yes,
like
I
don't
think
I
want
people
to
have
to
write.
Let
s
equals
s
to
write
to
write
that
closure.
I,
which
one
are
you
talking.
A
The
first
or
second
one
like
looking
at
the
regardless
of
which
one
you
do.
I.
A
First,
one
is
dealable
because
you
can
just
drop
the
trailing
data
and
we
can
just
we're
good
with
it.
But
again
the
question
comes
down
to
what
should
what
is
the
expected.
Behavior
like
like
dropping
trailing
ddrs,
is
to
get
the
code
in
the
compiler
today
to
work,
but,
like
the
real
question
is
what
should
actually
happen.
I'm.
C
Like
you,
what
so,
why
would
I
say
that?
Because
for
one
thing,
that's
where
the
backwards
and
compatibility
issues
primarily
arise,
not
not
only
because
it's
possible
to
move
things
even
outside
of
a
move
closure,
but
primarily
and
suck
this
this
example.
This
second
example
is
really,
I
don't
know,
I'm
kind
of
struggling
with
it
like
I
don't
like
this.
A
C
I
don't
know
that
there
that
I
think
it
might
still
be
that
you
take
all
the
variable
because
yeah
I
feel
like
that
code
should
work
and
that's
the
only
way
that
code
compiles
and
if
you
don't
the
problem,
is
this,
so
we
can
make
that
code.
I
don't
exactly
know
how.
But
let's
say
we
said
something
like
in
a
move:
closure.
C
A
Well,
what
I
was
thinking
was
modern,
well,
a
that's
incorrect
right,
because,
if
you're
expecting
s
dot
x
to
let's
say
this
example
be
moved
or
because
you're
expecting
everything
to
be
moved,
then
that
to
be
moved
like
the
solution
around
this
I
was
thinking
was
more
around
outside
of
the
closure.
We
add
a
line
which
is
basically
ampersand
mute
s,
dot
x.
So
we
have
a
mu
outside
the
closure.
C
I
don't
know
where
we
have
like
a
hacking
right.
It's
kind
of
it
was
kind
of
created
for
a
different
problem.
The
let
underscore
x
equals
problem.
C
A
Okay,
I
I
created
a
issue
for
this.
Let
me
just
add,
I
marked
it
as
migration,
but
if
we
can,
of
course,
remove.
C
C
C
Oh
I'm
back
now,
so
let's
see.
A
A
Yesterday,
but
we
can
just
remove
it
if
we
feel
like,
like
my
initial
instinct,
was
this
might
be
that
but
yeah
we
can
label
it
accurately.
C
C
C
Tabs,
okay,
here
we
go
so
here
are
some
thoughts.
Also,
you
know
what
the
issue
again
it
was
here.
It
is
so.
The
first
thing
is
here's
the
example.
C
What
did
I
want
to
say
about
this
example?
I
wanted
to
say
right:
what
would
you
de-sugar
this
closure
to
so
option?
One
you,
you
could
imagine
that
this
closure
gets
sort
of
internally
de-sugared
to.
C
C
C
C
It's
borrowing
the
referent
of
this
other
reference
so
like
it's
not
into
the
stack
it's
into
borrowed
memory,
so
in
other
words
this
the
type
of
this
thing
would
be
like
amute
string
of
you
know
whatever
this
or
the
type
could
be
this
and
and
therefore
could
be
returned.
C
I
think
the
more
interesting
right
signature
might
be
something
like
this,
because
this
gets
at
the
idea
that
this
needs
to
be
returnable
so
right.
So
we
would,
you
would
be
able
to
return
it
and
the
way
that
the
borrow
checker
works.
These
days
like
you
might
think
that
this
would
make
s
be
borrowed.
There's
another
weird
case
where
if
this
was
mute,
and
you
sort
of
did
this,
that
would
be
legal
with
a
move
closure,
because
there
was
a
value
in
s
now,
there's
not
a
value.
C
Now,
I'm
putting
a
new
value
in
it
might
not
be
legal
or
the
non-move
closure.
Under
some
circumstances
it
wouldn't
be
legal
because
s
would
not
be
borrowed
not
moved,
but
in
this
case
again
because
we
are
passing
through
the
through
the
reference,
the
borrow
checker
has
rules
to
understand
that
it's
okay
to
reassign
s.
In
that
case,
I
think
this
would
like
mostly.
A
Work
as
a
de-sugaring,
my
my
concern
is
when
you
look
at
like
when
you're
trying
to
write
the
ampersand.
Sorry,
when
you
try
to
write
the
line
14,
you
have
the
section
where
you
d
ref
s
and
dot
x.
I
am.
I
think
this
should
be
fine,
because
we
add
another
ampersand
kind
of
like
we
take
the
mute
reference
here,
I'm
very
depending
on
how
we
do
it
like.
We
need
to
be
careful
that
it
doesn't
think
we're
trying
to
move
again
star
s
dot
x
here,
which
would
again
think.
A
So
when
we
write
like
the
d,
when
we
look
at
line
14
and
we
look
at
like
the
just
the
star
as
dot
x
part,
I
I'm
assuming
when
we
do
this
in
merbuil,
it
will
be
able
to.
It
will
be
able
to
realize.
C
A
A
C
C
Should
be
able
to
also
do
this
and
it
should
all
compile
yeah,
okay.
Now
the
question
would
be.
How
do
we
know?
C
A
I
think
what
we
can
do
is,
and
the
smart
solar
well,
let's
solve
the
immutability
problem
as
well,
is
instead
of
storing
by
value
when
we
have
a
move
closure.
We
store
two
pieces
of
information
which
is
like
this
was
what
kind
of
borrower
we
determined
based
on
capture
analysis
and
what
we
are
forcing
it
to
be
based
on
the
capture
calls
being
moved
so.
C
C
C
C
C
A
C
B
C
B
A
C
This
is
an
I
kind
of
think
when
you're,
I
think
the
rules
for
move
closures
are
gonna
need
some.
The
rules
for
move
closures
and
drafts
are
pretty
interesting.
I
think
they
probably
want
to
stop
it
drifts.
If
it's
sorry
a
move
of
a
box,
you
probably
want
to
stop
the
move
there
and
just
take
the
whole
box.
C
Enough,
I
mean
not,
I
guess,
but
it
doesn't
like
it's
not
obviously
right
to
me.
C
Well,
that
depends
but
yeah,
that's
not
true
for
there's
a
subtle
distinction.
If
it's
a
and
mute
star,
but
sir,
it's
not
a
bad
idea,
it
might
be
the
right
rule
it
doesn't
it's
not
always
going
to
do.
C
The
right
thing
where
the
right
thing
is
no
rule
will
like
it's
a
little
bit
subtle,
but
what
you
actually
want
to
capture
is.
A
A
Only
but
the
things
that
were
failing
when
I
was
trying
to
build
up
standard
were
similar
situations,
as
my
first
example
for
this,
which
is
like
we
don't,
have
a
path.
You
just
have
a
dereferenced
structure,
so
removing
trailing
dds
kind
of
fixed
it
and
what
we
ended
up
at
was
like
with
the
unsafe
issue,
where,
like
the
unsafe
block
issue
that
I
shared
earlier,
where
you
you're
trying
to
dereference
a
raw
pointer,
which
again,
I
think
at
some
point
we
need
to
like
need
to
truncate
those
as
well.
C
C
C
C
Sum
or
something
in
your
closure
and
it's
a
move
closure
we're
now
going
to
capture
x,
dot,
zero,
which
is
really
inefficient,
and
it
would
have
been
much
better
if
we
just
captured
x-
and
I
don't
know
that,
there's
like
a
r-
I
don't
think
you'll
ever
get
that
right.
All
the
time
like
right
now,
you
have
probably
other
inefficiencies
where
you
capture
a
big
root
variable,
but
you
only
use
one
field
of
it
and
it's
silly
to
capture
the
whole
thing.
A
A
Like
my,
my
concern
is
a
little
around
like
if
we
add
certain
nuances
to
this
and
they're
a
little
inconsistent
places
that
will,
I
don't
know
if,
like
I
feel
like
that,
might
cause
more
problems
than
helping
so.
C
A
C
I
I
do
see
some
value
in
saying:
okay,
move
closures,
always
capture
the
local
variable.
That's
not
what
you
want!
There's
a
there's,
an
idiom
where
you
do
you
know
this
is
what
I
do.
I
don't
know.
Other
people
might
do
their
own
ways
yeah
you
created
it
outside
and
then
you
kind
of
just
use
that
yeah
and
that's
just
the
way.
C
It
is
for
non-move
closures,
that's
a
different
story
and
like
because
mostly
they
take
by
reference
anyway,
but
not
exclusively
so
like
it's
not
an
entirely
different
story,
but
if
they're
not
taking
it
by
reference,
it's
because
they're
moving
that
value
right
and
so
they're
already
moving
it
once
so
you're
changing
from
like
you
move
it
when
you
create
the
closure
and
then
again.
C
C
C
Well,
let's
make
it
like
string
or
something
so
that
it
hasn't
just
I
don't
know,
otherwise
it
might
be,
and
what
I'm
saying
is
if
we,
if
we,
if
we,
if
we
proposed
a
model
where
we
said
move
always
captures,
is
very
simple:
it's
exactly
like
today,
but
if
it's
not
a
move
closure,
it
tries
to
be
smart
and
capture
the
most
move,
a
more
precise
path.
Maybe
it
omits
trailing
drafts.
C
However,
it's
not
great,
but
when
you
call
drop
tuple.0
you're
going
to
move
you're
moving
it
anyway,
so
like
now,
you're
moving
it
twice
instead
of
once,
that's
not
that's,
not
great,
but
like
in
the
in
the
other
example,
I
had
we're
moving
it
once
instead
of
zero
times,
you
know,
but
why?
Why
am
I
moving
double
twice
two
times
tomorrow
once
when
you
make
the
closure
and
once
when
you
execute
the
closure,
so
because.
A
B
C
C
That's!
Okay!
It's
just
it's
just
a
little
like
that's
the
only
place
in
rust,
where,
like
the
path
that
you
borrow
and
the
pack
that
you
move,
they
sort
of
behave
they're
like
considered
disjoint
in
all
the
same
cases
today,
and
now
they
would
be
different.
So
if
we
never,
if
we
always
made
any
move,
move
the
local
variable-
and
this
would
fail
to
compile.
C
And
because
it's
making
a
reference
where
we
capture
the
full
path,
and
so
we
consider
them
this
joint.
But
here.
A
C
Don't
make
a
reference,
and
so
we
don't
consider
them
disjoint
and
that
that
calls
me.
C
C
I
think
it's
unacceptable
for
this
example
to
go
from,
because
it's
going
to
compile
either
way.
The
difference
is
it's
going
to
become
the
worst
inefficient
or
not
yeah
yeah,
and
that
means
that,
like
the
idiomatic
way
to
write
this
code,
is
this:
let
double
equals
yes,
and
I
think
that's
sort
of
unacceptable.
That
should
not
be
the
idiomatic
way
to
write
that
code,
and
now
I
I
I
it
should
happen
in
some
weird
cases.
C
This
is,
I
don't
know
this
doesn't
feel
sufficiently
weird,
like
you
put
the
box
in
there,
because
you
wanted
it
to
be
cheap
to
move
probably
and.
A
C
C
A
Yeah,
oh,
I
think
there
are
a
couple
things
at
the
around
the
end
of
the
rc.
When
move
is
being
discussed,
so
move
closures
always
capture
by
move.
We
will
continue
to
do
so
under
this
proposal.
A
Oh,
yes,
I
think
this
exact
exam
kind
of
situation
is
being
talked
about.
I
guess
I
sort.
A
Well,
mostly
because
yeah,
I
think
a
lot
like
the
like
we'll
basically
have
a
draft
as
like
the
first
rejection,
almost
always.
If,
especially,
if
you're
dealing
with
references
thing
and
things
that
we
cannot
directly
move
so
we'll.
C
C
C
So
we
kind
of
run
the
capture
algorithm
as
normal
and
we
go.
If
it's
move,
we
turn
them
all
to
and
truncate
them
before
any
due
rest
always
move
the
pointer
and
that's
just
okay.
I
mean
it
does
mean
that
this,
oh
no,
this
example
works.
B
A
C
You
can't
have
it
both
ways
like
this
example
either.
If
you
want
this
example
to
not
move
the
array,
then
you
can't
have
this
example
work
when
it's
in
the
box,
like
just
doesn't
mean
so,
and
I
do
think
so
yeah.
So
we
say
when
you
have
a
move
closure,
it
moves
every
local
variable
or
other
it
like
it
moves
things
that
are
on
the
stack
into
right,
but
things
that
are
in
pointers.
It
does
not
move
like
the
pointer,
not
the
that.
C
That's
a
like
reasonable
rule
that
I
think
one
thing
it's
people
will
get
confused,
but
it's.
C
C
We
truncate
the
or
we
we
capture
the
most
precise
path
that
is
used,
which
is
on
the
stack
yeah.
So
in
effect,
we
truncate
captured
pads
at
before
a
debuff
and
there's
possible
extension,
which
is
to
convert
a
s
and
you
star,
x
or
is
just
sometimes
capture
by
reference.
C
If
the
place
is
only
used
by
reference,
and
it
is
a
draft,
it
is
a
reboro,
a
draft
of
a
reference
but
may
have
complex
lifetime
interactions
and
is
hard
to
explain,
and
I
doubt
that
I
even
explained
it
to
you
much
less,
the
user
who's
trying
to
identify.
C
One
of
the
examples
that
bothers
me
so
that
I
have
it
for
the
future.
But
if
you,
I
think
it's
okay,
because
I
think
this
code
also
does
not
compile
today.
But
if
you
had
something
like
this
today,
this
would
not
compile
because
you're
going
to
capture
s,
but
that
is
a
reference
to
the
stack
and
we're
returning
it
outside.
So
the
lifetime
collective
work
and
if,
by
this
rule,
what
I'm
getting
at
here
is
that
what
would
happen
with
my
extension
is
that
we
would
or
maybe
drop,
isn't
the
right.
C
Let
me
just
yeah:
let's
just
do
this,
we
would
like
see
that
we
have
re-borrowed
s,
and
so
we
would
kind
of
capture
ampersand
star
s
which
yeah,
I
guess
it's
fine,
which,
which
would
basically
run
at
the
same
error,
essentially
because
the
lifetime
of
that
new
reference
that
we're
now
capturing
is
still
tied
to
p.
In
the
end
yeah.
C
This
won't
compile,
but
it
wouldn't
have
compiled
before
so
that's,
okay,
they're.
I
guess
I
think
there
might
be
an
example
like
this
where
the
right
thing
to
do
is
to
capture
by
move,
but
you
can't
tell
that
unless
you
trace
out
all
the
things
that
the
reference
refers
to,
which
we
don't
know
so
like
that's,
that's
what
I'm
wondering
and
I
can't
think
of
what
it
would
be
right
now,
but.
A
Okay,
I
think
if
this
goes
in,
this
will
also
fix
the
problem
with.
I
don't
know
if
this
will
fix
the
problem
with
the
unsafe
pointer,
but
we
can
just
remove
drafts
if
we
are
starting
off
with
an
unsafe
point
or
anywhere.
A
Point
well,
it
will
fix
the
unsafe
pointer.
If
it's
a
move
closure
right,
it
won't
fix
unsafety,
that's
a
preference
like
if
you're
capturing
an
unsafe
draft.
With
that
I
see
I
see
yes,
you're
correct,
you
have
to
do
it.
You
have
to
have
an
extra
rule
like
if
it's
an
unsafe
pointer
and
there
are
data
truncated
at
the
unsafe,
pointer,
yep.
B
Which
I
don't
know
if
there's
a
test
for
it,
but
we
should
make
one.
I
think
I
think
we
need
still
a
lot
more
test
cases
for
this.
A
C
It
doesn't
matter
so
this
code,
this
code
is
unsafe
because
we
can't
we
don't
know
if
the
field
has
an
aligned
address
or
not,
and
maybe
we
wrote
it
with
an
unsafe
keyword,
because
somehow
the
user
believes
that
it's
aligned-
and
the
point
is
just
like
with
unsafe
dref.
If
this
is
occurring
inside
a
closure.
C
C
A
Things
wait
so
when,
when
you
do
an
ampersand
full
here
you
get
a
raw
pointer,
you
should
still
get
like
a.
I
would
have
assumed
that
would
give
you.
A
C
C
Oh
so
half
the
path
you'll
see
so
in
your
code,
you'll
see
a
place
like
foo
x
and
the
problem.
The
way
you
know
is.
C
A
C
A
How
to
check
for
as
long
as
like
there's
like
the
is
the
wrapper
pack
reflected
in
the
type
information
of
the
80d.
C
A
It
but
it's
it's
more
complex
than
yeah
like
like,
I
feel
like
they,
the
I
think,
a
couple
meetings
before
it
was
like.
Okay,
we
have
the
more
thing
left
and
the
moment
that
I
got
enabled
it's
just
like
all
right:
fireworks
everywhere,
yeah.
C
Yeah,
I'm
distressed
by
the
move,
rules
they're
more
yeah,
I'm
I'm
not
I'm
kind
of
happy
with
our
draft
rule.
I
think
we
found
a
this
is
like
I
could
imagine
explaining
it,
but
it's
definitely
more
complex
than
I
would.
A
I
think
the
only
thing
now
left
is
our
patterns.
Well,
I
I
won't
use
the
word
only,
but
one
of
the,
I
guess
main
things
that
are
left
now
are
patterns
like
wild
card
patterns.
So
I'm
assuming
we
just
go
like
I.
I
didn't
get
a
chance
with,
like
all
the
small
of
these
things,
that
came
up
the
last
couple
days
with
dick
2d,
but
we
probably
want
to
start
using
place
builder
somewhere,
but
I
feel
like
that
code
is
still
fairly
complicated
too.
A
C
C
Which
code
do
you
not
want
to
refactor?
Oh,
like
the
more
bad
one
right,
I
got
distracted
again
the
mirror
building
the
fact
that
that
stuff
uses
place
builder.
That's
what
you're
talking
about.
A
Yeah
yeah
like
using
what
is
it
called
and
when
we
build
patterns
using
place
builder
everywhere,
yeah
and
sort
of,
but
we
don't
right,
we
use
places
we
use
place
so
I'm
debating
how
much
do
we
want
to
use
a
like.
So
we
had
two
things
going
on.
One
thing
we
were
discussing
was:
does
it
make
sense
to
just
use
like
consume
the
place
in
its
entirety?
If
it
appears
in
a
pattern,
it's
an
easy
fix.
A
I
am
trying
to
like
just
look
away
in
the
sense
that
I
don't
like
I'm
trying
to
think
more
from
a
perspective
again
what
it
would
have
been
if
this
feature
was
available
from
start
and
not
something.
That's
just
easy
for
us
to
do,
which
makes
me
wonder
that
just
for
symmetry
inside
and
outside
of
closure,
I
feel
like
we
should
go
and
do
it
implement
the
do
the
refactoring
and
basically
implement
precise
capture
there.
C
C
I
tend
to
agree
that
if
the
code
compiles
outside
of
a
closure,
ideally
it
would
compile
when
you
put
more
or
less
right
so
like
that
means
that
we
would
capture
more
precisely.
I
don't
know
how
hard
that
refactoring
is
going
to
be.
It
doesn't
like.
A
C
It's
got
a
lot
of
vectors
instead
of
intern
thing,
but
obviously
true,
because
we'll
do
probably
less
interning,
I
don't
know
it
might
need
some.
That
would
be
a
problem.
I
feel
like
it's
low.
That
said,
I
feel
like
it's
relatively
low
priority.
I
would
rather,
energy
is
invested
in
working
out.
This
move
problems,
for
example,
and
thinking
about.
C
Well,
to
find
fail,
I
mean
it
captures
overly
broad
path
right.
A
No,
I'm
sorry,
I'm
confused.
What
do
you
mean
by
already
brought
part
there.
C
A
B
C
That's
going
to
be
going
to
be
grungy
like
it's
conceptually,
simple.
Unfortunately,
the
way
you
have
to
implement
this
stuff,
it
basically
comes
down
to
like
textual
diffs
from
what
I
know
so
we
have
to
it's
not
like
we
can
edit
the
ast
inside
the
compiler,
and
it
generates
a
nice
of
a
pain
in
the
neck.
That
way,
maybe
there's
some
good
techniques.
We
should
ping
esteban
he's
the
master
of
this
stuff.
Okay,.
A
Yeah
diagnostics
are
also
sort
of
in
work,
so
just
to
kind
of
give
you
an
update.
So
we
are.
There
are
two
pr's
currently
in
work
on
our
end.
So
roxanne
has
this
one
going
where
we,
basically,
when
we
report
f
and
mute
f
and
once
and
all
that
we
report
precise
paths
there,
so
that's
sort
of
starting
to
get
in
being
works
and
the
other
one
for
diagnostic
that's
going
around
is
so
it's
possible
and
we
have
discussed
this
before.
A
Like
let's
say
we
have
this
min
capture
situation
where
we,
you
read
p,
but
you
modify
p
dot
x
in
a
closure.
So,
like
the
error
message
based
on
how
things
would
be
today,
like
p,
is
used
as
a
mutable
borrow,
but
it's
like
it
could
be
confusing
if
which,
like,
like
you
might
like.
The
part
and
the
reason
for
a
mutable
borrow,
might
be
two
different
x
varieties
and
like
two
different
spans.
So
storing
that
information
is
also
sort
of
in
the
works
cool.
C
A
Yeah,
so
that's
in
the
works
and
jenny
and
logan
are
also
getting
working
on
what
they're
called
getting
rid
of.
Like
lawyer
captures
and
like
the
old
data
structures
from
the
compiler.
C
A
Right
that'll
be
nice
yeah,
it's
funny
like
our
school
is
moving
towards
teaching
one
of
our
courses
and
russell
that's
going
to
be
interesting.
Next
room.