►
From YouTube: 2021-01-12 Lang Team Triage meeting
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
A
Let's
go
down
the
list.
I
again
this
will
hopefully
start
changing,
but
I
haven't
had
time
to
do
any
pre-work
on
the
agenda,
so
people
should
feel
free
to
throw
things
in
that
need
updates.
Are
there
comments
or
updates
on
any
of
the
active
projects,
constant
evaluation,
async
foundations
macro
I
saw
there
was
some
posts
in
the
macro
repetition
counts,
but
I
think
we
also
may
have
lost
our
liaison.
Is
that
correct?
A
A
A
C
This
introduces
a
not
gaps
but
similar
in
intent,
type
that
can
be
used
to
keep
the
option-ness
or
resultness
of
something
through
a
question
mark
the
default
question
mark
d.
Sugar
could
not
use
that
one
for
compatibility
reasons,
but
it
could
be
used
inside
a
try
block
if
we
chose
to
go
that
direction
for
try
blocks
and
it's
also
valuable
to
the
library
where
unstable
methods
like
iterator
try
find
would
like
to
be
able
to
use
it
as
well
as
a
couple
other
things
like
there
was
a
pr
recently
for
try
map
on
arrays.
A
D
C
A
B
B
Be
valuable
to
do
the
brief
overview
in
this
meeting
and
then
a
design
meeting
tomorrow,
with
the
hopes
that
in
between
there,
people
may
have
an
opportunity
to
take
a
look
over
the
rfc,
it's
relatively
straightforward
as
an
rfc.
But
yes,
the
discussion
will
go
better
if
people
have
had
a
chance
to
read
it.
A
E
B
A
A
B
Part
of
the
reason
that
I
thought
it
was
worthwhile
to
go
ahead
and
get
that
discussed
was
that
I'm
hoping
that
if
this
proposal
is
reasonable,
that
we
might
be
able
to
get
this
handled
roughly
speaking
by
the
edition,
it's
not
edition
tied,
I
I
don't
think,
and
I'm
hoping
that
doesn't
change,
but
on
the
off
chance
there
is
any.
In
addition,
interaction.
It
would
be
nice
to
be
able
to
handle
that
in
a
timely
fashion.
It's
been
open
for
far
too
long.
A
It
has
been
open
for
far
too
long.
All
right,
let's
do
the
let's
do
the
meeting
tomorrow,
but
you
know
felix,
don't
feel
obliged
to
do
the
reading
and
if
you
can't
attend
that's
also,
okay,
I
can
catch
you
up.
I
guess
I
don't
think
we'll
make
any
decisions
anyway
right.
It's
kind
of
a
dig
into
the
rfc
and
understand
it
meeting,
but
no
we
don't
make
decisions
in
meetings
so.
A
A
C
A
A
D
A
Agree,
I
am
I'm
trying
to
figure
out
if
we're
ready
to
do
yeah.
Okay,
so
we
need
a
stabilization
report.
The
main
thing
I'm
wondering
about
is:
do
we
want
to?
Would
we
want
to
stabilize
before
we've
done
the
addition
work,
or
we
want
to
wait
to
make
sure
that
we're
going
to
get
that
work
done
or
whatever
it's
kind
of
incurring
a
certain
amount
of
obligation?
Maybe
but.
B
Well,
even
how
little
breakage
we
observed,
I
mean
we
observed
enough
in
crater
that
we
did
not
want
to
just
migrate
directly
and
say
pattern.
Has
this
behavior
in
all
editions,
but
we
did
not
observe
so
much
that
this
seems
like
it
is
worth
taking
a
disproportionate
amount
of
time,
implementing
a
lint
to
very
carefully
scan
macro
tokens
and
follow,
sets
and
similar
and
try
to
figure
out
if
you
can
be
migrated
over.
B
B
D
Think,
because
of
the
interaction
with
macros,
at
least
my
concern
would
be
that
if
we
don't
give
a
lint,
not
necessarily
migrating
but
telling
you
that
you
have
a
problem,
it
is
really
easy
to
migrate
to
2021
and
break.
You
know,
potentially
all
of
your
users
or
a
good
chunk
of
them,
who
are
using
the
sort
of
broken
behavior
right.
D
B
D
B
A
E
A
Simple
as
looking
at
the
follow
sets
like
well,
I
think
what
I
had
thought
about
the
last
time
we
did.
This
was
thinking
that
we
can
probably
have
some
simple
heuristics
that
cover
a
lot
of
cases
and
we
needed
someone
who
was
willing
to
do
some
experimenting.
However,
I
didn't
do
any
of
that
experimenting.
I
do
think
we
compute
the
follow
sets
already
in
order
to
because
we
make
errors
right
for
if
they're
not
correct,
so
we
may
have
all
the
data
we
need
and
just
need
to
inspect
it.
A
C
I
feel
like
there's,
probably
two
common
patterns
for
how
people
actually
make
their
macros
work
like
this
right.
The
people
who
have
a
comma
question
mark
in
the
new
way
or
who
use
the
move,
the
comma
outside
the
parent
trick
to
call
the
other
arm
of
the
macro.
And
if
we
handled
those
two,
then
that
would
probably
get
pretty
much.
Everyone.
A
I
don't
know
it
seems
a
little
too
in
the
leads
to
dig
into
right
here,
but
the
main
thing
is:
can
we
find
someone?
Is
there
someone
who
will
do
this
and
how
can
we
figure
that
out?
But
I
will
I
propose
that
we
we
message
to
mark.
I
am
to
ask
them
to
do
a
stabilization
report
and
or
maybe
I'll
ping.
Actually
they
may
want
to
do
the
migration.
Then
too,
I
don't
know
you
can
ask
them
how
they
feel
about
it.
A
B
C
E
E
D
D
A
A
A
F
B
A
E
Never
dereference
never
again
yeah.
I
did
look
at
this.
I
haven't
implemented
a
fix
for
it
yet,
but
the
interesting
thing
I
did
discover
is
that,
while
let
underscore
equals
blah
blah
doesn't
do
unsafe,
checking,
let
underscore
colon
type
equals
blah.
Blah
does
do
unsafe,
checking,
which
was
shocking
to
ralph
and
adam.
I
argue
a
little
upset
so
anyway,
there's
there's
some
hint.
This
is,
I
suspect,
the
compiler
bug
and
there's.
E
The
interesting
thing
to
me
is
that
someone
responded
that
that
observation
by
saying:
oh,
let's
bring
these
things
consistent
and
the
way
that
the
way
they
made
it
consistent
was
by
making
type
its
type
description,
not
cause
this
to
happen,
as
in
you
know,
it
would
still
fail
on
safety
check.
Even
we
had
the
type
description,
but
ralph
rightly
said
we
haven't,
decided
that's
the
right
direction
here
anyway,
I'm
I'm
still
trying
to
figure
out
the
actual
fix
to,
because
I
assume
we're
gonna.
E
The
plan,
still,
I
believe,
is
to
move
forward
with
doing
on
safety
checking
on
the
expression.
There
is
one
thing
that
came
up
pretty
recently.
Someone
asked
someone
gave
me
a
correlated
example
of
doing
a
draft
of
an
uninitialized
val.
What
was
it
a
draft
of
an
initialized
reference
and
then
likewise
was
the
case
where
it
was,
you
know,
being
bound
to
a
let
underscore
and
thus-
and
that
also
was
accepted
by
the
compiler
and
for
some
reason
in
my
head.
E
A
E
Yeah
yeah
borrow
checking
we
eject
a
type
description
statement
and
that's
treated
as
a
use
and
ends
up
causing
the
the
checking
to
then
admit
that's
interesting
to
check
this
is
this
is
the
example
that
I'm
saying
is
also
accepted
right
today?
Oh
somebody
just
write
it
in.
I
think
someone
actually
already
just
inlined
it
yeah
someone
else
transcribed
it.
E
So
the
point
is
this
is
sort
of
analogous,
depending
on
your
point
of
view
in
terms
of
whether
it
should
be
also
a
bug
or
not,
that
this
is
that
this
doesn't
cause
the
borrow
checker
or
the
initialization
checker
to
complain,
but,
like
I
said
for
some
reason,
my
head
isn't
as
bothered
by
this.
Probably
because
I
don't
know
I'm
going
to
treat
this
more
of
as
a
semantic
analysis
rather
than
a
syntactic
one,
and
I
appreciate
safety
checking
as
being
more
syntactical.
A
A
E
A
D
D
A
Think
that's
the
correct
fix.
I
think
it
should
be
done
on
hair,
but
that
kind
of
informs
my
intuition
also
of
like
why.
I
think
I
just
think
of
unsafe
as
a
static
sort
of
right,
simple
syntactic
check-
and
this
is
this-
these,
like
borrow
check,
is
very
flow,
sensitive
and
all
about
actual
uses
and.
A
But
really
crappy.
This
is
how
we
fix
the
dead
code
thing
too
right.
If
I
recall
we
had
the
same
problem
around
other
kinds
of
dead
code
when
we
first
released
the
thing
it
was
like,
ignoring
unsafe
in
dead
code
yeah,
and
we
kind
of
fixed
it
by
running
it
before
we
do
dead
code
stripping,
which
I
always
thought
was
the
wrong
fix,
and
now
we're
paying
for
that.
I
guess
yeah,
but
there.
C
E
A
On
hacks
to
keep
this
because
it's
just
the
wrong
place
to
do
it,
but
the
only
reason
we
even
moved
it
to
mirror
is
because
we
wanted
it's
something
to
do
with
like
the
hidden
drafts
around
packed
structs.
If
I
recall
we
wanted
to
make
the
accessing
a
field,
oh
it's
getting
a
little
vague.
I'm
not
sure
why
mirror
makes
this
easier,
but
that
was
that
is
my
memory
of
the
region.
Was
it
had
to
do
with.
E
A
E
A
E
A
E
C
A
As
another
example,
that's
consistent
with
this,
if
you
say
let
mute
x
equals
22,
let
y
equals
ampersand
at
x.
No,
no!
Let
y
equals
yeah,
let's
say
ampersand
mute
x,
but
underscore
equals
x,
drop
y
or
something
I
think
this
also
compiles,
even
though
x
is
borrowed
here,
because
we
don't
consider
this
an
access
so
yeah,
it's
just
sort
of
the
whole
family
of
things
that
we
accept,
and
I
that
are
all
based
on
the
notion
of
what
an
access
is.
E
It
seems
yeah
like
one
looks
at
this
and
says
it's
truly
seems
totally
useless.
It's
more
that
it's
meant
to
be
consistent
with
the
use
of
underscore
in
more
complicated
patterns
where
you
really
don't
want
to
read
something
in
it.
Yep
it's
valid!
Yes,
exactly.
If
you
move
half
of
a
tuple
or
something.
A
C
E
A
E
A
A
E
E
A
D
I
think
someone
was
going
to
look
at
whether
it
was
type
relative
or
not,
and
I
think
we
concluded
that
it
was
and
that
the
only
new
thing
was
the
ability
to
say
as
whatever.
But
I
think
we
also
maybe
nico,
were
you
going
to
like
actually
figure
out.
If
that's
actually
true
and
or
I
think
we
were
going.
A
A
I
don't
remember
let's
just
I
do
remember
the
thing
about
the
only
real
new
thing
here
was
I'll
have
to
go,
find
the
minutes
from
last
time.
We
did
some
digging
and
I'm
pretty
sure
the
only
new
thing
indeed
was
the
fact
that
you
can
now
use
the
fully
qualified
syntax
that
before
you
could
do
it,
but
only
with
the
shorthand
and
that
I
think
made
everyone
feel
fine
about
it.
A
B
D
A
A
A
A
A
A
A
E
E
The
problem
of
a
problem
of
80394
is
that
if
you
land
that
it
creates
a
runtime,
a
seemingly
runtime
expression
that
has
a
division
by
zero
in
it
as
a
something
that's
going
to
cause
the
future
incompatibility
warning
to
fire
because
it
gets
promoted
and
then
and
then
evaluation
time
at
compile
time.
It
has
division
by
zero.
This
fixes
that
by
no
longer
doing
division
no
longer
promoting
division,
because
it's
something
that
can't
in
general
always
evaluate.
A
D
D
F
D
E
A
A
F
F
E
C
B
A
A
A
Right,
the
motivation
may
just
be
as
simple
as
it
sounded
funny,
but
that
would
be
okay,
but,
like
he
says
in
the
comment,
I
feel
the
current
state
is
fairly
unintuitive.
I
suspect
the
motivation
is
kind
of
the
it
didn't
seem
as
elegant
as
it
could,
but
that
it
would
be
good
to
know
if
there's
more.