►
From YouTube: 2021-01-20 Lang Team Design Meeting: RFC 2229
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
Okay,
recording
is
going
oh
hi
felix,
so
we've
got
in
addition
to
lengthening
folks
like
josh,
felix
scott
and
honorary
link
team
mark
we've
got
amman
and
logan
who
are
part
of
the
group.
That's
been
working
on
this
implementation
if
I'm
not
mistaken
and
all
right,
let's
start
walking
through
so
for
reference.
This
is
the
work
to
try
to
make
closures,
so
they
don't
just
capture
an
entire
variable,
but
they
only
capture
kind
of
the
part.
A
You're
using
turns
out
to
be
a
little
complicated
and
we've
run
into
some
kind
of
questions
we
wanted
to
get
lang
team
feedback
on,
but
before
I
dive
into
those,
I
want
to
kind
of
walk
through
some
of
the
details
and.
B
A
We'll
kind
of
approach
them
in
reverse
order
in
some
sense-
and
it
like
this
is
one
of
the
biggest
ones-
is
kind
of
what
is
the
correct
behavior.
So
we
have
toyed
with
a
couple
different
rules
around
what
what
move
closures
ought
to
capture.
There
are
some
considerations,
I'm
going
to
go
through
the
rules
as
currently
implemented,
and
then
explain
a
little
bit
of
why
so
one
thing
that
we
realized
along
the
way
or
is
we
don't
have
when
you
have
a
move
closure
the
way
that
it's
currently
implemented?
A
It
does
not
capture
through
a
draft,
basically
meaning,
if
you,
if
you
use
star
x,
you'll,
actually
capture,
x
and
similar
that,
but
if
you
use
here
like
in
some
well
okay
in
this
case
here,
there's
a
few
reasons
for
this.
One
of
the
motivations
is
around
boxes.
A
So
in
the
rules,
as
they
are
currently
implemented,
move
closures
are
always
capturing
things,
something
that's
already
on.
The
stack
is
being
moved
in
or
some
subset
of
something
that's
already
on
the
stack.
This
also
avoids
things
like
capturing
drafts
of
raw
pointers,
but
that's
kind
of
a
no-brainer.
A
C
A
A
Yeah,
so
if
you're
capturing
by
reference,
then
we
can,
we
can
capture
sort
of
through
a
dref,
but
if
you're
capturing
by
move,
we
won't
and
right
by
value
captures.
Don't
capture
dbfs
yeah,
that's
what
this
okay,
I
see
right.
That's
this
point
is
that
this
applies
not
only
to
move
closures,
but
also
to
closures
that
are
not
move
closures
but
which
move
values.
A
And
pretty
clearly
one
thing:
we
noticed
you
can't
capture
through
a
raw
pointer,
because
that
doesn't
make
any
sense.
You
don't
know
that
the
raw
pointer
is
valid
at
the
time
the
closure
is
created
in
particular
one
thing
that
I
see
yeah.
Okay,
I
actually
don't
know
what
the
wrapper
packed
story
is
amman.
Do
you
want
to
talk.
C
I
think
this
was
like
things
might
not
be
aligned
and
the
reads
might
not
be
safe.
A
Yeah,
by
the
same
token,
like
anything,
essentially
anything
that
requires
unsafe,
we'll
have
to
back
up
exactly
something
that
we've
considered
but
not
implemented.
I
guess
it's
not
in
this
like
linked
list
of
things.
Is
this
extension
around
reborrowing,
where
the
idea
would
be-
and
this
is
what
this
actually
was
proposed
on
the
original
rfc.
A
The
idea
would
be
that
if,
if
you
have
a
let's
say
a
move,
closure
or
just
a
closure
that
has
a
move
and
the
value,
the
full
path
is
reached
by
going
through
an
ampersand
mute,
then,
instead
of
moving
s
dot
x
here,
you
would
actually
have
a
mutable
reference,
so
you
would
basically
have
a
mute
ref
of
s.x
and
kind
of
re-borrow
it
the
current.
A
Yeah
exactly
now
keep
in
mind
this.
This
only
applies
to
moves
so
like.
I
think
this
extension
makes
sense,
but
in
the
majority
of
closures
you
don't
have
a
move,
in
which
case
this
is
not
a
move
this
would,
and
in
which
case
we
would
already
be
doing
a
mutable
reference
to
s.x
it's
only
because
this
was
a
move
closure,
but
all
the
uses
were
by
reference
that
we
kind
of
get
into
this
situation.
Does
that
make
sense.
A
Right
and
it,
and
importantly,
this
rule
still
preserves
like
the
primary
use
for
a
move.
Closure
is
to
be
able
to
return
it
from
x
or
to
have
it
escape
the
stack
frame
in
which
it
was
created,
and
this
still
works
as
well
as
it
ever
did
like
you.
Can.
The
closure
can
escape
so
long
as
it
doesn't
outlive
this
and
mute
s,
which
is
an
obvious
requirement,
since
it
has
which
is
true
in
both
modes.
A
Okay,
so
let's
talk
about
the
migration
plan,
the
I
think
there
are
a
few
things
that
have
come
up.
The
first
is
that
the
obvious
thing
that
was
considered
initially
is
that
when
you
move
different
things
into
the
closure
than
you
originally
moved,
you
might
change
when
destructors
run
right,
so
the
closure
would
have
moved
an
entire
variable,
but
now
it
moves
a
more
specific
place
and
if
there
are
other
fields
of
x,
that
would
have
been
moved
before,
but
now
won't
be
moved
and,
and
they
happen
to
have
a
destructor.
A
That
is
significant
in
some
sense,
like
the
user
cares
when
it
runs,
then
that's
going
to
change,
and
so
what
we're
doing
now
is
we're
fixing
that,
via
a
migration
lint
that
inserts
basically
let
x
equals
x
or,
like
a
you,
know,
a
tuple.
Some.
A
Some
no
op
like
this,
that
winds
up
doing
the
move
of
the
whole
variable
so
as
to
preserve
the
older
semantics,
and
we
don't
want
to
do
that
for
any
destructor
at
all,
because
there's
a
good
number
of
destructors
that
we
think
it's
that
just
free
memory
in
the
standard
library
and
it's
probably
not
what
the
user
really
wanted
to
to
to
move
them
in.
A
They
probably
don't
care
when
that
destructor
runs
and,
in
fact
might
prefer
it
to
run
earlier,
like
at
the
point
where
the
close
the
stack
enclosing
stack
frame
returns.
So
what
we've
the
plan
is
to.
I
don't
think
this
is
implemented
yet
to
allow
an
annotation
that
would
be
internal
to
rusty
that
can
be
put
on
to
types
or
drops
or
whatever
drop
impulse
to
kind
of
say.
This
is
a
non-significant
destructor,
which
means
that
for
the
purpose
of
this
lint,
we
won't
insert
a
statement
like
this
just
be
yeah.
A
Unless,
if
that's,
if
that's
the
destructor,
that's
going
to
run
at
a
different
time.
So
there's
this
plan
basically
works.
I
think
modulo
not
having
fully
implemented
the
precise
analysis,
but
there's
a
few
kind
of
challenges.
A
One
is
this
is
let
x
equals
x
is
sort
of
a
effective
hack,
but
if
that
this
might
be
code
that
people
have
to
write
at
other
times
right
like
if
you
want
the
force
when
a
destructor
runs,
you
have
to
force
a
capture
of
x
and
not
just
the
path
you're
using
and
now
this
would
kind
of
be
the
official
way
to
do
that,
and
that
seems
a
little
strange
to
me
like
it
looks
like
a
hack.
I
think
we
have
some
similar
things
in
closures
today
that
I
used
to
think
were
elegant.
A
Being
you
want
to
capture,
you
want
to
capture
a
clone
of
an
rc
and
the
way
I
at
least
do
that
is
to
write
this,
but
I've
like
I
said
I
used
to
think
that
was
elegant
because
we
didn't
have
any
kind
of
it
didn't
require
any
sort
of
special
syntax
for
capture
clauses
or
something,
but
most
people
don't
seem
to
think
of
this
or
if
they
do
think
of
it,
they
think
it's
horrible.
So
I'm
not
sure
that
was
such
a
good
idea.
I
feel
like
this
feels
the
same
to
me.
D
F
D
A
C
A
F
A
I
think
I
don't
actually,
I
think,
having
had
some
time
to
sit
on
this,
that
I
don't
have
an
objection
to
this,
and
I
wouldn't
necessarily
propose
that
we
change
it
so
much
as
that.
We
consider
for
future
as
a
possible
future
extension
that
there
might
be
value
in
having
an
explicit
capture
clause
syntax
of
some
kind.
F
Yeah,
I
I
guess
I'd
like
to
better
understand
what
the
objection
is.
Like
the
code
power
you
provided
earlier,
I'd
like
to
better
understand
like
what
the
objection
is
that
in
particular
to
me,
a
capture
clause
that
still
is
forced
to
occur
at
the
beginning
of
the
closure
doesn't
sound
all
that
more
palatable
than
what
you
wrote
out.
I
can
understand
the
objection
being.
I
have
to
add
this
code.
That's
nowhere
near
the
use
of
the
thing
that
I
put
in
right
like
I.
F
D
I
was
just
going
to
say
for
what
it's
worth
my
question
a
moment
ago
should
not
be
taken
as
an
objection
to
let
x
equal
x.
I
was
asking
if
there
was
a
way
to
write
it
in
a
more
self-documenting
fashion
and
it
sounds
like
the
answer
may
be
no
at
the
moment,
but
that
I
don't
have
an
objection
to
that
pattern.
It's
a
sensible
rest
fix.
A
I
so
felix
to
answer
your
question.
I
think
my
your
right
to
press
on
looks
odd
is
not
a
very
specific
specification,
but
I
think
for
me
it's
a
combination
of
self-documenting
and
non-obvious,
or
rather
not
self-documenting
and
non-obvious.
A
Like
I
don't
know
that
people
will
think
to
write
it,
and
I
don't
know
that
they'll
understand
why
it's
there
a
macro
could
help,
but
that
it
just
feels
there
is
a
certain
part
where
it's
hard
for
me
to
put
my
finger
on
it,
but
it
feels
hacky
yeah,
all
right.
F
The
let
x
equals
x,
I
can
see
being
pretty
somewhat
broken,
not
and
not
obvious
that
the
click
sequel
I
feel
like
I've,
seen
the
pattern
of
the
clone
explicit
clone
before
the
closure.
Enough
to
you
know,
recognize
it
so
I'm
I
find
that
curious
that
you
found
people
who
are
confused,
I'm
not
surprised
but
confused
by
it.
I
think
I'd
be
curious
if
there's
veterans
who
are
confused
by
it.
A
A
C
A
It's
not
it's
not
going
to
break
the
code;
it
just
won't
fix
the
problem
you're
trying
to
fix.
So
are
you
you're
right?
I
would
say
one
other
thing
about
the
not
obvious
is
that
I
could
imagine
that
the
idiomatic
way,
even
if
this
is
what
the
lint
inserts
the
idiomatic
way
to
fix
this
might
be
to
insert
an
explicit
call
to
drop
because
most
of
the
time
that
will
work
fine,
and
it's
much
more
obvious-
why
it's
doing
what
it's
doing
right.
B
Do
we
have
some
sense
of
how
common
like
as
a
percentage
of
like
closure
or
something
this
would
be
and
like?
Potentially,
I
could
see
us
doing
like
we
insert
drop
x
if
there
is
only
one
like
exit
path
or
something
like
that?
Yeah.
A
E
The
the
other
thing
that
was
curious
to
me
here,
the
notion
of
marking
destructors
as
not
so
important
or
whatever.
In
a
way,
it's
reminding
me
of
that
irlo
thread
going
on
about
talking
about
leaked
safety
traits
again,
and
all
this
or
sort
of
the
like,
I
feel
like
of
most
drops
that
are
actually
going
to
happen,
are
going
to
be
unimportant.
A
A
When
I
mean
we
could
sort,
you
could
imagine
expanding
this
annotation
so
that
users
can
add
it
to
if
it
were
to
like
and
then
kind
of
getting
major
crates
to
adopt
it
very
important.
E
A
E
D
A
E
B
A
So
there's
another
wrinkle,
which
is
that
there
are
other
ways
to
change
behavior,
that
we
didn't
appreciate,
or
at
least
to
have
not
change,
behavior
so
much
as
have
an
effect.
One
of
them
is
oops.
I
don't
know
what
this
links
to
looks
like
a
broken
link,
but
if
you
have
an
auto
trait
the
one.
A
The
end
of
the
page,
this
one
here
yeah,
yes,
so
consider
this
example.
I
think
scott
may
have
raised
it.
I
don't
remember,
but
we
have
here,
we
are
capturing.
I
think
this
comes
out
of
code
from
the
standard
library,
actually
we're
going
to
wind
up
capturing
w.0
as
a
move,
because
this
is
a
move
closure
and
that's
all
stored
on
the
stack.
A
So
we're
going
to
capture
w.0,
however
w,
which
is
basically
f,
which
means
that
the
type
of
this
closure
now
includes
f
directly
instead
of
including
assert
unwind,
safe,
wrapped
around
f
and
the
problem
now
is
that
assert
unwind
safe
implements,
unwind,
safe,
but
f
does
not
so
this
code
stops
compiling
and
that's
super
annoying
like
the
whole.
A
Yeah
yeah
yeah
there
are
similar
there
are
lots
of
this
can
happen
with
clone,
which
is
not
an
auto
trade.
By
the
same
same
concept,
this
is
much
harder
for
us.
Let
me
think
well
yeah
it's
harder
for
us
to
do
the
migration,
because
we
can't
always
tell
who's
gonna
care
right
like
if
you
were
to
return
this
closure
out
from
the
function.
A
It
might
be
that
the
like,
due
to
auto
trade
leakage
and
whatever
it
might
be,
that
the
callers
care,
if
it's
send
or
not
send,
but
but
we
don't
see
that,
and
so
we
wouldn't
really
necessarily
know
if
it
matters,
and
so
you
you
don't
want
to
have
a
test,
that's
like
if
this
type
implements
different
traits
than
the
type
as
a
whole
at
all.
That's
pretty
crude
you'd
really
want
to
condition
it
to
what
to
only
look
at
traits
that
might
matter.
A
F
A
C
Interesting
thought
might
be
able
to
see
it
in
the
sense
that
if
we
have
a
trade
obligation
fail
within
the
closure
itself,
we
can
see
if
the
root
variable
sort
of
implements
that
trade,
so
maybe
that's
a
possibility.
I.
A
E
A
Self
type
is
a
closure.
You
know
we
could
kind
of
do
some
stuff
around
it.
I
think
we
could
implement
a
good
diagnostic.
C
No,
no
so
like
you
can
implement
sentencing
on
like
so.
If
you
go
back
to,
I
think
I
have
a
link
in
there
like
you
might
implement
right.
C
Yeah
yeah
like
when
you
have
wait.
What
so,
I
think,
can
you
go
to
29
yeah
and
look
at
the
comment.
That's
at
the
very
bottom
yeah.
So.
A
E
We
never
have.
We
never
have
a
closure
that
implements
hash,
say
right.
A
E
So
this
can
never
be
a
problem
for
the
hash
trait,
because
anything
that
you
were
using
inside
the
closure
that
cared
about
hash.
It
would
still
be
capturing
that
part
that
was
hash
that
needed
to
be
ash,
so
this
only
affects
auto
traits
and
the
other
two
or
three
things
that
we've
defined
on
closures.
E
F
E
B
A
E
A
E
B
I
I
think
the
the
more
potentially
worrying
thing
is
like
if
I
have
some
struct
and
I'm
cloning,
I
guess
like
I
was
thinking
about
like
arc
and
rc,
where
potentially
you
can
clone
like
the
ark
itself
or
like
the
draft
of
the
ark
to
some
struct,
but
I
think
we
would
handle
that
correctly
because
you
never
there's
never
like
there's
not
a
field,
you
can
access,
that's
the
inner
thing
you
always
draft
to
it.
Also.
A
We
wouldn't
capture
through
drif
right
the
move,
but
I
think
scott,
I'm
still
not
entirely
sure
what
you're
saying,
because
I
think
that
anything
in
the
body
of
the
closure,
like
you're,
still
accessing
the
same
data
that
you
ever
were.
So,
if
you're
doing
explicit
clones
or
something
like
that,
it's
just
about
whether
you
capture
the
whole
struct
or
some
parts
of
it.
E
E
A
I
don't
know
what
I'm
writing
here.
It's
not
rest
syntax,
but
ignore
that
I
have
a
a
struck
like
this
and
I
have
a
move
and
you're
saying
like
I
had.
D
A
Clone
I
see
yes,
you're
correct.
There
is
a
change,
a
subtle
change
in
semantics
there.
What
I
did
want
to
say
about
clone
is
that,
unlike
auto
traits,
it
doesn't
leak,
and
so
we
actually
can
see
all
the
places
where
clone
gets
called
on
the
closure
type.
A
Which
is
interesting
like
yeah,
you
could
return
an
impul
clone,
of
course,
but-
and
we
could
see
that
too,
but
so
we
actually
could
potentially
make
clone
even
more
specific
to
say
if
you
actually
clone
the
closure,
because.
E
A
But
the
changes
to
clone
for
capturing
subpaths
can
change
the
semantics
of
closure.clone.
That's
a
good
catch.
Thank
you,
scott.
I'm
glad
we
drilled
into
that.
A
I
didn't
understand
it.
That's
not
true
for
any
auto
trades.
This
is
specific
to
clone
yeah
because
it
has
like
user
defined
code
that
can
run.
D
B
B
And
hopefully
the
standard
library
doesn't
ever
make
use
of
it
in
a
way
that
matters
exactly,
although
I
guess
technically,
if
you
have
like
a
closure
that
captures
something
and
then
the
standard
library
currently,
I
guess
we
don't
ever
specialize
on
a
closure
type.
So
we
should
that
shouldn't
be
a
problem.
E
B
Yeah,
the
thing
I
would
be
more
worried
about
is,
like
I
don't
know
for
some
reason,
like
you
want
to
copy
your
closure
a
bunch
of
times
and
then,
if
you
change
what's
inside
the
closure
to
a
smaller
field,
now
we
compile
that
down
to
like
a
mem
copy.
Instead
of
not
I'm
copying,
somehow
that
you
know
takes
your
performance,
but
I
am
not
terribly
worried.
I
guess.
A
A
F
A
Foo
we
I
haven't,
I
don't
know,
I
guess
I
am
not
sure
what.
A
The
question
that
is
not
entirely
clear
to
me
is
how
often
to
add
that
in
do
we
want
to
try
to
get
smart
and
only
look
for
cases
where
you
actually
use
clone.
Do
we
just
want
to
do
it
anytime,.
D
B
Yeah,
I
guess
I
don't
know
for
a
lot
of
these
migration
things.
I
am
personally
really
interested
in
seeing
like
how
often
we
even
have
to
do
anything
like
if
you
know
you
implement
no
migration
except
the
potential,
even
like
no
migration
whatsoever.
What
percentage
of
crates
break
right
with
the
new
rules?
A
I
also
wanted
to
see
data.
I
would
love
to
think
about
those
thresholds.
Also,
like
I
don't
know
either
one
is
a
good
one,
but
yeah
I,
the
downside
of
this
is
each
time
we
add
it.
I
think
there's
a
relatively
small
chance
that
you
actually
wanted
it,
and
so
you
know
each
such
migration.
It
just
makes
the
code
a
little
less
idiomatic,
so.
A
Running
on
the
wrong
thing
sounds
really
unfun,
so
I
wonder
if
never
mind
I
was
going
to
ask
a
totally
question.
Okay,
this
is
another
question
right
now
in
the
implementation.
A
We,
if
you
have
a
subset,
an
index
expression
like
this.
We
always
treat
it
as
if
it
were
overloaded,
which
means
that
you
would
capture
foo
here
and
not
foo
of
zero
and
in
the
case
where
index
is
overloaded.
That's
sort
of
we
have
to
do
that
because
you
have
to
run
the
index
code
and
it
has
to
run
on
foo
by
the
way
there's
some
typing,
so
I'm
gonna
mute
there.
We
go
okay,
josh
yeah,
you're,
muted,
the.
A
However,
in
the
case,
where
you're
indexing
into
a
fixed
length
array
like
this,
we
could
choose
not
to
do
that.
It
would
not
be
too
hard.
I
don't
think
so.
There's
a
bit
of
a
policy
question
of
like
do
we
wanna
do
we
want
to
specialize
to
known
types
and
have
more
precise,
captures
and
then
lose
precision
in
the
case
of
overloaded
operators?
A
We
are
doing
that
with
draft,
for
example,
also
in
borrow
check
in
various
ways
so
or
do
we
want
to
keep
it
consistent
for
index,
no
matter
whether
you
overload
it
or
not,.
B
B
F
F
A
D
A
Yeah
very
little
right
because
accessing
the
other
elements,
the
array
is
still
going
to
be.
Disallowed
like
the
bar
checker
is
not
smart
enough
to
know
that
foo
of
one
is
disjoint
from
foo
of
zero.
So
you
the
only
thing
it
changes
is
when
the
destructors
run,
but
you
won't
get
access
to
the
rest
of
the
array.
D
F
A
So
that
is
all
true,
but
I
don't
particularly
like
the
idea
of
making
this
different
for
copy
or
not
copy.
I
have
to
say
like,
if
you
add
a
t
copy
bounds.
I
don't
know
your
closure
captures
change,
seems.
B
F
A
A
Oh
no
anything,
I
guess
the
point
is
conceivably
conceivably
if
the
element
type
were
copy,
we
could
handle
this
case
differently,
but
that
would
be
complicated
and
would
mean
that
adding
a
t
copy
bound
changes.
The
behavior
of
your
closures
in
significant
ways,
which
is
surprising,
are
there
other
arguments
brought
up
along.
B
B
A
A
A
B
A
Either
all
right,
so
I
should
just
close
this
yeah
yeah,
more
progress,
yay
all
right,
it's
the
best
way.
Okay,
the
last
thing
it's
10
50
minutes
in
at
the
last
point,
which
is
fairly
significant,
is
or
actually
there's
not
much
to
say
about
this.
I
just
want
to
call
attention
that
the
current
implementation
is
not
particularly
smart,
so
it's
possible
that
your
closures
get
bigger.
Is
that.
A
Your
closures
could
get
bigger
than
they
used
to
be
because
maybe
before
you
just
stored
one
reference
to
the
entire
struct,
and
now
you
have
references
to
several
of
the
structs
fields.
Instead,
we
did
discuss
on
and
off
like
implementation,
optimizations,
where
we
would
try
to
just
capture
a
closure
pointer
to
the
struct
or
whatever
we
knew
we
could.
We
have
not
thought
seriously
about
how
to
implement
those
that
sounds
hard
and
scary
to
me.
A
So
the
way
it's
implemented
now
requires
like
basically
no
changes
to
borrow
check,
except
for
some,
the
diagnostic
patching
for
the
most
part,
I
think,
because
it's
kind
of
just
expressed
in
a
in
a
way
that
darja
can
understand,
which
is
nice
if
we
were
gonna,
add
raw
pointers.
It
would
get
scary
and
I
would
be
also
worried
about
things
like
I
don't
know
you
use
s
dot
x
and
if
we
capture
a
pointer
to
s-
and
then
s
goes
out
of
scope
now
we
have
to
make
sure
we
get
all
the
rules
right.
A
So
I'm
not
too
keen
on
that.
It
is
some.
I
guess
my
recommendation
at
the
moment
is
yeah,
we'll
we'll
try
to
gather
data
and
see
what,
like
we
can
print
some
earnings
if
closures
get
bigger
by
a
certain
percentage
and
see
what
we
see
in
the
ecosystem
and
if
it's
a
big
deal
we'll
think
about
it
and
decide
what
to
do.
Maybe
we'll
see
some
patterns
or
something
that
suggests
itself,
but
we
have.
F
A
C
A
Because
at
least
with
the
current
rules,
I
think
this
may
change
if
we
adopt
that
extension
we
proposed,
but
the
current
rules
say
that
you
only
capture
something
that
was
on
the
stack
already
basically,
and
so
if,
before
you
were
capturing
the
whole
variable,
which
is
all
the
things
down,
the
stack
now
we're
capturing
some
subset
of
those
things.
Yeah,
okay,.
A
Yeah
the
re-borrowing,
which
we
probably
will
implement
yeah.
C
A
A
Okay,
so
the
last
thing
captures
and
matches.
I
think
this
is
pretty
much
an
implementation
limitation
that
we
can
we
hope
to
fix.
But
presently,
when
you
match
on
something,
for
example,
regardless
of
what's
in
the
pattern,
we're
going
to
treat
it
as
a
use
of
the
thing
you
matched
on-
and
that
means
like
here,
we
would
capture
x,
even
though
we're
not
actually
using
any
data
from
x.
Also
here
I
forget
I'm
on
whether
that's
true
for
the
let
case
or
not,.
A
Which
we
do
by
introducing
a
fake
read
of
x,
that
the
borrow
checker
knows
about
currently,
at
least,
which
is
why
we
have
a
problem,
because
there's
a
read
of
x.
A
B
C
An
ass
right
now
so
wild
cards
are
yeah.
Pattern.
Matching
is
a
bug
that's
currently
being
fixed,
but
the
idea
is
what
we
discussed
at
least
last
week
was:
let
underscore
equals
x
will
not
capture
anything
we'll
just
make
sure
that
it
it
will
fake
capture.
X's
lag
is
the
better
way
to
put
it.
C
It
will
introduce
a
fake
read
of
x
just
because
when
we
do
build
mur
we
do
need,
because,
because
let
underscore
equals
x
goes
to
the
same
pattern
matching
chord
as
a
match
block.
Does
we
need
a
fake
read
of
x
so
we'll
fake
capture
x,
so
that
we
can
support
that
and
same
case
goes
for
the
match
blocks
as
well.
F
C
F
The
point
the
problem
is
something
compiler,
there's
places
where
you
can
only
special
case,
like
literally
let
underscore
equals
variable
it'd
be
good
to
make
that
clear
that
that's
not
what
you're
talking
about
here.
I'm
it's
only
occurring
to
me
just
now,
because.
F
F
C
Okay,
so
right
so
so,
if
we
have
yes,
we'll
try
to
make
them
the
same,
if
we
have
a
pattern
within
a
match
which
is
like,
if
it's
a
multivariate,
for
example,
an
x,
then
we
will
try
not
we
will
try,
we
will
have
to
capture
x
and
stuff
yeah.
I
I
think
what
we
just
that's,
what.
A
Yeah
right
well
that
that's
okay
yeah,
so
the
multivariate
enum
just
to
give
people
context.
We
were
observing
that
if
you
have
something
like
this,
you
have
to
capture
x
because
you
need
to
read
the
discriminant
of
x
to
know
whether
it's
sum
or
none.
Even
if
you
don't
take
any
data
out
of
x,
yeah,
that's
just
kind
of
an
implementation
detail,
but
yeah
we'll
get
that
right.
Yeah.
C
Yeah,
so
I
think
the
idea
is
yeah
we'll
try
to
not
capture
how
both
of
them
behave.
The
same
way
that
yeah.
A
All
right,
we
have
three
minutes
left
we're
at
the
end
of
the
dock,
which
is
sort
of
beautiful.
I
planned
it
that
way
any
final
comments
or
thoughts,
I
guess,
is
the
question.
A
I
think
I
would
say
to
jump
back
to
our
questions
that
we
brought
up.
We
we
settled
we
do
not.
No,
basically,
we
do
not
need
a
better
syntax
for
migrations,
but
maybe
we
want
to
consider
one
or
maybe
not
that's
just
nico.
A
We
came
up
with
some
ideas
about
how
to
migrate
around
traits
that
are
not
satisfied
by
the
closure
anymore.
We
can
introduce
migrations
for
these
if
necessary.
B
I
do
think
I
don't
know
more
generally,
I
feel
like
potentially,
if
you
know
ninety
percent
of
closures
gain
a
x
equals
x
type
thing.
Then
that
is
concerning
and
then
maybe
we
do
need
a
different
syntax
or
a
different
strategy
here.
But
if
we're
expecting
it
to
be
low,
then
I
think
I
would
be
less
like
that.
A
Agreed,
no
assuming
it's
not
that
common,
so
I
don't
know
that
we
can
set
a
threshold
here,
but
I
think
that's
just
like
a
good
general
rule
is
to
say
there's
nothing.
That's
come
up
with
any
blockers
so
far,
but
we
definitely
want
to
run
some
creator.
Tests
see
how
often
these
kind
of
edge
cases
and
stuff
come
up,
and
that
may
cause
us
to
revisit
some
of
these
questions.
A
C
Just
like
in
this
question,
or
something
at
the
top
about
clone
having
interesting
behavioral
changes,
just
just
as
a
highlight.
Okay,.