►
From YouTube: 2021-02-03 RFC 2229 Sync
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
C
Can
you
and
have
screen
sharing.
B
C
Now
that
looks
about
right,
so
we
have
first
part
of
the
migrations
merged
in
which
is
our
basic
first
pass
I'll,
be
creating
a
pr
for
precise
migrations.
Hopefully
today,
so
I've
been.
C
Means
basically,
if
food.x
is
captured
and
food
artix
is
the
only
thing
that
needs
to
be
dropped.
Then
we
don't
do
migration.
D
C
So
it's
implemented,
I've
just
been
caught
up
with
the
reborrowing
and
I
haven't
got
a
chance
to
just
switch
over
and
build
that
and
just
yeah.
So
hopefully
that
goes
in
reborrowing
is
in
the
works.
I
have
a
question
around
I'll
I'll
I'll.
C
C
No,
no,
no!
She
is
yeah.
She
has
another
meeting
with
her
school
compiler
course
stuff
at
the
same
time,
so
this
was
blocked
on
the
pr
that
got
merged
in
recently,
which
was
the
immutability
one,
because
it
was
generating
fake
warnings,
well
incorrect
warning.
So
hopefully
this
goes
in
soon.
Chris
is
working
on
diagnostics,
on
updating
that
bug
and
actually
updating
the
bottle
checker
to
use
the
diagnostic
information.
That's
now
available,
so
yeah
first
this
and
that
and
throws
going
to
start
working
on
looking
into
what.
Where
is
this?
C
Oh,
oh
sorry,
basically
doing
significant
drops
and
dealing
with
insignificant
disruptors.
So
that's
what
those
gonna
start
working
on,
and
he
also
has
just
adding
some
more
test
cases
to
our
test
suite
with
this
feature
yeah.
So
after
that,
I
think
the
main
thing
that
will
be
left
is
a
little
bit
around
unsafe.
A
At
what
point
I'm
just
thinking
my
biggest
fear
still
is
that
we're
gonna
find
out
that
everything
works
from
a
like
correctness,
point
of
view,
but
we
wind
up
creating
closures
with
way
too
many
fields
or
something,
and
I'm
wondering
at
what
point?
Are
we
going
to
be
ready
to
do
an
analysis
to
figure
out?
If
that's
the
case,
I
guess
we
probably.
C
What
we
can
do,
okay,
so
I
don't
see,
what's
stopping
us
from
doing
that,
right
now,
right,
because
what
do
we
like?
Okay,
so
we
can
do
two
things
either
we
can
use
our
first
pass
of
migration
analysis
to
just
give
us
a
basic
sense
of
idea
as
to
what
needs
to
be
dropped.
What
might
on
like?
What's
the
basic
difference
in
size,
difference
and
second,
question
is:
do
we
really
need
that?
C
Because
all
we
need
is
results
of
min
capture
analysis
when
this
feature
is
enabled,
and
basically
that
will
tell
us
the
number
of
things
we're
capturing
and
we
can
compare
it
to
the
size
of
upwards
mentioned.
A
A
A
A
File
an
for
that
I
can
do
it
if
you
want
but
yeah.
If
we,
I
don't,
think
it's
urgent,
it's
just.
I
would
like
to
track
it.
A
One
more
issue
then,
assessing
size
overhead
from
this
feature,
let's
see
as
discussed
today,
we
should
create
a
custom
lint
that
checks
how
big
a
closure
is
when
using
this
feature,
this
can
be
done
by
looking
at
the
results
of
min
capture
analysis.
C
Okay,
yeah,
it
would
be.
I
I
feel
like
this
is
going
to
be
an
interesting
problem
because
for
small
closures
even
like,
like
let's
say
you
have
a
closure
that
prints
the
x
and
y
corners
of
a
point
now
earlier
was
capturing
just
p.
Now
it's
going
to
capture
p
dot
x,
beta
y,
which
is
2,
which
is
100
increase.
A
Well
but
note
that
I
said
the
size,
I
would
prefer
to
not
measure
the
number
of
fields,
but
the
number
of
bytes.
C
Okay,
let's
just
add
that
to
the
board
as
well
is
that
here,
okay.
C
Okay,
so
yeah,
I
guess
that's
the
update.
One
thing
I
was
curious
about
was
when
we,
so
we
have
something
like
this.
So
what
happens
if
I
not
yeah?
I
think
this
was
another
issue,
but
I
guess
this
question
is
sort
of
similar
is
what
happens?
What
do
we
want
to
do
if
this
is
a
copy
type,
when
we
do
do
a
dereference
in
case
of
a
clause
or
a
move
lawyer.
C
So,
since
it's
getting
moved,
we
will
drop
this
to
b,
regardless
of
this
being
a
move
closure
or
not.
Now,
if
I
drop
the
drop
this
down
to
b,
why
is
this
getting
moved.
D
C
Yes,
today,
it
will
be
a
shared
reference.
You
are
right,
you'll.
C
Yes,
but
now,
if
we
look
at
if
this
was
moved,
then
that
will
create
a
move
for
b
right.
D
C
Let's
consider
both
cases
because
I'm
like
I
would
have
to
handle
both.
So
let's
just
kind
of
write
this
out:
okay,
so
a
non-move.
This
is,
I
mean.
A
C
Yeah,
because
yes,
because
we
just
we
can
just
copy
this
and
an
immutable
bar,
will
suffice
for
that.
D
A
C
This
shows
up,
so
that's
that's
what
I'm
trying
to
figure
out
what
needs
to
happen
there,
because
when
this
shows
up,
we
see
it
as
a
consume
of
b.0,
but
a
copy
type
right.
So
this
is
consume.
A
A
A
A
A
Do
you
have
the
link
to
the
hack
md
we
we
we
had
before?
Yes,
one
second.
C
C
One
second,
is,
I
always
lose
weight.
I
can
see
things
like
where's
chat.
Okay,
I
don't
know,
zoom
shows
to
windows
and
it
always
confuses
me.
Okay,
I
sent
it
in
the
link
and
if
you
want
to
share,
I'm
gonna
reclaim.
A
C
B
B
C
Let
me
share
this
one.
Second,
I
I
added
the.
A
You
will
have
a
ref
up
bar
for
p,
so
right-
and
here
I
guess
this
is
what
I
was
really
looking
for.
This
was
our
previous
algorithm
right.
D
A
A
A
A
C
A
It
would
limit
the
closure
to
not
outlive
the
local
variable
b
and
that's
the
whole
point
of
a
move.
Closure
is
not
to
have
that
limit
right.
C
A
A
So
behavior
just
capture
b,
the
algorithm
above,
is
correct
if
they
wrote
it
like.
A
C
A
C
A
A
Okay,
sorry
yeah,
but
I
don't
think
this
closure
will
be
fn
once.
C
Like
if
you
look
at
e0
the
day,
we
thought
we
mentioned
that
I
guess
with
the
move,
yeah,
even
with
the
move.
If
the
closure
captures
just
b,
actually
no
it
will,
it
should
still
be
fn.
Once
then.
C
So
here's
my
thought
process,
and
so
it's
specific
to
the
fact
that
the
type
that's
being
used
here
is
a
copy
type.
We
are
moving
the
b
box
to
the
closure
and
closure
never
gives
up
b
away.
It
just
gives
up
the
value
b,
dot
zero,
which
is
copied
into
underscore
b.
B
C
C
A
Yeah
I
figured
we
were
having
a
boolean
error
here,
yeah
and
and
what
that
tells
you
is-
and
I
think
we
said
this
the
last
time,
but
if
not,
this
is
a
good
example
of
it
in
order
to
decide
if
something
is
fn
once
or
not
you
don't
look
at
the
things
it
captures.
You
look
at
the
full
places
that
it
actually.
B
C
A
Sure,
there's
not
that
much
to
say
about
it
really,
but
just
that
we
should
add
one.
We
decided
in
the
lang
team
meeting,
we'll
call
it
capture.
A
C
Where
are
you
adding?
This
is
that
on
the.
A
D
D
Match
I
think
this
is
right
yeah,
but
the
re.
A
The
reason
I
bring
this
up
is
I
I
know
the
main
thing
is
I'm
using
ident
here,
which
means
that
you
can.
You
can
write
capture
y,
but
not
like
capture
zero
or
something.
A
I
actually
think
the
latter
is
an
interesting
extension
because,
and
I
think
it
would
actually
just
work
like
if
you
were,
if
you
had,
if
you
were
using.
Let's
say
you
were
using.
C
A
A
This
is
not
a
very
exciting
example,
except
to
say
that
you
might
have
one
where
you
use
a
bunch
of
subpaths,
which
would
otherwise
be
three
different
fields,
but
we
capture
only
the.
C
I
have
only
one
concern
here
is
when
we
say
the
word
capture.
It
doesn't
indicate
that
we
are
forcing
a
move
here.
It
could
just
be,
but
we're
not
forcing
a
move.
A
A
Yeah,
basically,
basically
I
mean,
if
you
have
arbitrary
experts,
it's
a
little
weird
because
you
can
put
stuff
like
you
know
things
that
are
not
places
I
would
sort
of
prefer.
We
don't
have
a
place
and
we
don't
have
like
a
expert
that
that
forces
it
to
be
a
place,
but
that
would
be
my
preference.
You
could
write
the
macro.
I
mean
if
you
wanted
to
get
all
ambitious.