►
From YouTube: RFC #2229 Disjoint Field Capture Plan
Description
We discuss the overall strategy for implementing RFC #2229, pulling together a rough roadmap including a number of refactorings, and identifying some bits of work that can be done independently.
A
B
A
A
A
A
B
A
B
A
Don't
see
them
okay,
let's
leave
that
we'll
come
back
to
that
topic
because
something
we
can
discuss.
Asynchronously
I,
don't
think
it's
a
major
problem
like
okay
Dorit.
We
could
plausibly
even
land
the
PR,
as
is
but
I,
think
I'm
inclined
to
try
to
fix
the
error
messages.
I,
just
don't
think
it's
very
well.
A
Mostly
because
it
seems
like
we're
exposing
implementation
details,
if
we
land
those
message,
but
the
changes
to
the
message
kind
of
expose,
an
internal
detail
that
maybe
users
don't
care
about,
I,
see
but
I'm,
not
overly
concerned,
it's
not
the
best
error
message
anyway.
So
I
guess
the
interesting
next
question
is:
where
will
we
go
from
here
right,
I
think
I,
definitely
think,
step
one
that
we
should
lay
on
this
as
a
PR
like
this.
A
A
A
A
A
B
B
A
A
A
B
C
B
A
A
A
A
Code
that
uses
with
free
VARs
we
have
to
we
have
to
for
each
for
each
user
sort
of
make
a
plan
for
how
it
will
be
altered,
all
right,
so
I
think
a
number
of
them
and
just
use
the
up
for
list
I'm,
pretty
sure
you
changed,
mirror
construction
or
something
actually
I
could
probably
figure
this
out
with
relative
ease.
So
the
up
wireless
map
is
accessible
through
the
up
far
list.
Let
me
just
do
a
quick.
C
A
A
Yeah
so
Samir
construction
Russ,
let's
see
it,
looks
like
oh
man.
This
is
the
weirdest
I
have
to
complain
it.
She
sorry
totally
unrelated,
but
in
github.
For
some
reason
it
does
never.
It
does
not
find
like
in
this
file
search
mode,
mere
construction.
It
just
can't
find
and
I've
never
understood
lion
and
drives
me
a
little
bit
crazy,
but
there's
some
kind
of
there's
some
kind
of
bug.
There's
a
directory
lip
rusty,
mirror
slash
build,
but
you
see
it's
not
in
this
list,
so
what
I
always
have
to
do
is
yeah.
C
A
But
there
there
may
be
other
code
I
guess.
The
question
is
to
check.
Where
is
the
other
code,
but
in
which
cases
is
discharged
and
I
think
that
would
primarily
be
harder
to
do
if,
for
some
reason
that
code
comes
before
type
check
is
done,
you
know
type
check,
yeah
and
I'm,
hoping
we
don't
have
any
such
cases,
or
at
least
we
can
find
you
know,
solutions
for
each
of
them.
B
A
A
A
A
A
A
A
A
Don't
love
either
of
those
plans
but
I'm
I'm
nervous
about
telling
the
bar
checker
to
treat
the
code
differently
than
what
it's
actually
doing,
because
it's
the
kind
of
thing
we
used
to
do
a
lot
and
it
can
definitely
lead
to
subtle,
bugs
I
feel
I
mean
I.
Guess
this
that's
also
true
for
the
optimization,
but
somehow
it
feels
different
to
me.
A
A
A
A
A
A
Is
interesting:
okay,
I
guess
this
is
getting
more
optimized
than
I
expected,
but
this
must
be
the
point
where
it
is
underscore
to
this
variable.
This
must
be
the
closure
and
we're
assigning
to
its
to
its
one
field,
oops
just
in
there
for
signing
to
its
one
field,
the
the
tuple,
a
reference
to
the
tuple
X
right,
and
so
my
point
was
if
we
were
gonna
change
this
after
the
fact.
A
We
would
have
to
kind
of
alter
this
code,
like
it's
pretty
tricky
right.
We'd
have
to
alter
this
code
to
instead
of
doing
one
thing
to
do
two
or
three
things
we
still
obviously
have
to
change
the
fields.
This
alone
might
argue
why
we
can't
do
it
after
the
fact
very
easily,
because,
okay
so
to
make
the
change
or
whatever.
However,
we
do
it,
you
have
to
accommodate
two
concepts,
which
is
the
number
of
fields
in
the
closure
struct,
and
the
number
of
captures
right,
and
these
right
now
are
one-to-one,
but.
A
But
we
would
want
to
make
them
separate
because
yeah
right,
you
can't
do
this,
and
so
what
that
implies
to
me
is.
However,
we
do
this.
The
layout
code
and
other
code
that
has
to
deal
with
the
number
of
fields
is
going
to
want
to
be
kind
of
aware
of
the
final
result
before
we
even
get
started
right,
because
it
has
to
generate
the
right.
C
A
You
can't
change
it
up
later,
and
that
means
that
code
is
kind
of
tied
to
to
the
mirror.
In
the
first
place,
we
can't
generate
mirror
that
writes
to
fields
that
don't
exist.
Do
you
see
my
point
yeah?
So,
let's
see
so
so
it
seems
like
we're
kind
of
getting
to
that.
We
can't
they're.
Actually,
this
approach
is
maybe
incoherent,
because
it
would,
it
would
require
us,
alter
the
layout
of
the
closure
struct
after
mirror
generation,
and
we
don't
currently
on
them
mechanism
for
that,
like
that
would
require
introducing
two
concepts
of
layout
one.
A
A
That
means
we
either.
We
only
really
have
one
choice,
which
is
this,
which
is
that
we
have
to
figure
out
ahead
of
time,
the
logical
Barros
and
the
actual
burrows
or
the
logical
captures
and
the
actual
captures
and
some
parts
of
the
code
are
going
to
want
to
deal
with
the
actual
captures
and
some
parts
of
the
code
are
gonna
want
to
deal
with
the
logical
captures,
and
now
we
get
to
another
challenge.
So,
let's
just
assume
we're
doing
that.
A
That's
how
we
going
to
separate
logical
captures
our
check
sees
on
the
actual
captures
what
the
code
does
and
how
we
have.
Another
problem
is
that
if
you
look
at
where
these
captures
these
borrows
and
things
are
occurring
in
this
code,
you
can
see
that
we
are
we're
actually
borrowing
so
underscore.
One
is
the
variable
X
here
right
and
we're
actually
borrowing
it
just
kind
of
in
this
random
statement.
That's
not
connected
to
the
closure
in
any
particular
way,
and
this
is
actually
after
optimization,
but
but
this
is
really
the
closure
construction.
A
A
What
this
leads
me
to
so
ok
hold
on
problem.
A
set
of
her
borrow
check.
Sort
of
Muir
has
no
way
to
reflect
optical
versus
actual
borrows
right
now.
The
borrows
in
Weston
are
just
normal.
Borrows
borrow
Tucker
camp
obviously
distinguish,
unless
we
add
some
metadata,
so
I
think
what
I
would
what
I
I
think
what
we
should
do
a
is.
We
should
probably
try
to
introduce
this
concept
of
logical
versus
actual,
but
we
prob,
we
probably
shouldn't
use
it
yet.
A
However,
I
think
there's
a
principled
way
that
we
might
want
to
do
as
a
second
step
to
add
this
notion
of
logical
versus
actual,
and
that
is
that,
actually
this
is
the
problem
like
if
you
look
at
the
borrowed
track
in
general,
there's
just
a
general
problem
of
you
know.
If
you
have
a
method
like
this
I.
A
A
B
A
To
all
of
self,
even
though
it's
not
going
to
use
the
field
eight
right,
it's
the
same
problem
and
I
I
would
like
to
have
a
way
for
us
in
rust
in
general,
to
declare
sort
of
that
that
four
bar
to
declare
that
it
only
uses
this
field
bar,
so
that
so
that
we
could
type
check
this
code.
I
don't
plan
for
us
to
add
that
to
I
mean
I
have
no
concrete
plans
for
how
that
would
work
in
rust,
but
it
might
be
something
where
we
could
start
building
some
of
the
underlying
mechanism.
A
A
Something
like
this
I,
a
reference
that
can
home
the
access
bar
that's
kind
of
the
concept
we
want.
It
seems
to
me
like
well,
we
could
sort
of
do
this
in
any
order,
but
it
seems
to
me
like
it
would
be
nice
to
get
to
first
get
the
feature
working
so
that
we
can
test
it
and
deal
with
some
of
the
other
questions
like
even
ignoring
this
optimization.
There
are
some
questions
and
stuff
we
wanted
to
play
around
with
around.
A
When
should
you
break
it
up
into
fields
and
so
forth,
and
then
we
could
separately
come
take
a
look
at
this
problem
and
try
to
deal
with
it.
That's
what
I
think
makes
sense.
So,
okay,
digression
aside!
Well,
that
means
that
that
already
tells
us
that
there's
going
to
be
a
like
step
n,
which
is
like
try
to
optimize
the
representation
of
closures.
You.
A
Don't
know
exactly
what
n
is
gonna
be
yet,
but
two
separate
optical
from
actual
bars,
so
step
three
is
probably
going
to
be
so
we're
gonna
assume
still
a
one
to
one
logical
and
actual
bar.
Oh
then,
I
think
what
that
means
is
we're
going
to
want
to
probably
in
the
type
checker
analyze
the
paths
that
get
used
and
create
more
refined
borrows.
A
Probably
the
first
step
is
going
to
be
I
think
we
could
probably
land
some
kind
of
sort
of
write.
The
code
that
figures
out
what
paths
should
be
borrowed
like
some
unit
testing
of
this.
So
the
idea
here
would
be
that
we
can
have
code
that
figures
out
and
in
fact
this
doesn't
really
depend
on
any
of
the
other
we're
doing
so.
This
is
like
a
separable.
B
A
Yeah
this,
so
this
actual
change,
I'm
proposing
doesn't
blow
strictly
speaking,
require
a
feature
gate
but
I
agree
that
making
a
future
Gators.
It
could
it's
time
for
that,
because
now
we're
starting
in
on
the
feature
itself,
and
what
I
was
going
to
propose
here
is
that
you
would
basically
have
something
where,
like.
A
Where
you
can
kind
of
write
a
unit
test
where
you
you
had
some
funny
annotation
like
rusty,
underscore
captured
dumped
on
to
the
function
on
the
enclosing
function,
and
then
we
will
emit
notes
or
errors
for
each
closure
with
in
describing
the
past
that
should
be
captured
on.
Why
and
so
I
can
give
you
an
example.
This
is
something
I
found
to
be
pretty
useful,
especially
in
the
early
stages,
often
less
so
later
on,
but
it
lets
you
kind
of
land
PRS
that
have
tested
code
without
having
built
all
the
mechanism
right.
A
A
Where
we
put
this
right
little
unit
tests,
they
have
a
funny
annotation
rusty
regions,
which
itself
is
feature
gated
and
any
any
attribute
that
starts
with
rusty
is
feature
Gator
automatically
with
a
feature
that
will
never
be
stable
because
it's
not
really
meant
for
real
rust
programs
to
use,
and
then
it
dumps
it
dumps
this.
This
information,
which
the
details
aren't
important.
But
the
key
point,
is
it's
basically
like
a
unit
test
right,
saying:
here's
something:
here's
some
details
about
the
closure.
A
A
Then
later
we
would
add,
I
don't
actually
know
the
details
we'll
have
to
look
more
closely,
but
we're
gonna
want
to
sort
of
define
the
or
modify
the
off
our
list
entries
somehow
to
specify
the
path
that
is
captured
and
we'll
want
to
modify
your
construction
to
translate
sort
of
a
dot,
B
dot
C
into
a
reference
to
the
OP.
Far,
instead
of
only
translating
okay
and
probably,
unfortunately,
will
probably
also
have
to
there
are
some
other
bits
of
code
that
will
probably
also
have
to
be
changed.
I'm
thinking
of
the.
A
With
something
called
the
expression
use
visitor,
which
is
sort
of
a
predecessor
ish
to
Mir,
it's
used
in
the
old
used
in
the
ast
bar
check,
primarily
though
also
other
places
and
there's
like
a
few
other
bits
of
code
that
it
will
have
to
alter.
Hopefully,
if
we
move
slow
enough,
maybe
some
of
those
codes
will
be
factored
away.
A
Actually,
not
the
expression
use
visitor,
though,
because
it's
also
used
in
closure
analysis.
It's
not
going
anywhere,
at
least
not
for
the
short
term,
but
still
there's
some
advantage
to
moving
slow
anyway,
but
I
think
that's
far
enough
away.
We
don't
have
to
like
do
in
too
much
detail,
but
once
we
do
that,
we're
basically
done
with
versions
one
of
the
features
or
so
maybe
this
becomes
step.
Four
I,
don't
know
I'm
sure
we'll
add
some
more
steps
as
we
go.
A
Yeah,
a
simple
PR
would
be
adding
a
future
game.
I
guess
the
main
insight
here.
Is
it
indeed
this
code
that
figures
out
what
path
should
be
borrowed
is
something
that
it's
kind
of
independent
from
the
rest
right
like
we
can
write
that
code
and
dump
it
out
and
we're
just
not
using
it
for
anything.
Yet.
B
A
And
how
I
should
add
that
I
think
figuring
out
the
set
of
things
that
are
SCAP
sure
it
is
not
like
super
complex
but
not
entirely
trivial.
If
I
recall,
there's
some
subtle
points
in
order
to
preserve
execution
order
and
stuff
like
that,
hopefully
we
think
it's
documented
in
the
RFC
more
or
less,
but
that's
something
we're
gonna
have
to
think
about.
A
C
B
A
So
this
function,
what
it
does
is
it
it's
used
for
auto
traits
and
it
basically
takes
a
type
and
gives
you
the
Constituent
types
of
things
that
are
inside
of
it
like
for
a
struct.
It
would
be
all
of
its
fields
for
something
like
a
you
enter
in
there's
nothing
inside
of
it.
So
it's
just
an
empty
vector
and
the
idea
is,
you
know,
for
an
auto
trait.
A
Something
is
send,
for
example,
if
all
of
its
constituent
types
are
sin
all
right
and
so
for
a
tuple,
it's
just
gonna
be
the
list
of
stuff
inside
of
it
and
here's
the
change
we
made
right
because
today
for
a
closure,
it
directly
returns
a
vector
of
the
captured
up
var
types
right.
So
today
they
for
a
closure
for
a
closure.
Let's
call
it
C,
you
get
back
a
vector
like:
u
1?
U,
2!
U!
3
of
the
up
four
types
right
and
in
your
branch
of
the
branch.
A
A
A
A
Basically,
we
added
an
extra
step
and
I
see
two
options:
how
to
fix
this
I'm,
not
actually
sure
which
one
I
like
better
option
number
one
would
be
that
we
we
modify
this
line
in
your
branch
to
kind
of
do
something
more
like
the
current
behavior,
so
you
could
imagine
saying
instead
of
just
returning
the
OP
particle
tie,
we
could
inspect
it
if
it
is
known
to
be
a
tuple,
you
just
returned
its
contents
else.
We
returned
the
two
bullet.
The
problem
with
that
is,
besides
being
complicated,
I'm
a
little
bit
nervous
that.
A
Something
weird
will
happen,
basically
like
having
a
consistent
return.
Type
from
that
function
seems
better
than
inspecting,
especially
inspecting.
The
state
of
inference
is
very
fragile.
Okay,
so
another
option
is
to
suppress
this
in
the
sort
of
print
out,
right,
I,
think
and
that
I
feel
a
little
bit.
This
seems
maybe
better
because
it's
less
steep
the
question
is
exactly
how
to
do
it.
A
So,
let's
see
what
happens
today,
let
me
show
you
a
little
bit
more
detail
where
that
tracing
mechanism
comes
into
play,
so
each
time
we
have
to
prove
something
we
have
something
called
a
cause
it
so
like.
If
we
have
to
prove
that
something
is
send,
will
have
a
cause
saying
why
maybe
because
we
called
another
function
or
whatever
and
there's
inside
this
cause,
there's
a
code
which
is
the
obligation
cause
code.
A
A
Yeah
I
think
this
is
it
so
I
think
this
is
where
we
build
up
a
little
chain.
That'll.
Have
these
things
saying,
like
I,
had
to
prove
I
had
it's
kind
of
just
making
a
little
linked
list
of
the
types
that
that
I
had
to
prove
and
then,
when
you
see
this
error
message,
we're
actually
iterating
through
that
linked
list
going
going
through
the
parent
codes.
A
Bates,
where
is
it?
It's
called
error
reporting?
That's
what
it
is
so
in
the
Train
error
reporting
code,
let's
see
required
because
it
appears
right.
So
when
we
see
a
built
in
derived
obligation,
we
kind
of
get
the
parent.
We
dump
some
information
about
the
self
type
of
the
parent
and
then
we
recursively
process.
A
It's
a
little
bit
tricky,
so
you
could
look.
I
can
see
I
guess.
I
can
see
two
ways
to
combat
this
either
when
we
add
a
link
when
we're
when
we're
in
a
closure
type.
We
kind
of
suppress
that
link
in
the
stage
or
something
off
to
look
where
these
actually
get
created,
but
basically
so
that
we
create
a
shorter
chain
that
doesn't
include
the
tuple
type
and
then
that
we
could
probably
do
with
relative
ease.
A
Actually,
that's
probably
the
way
to
go:
that's
just
better,
but
either
we
do
it
that
way,
or
we
somehow
add
a
field
or
something
so
that
we
know
in
this
code
to
ignore
that
link
in
the
chain.
All
right,
but
I
feel
like.
If
we
can
add
some
way
to
note
to
ignore
it,
then
we
could
also
just
not
create
it.
I
guess:
I,
guess
what
we
could
do
in
this
code.
For
example,
is
you
could
look,
and
you
could
say?
Oh
if
I'm
looking
at
a
tuple
and
its
parent
is
a
closure.
C
B
A
A
A
A
If
we,
if
we
then
change
again
the
constituent
types
function,
then
this
code
is
now
wrong
with
there's
no
reason
to
so
it's
sort
of.
Rather,
if
we
can
make
it
more
local,
but
let's
see
where
does
that
actually
happen?
It's
probably
not
too
hard
hold
on
so
I
think
I
think
what
happens?
Let's
see,
Constituent.
A
A
Given,
let's
see
I'm
just
gonna
leave
a
few
notes
here:
I
guess
we
have
the
video
open
anyway
given
given
that
you
know
like,
given
that
you're
proving
sort
of
t
send
greater
returns,
it
returns
a
list,
among
other
things,
of
other
things.
You
have
to
prove
right,
which
might
be
like.
If
T
happens
to
be,
let's
call
it
t
you
send
eg,
he
send
you
send
right,
so
it's
gonna
kind
of
and
it
and
it
calls
constituent
types
for
tight
to
do
that.
And
then
it
calls
v
table
Auto
imple,
which.
A
A
Obligation
derive
cause
built-in
derived
obligation.
Oh,
this
line
is
where
we're
actually
making
that
chain.
I
was
talking
about
I,
see,
and
so
what
we
might
do
here.
We
could
instead
sort
of
say:
if
this
is
a
closure,
then
don't
use
the
derived
cause,
but
instead
use
like
obligation.
Clause
clone.
A
We
could
make
it,
maybe
even
a
little
less
a
little
more
local
by
saying
that,
maybe
the
return
type
of
constituent
types
for
tie
instead
of
hard-coding,
that
it's
a
closure
you
could
say
or
maybe
make
its-
that
you
went
I
can't
spell
that
word.
Apparently
one
statue
and
pipes
for
a
tie,
return,
sort
of
a
vector
and
a
boolean
or
something
where
the
boolean
means
you
know
make
derived
cause,
and
that
way
we
only
we
would
literally
change.
A
You
know
we're
putting
all
the
decision
in
that
one
function,
which
feels
good,
so
I
think
that's
what
I
would
do.
Okay
and
this
line
you
can
leave
alone.
What
this
is
saying
is
it's
going,
and
this
is
this
line
is
making
this
the
sub
obligations
based
on
the
type,
and
this
is
making
other
obligations
based
on
the
trait
like
if
the
trait
has
super
predicates
or
something
like
that
which
actually
are
illegal
now.
This
is
probably
no
up
anyway,
but
it's
a
different
thing
different
different.
A
A
Fun
so
I
guess
what
we'll
do
overall
you'll
try
that
out.
We
can
pull
this
list
here,
I
mean
I,
guess
I
can
just
move
the
heading
down.
This
is
kind
of
our
roadmap
and
then,
when
next
time
we
talk,
we
kind
of
already
know
the
plan.
We
can
figure
out
the
next
step,
but
it
seems
like
maybe
this
could
be
on.
This
is
a
something
I
can
do
it's
not
too
hard.
Oh.