►
From YouTube: 2021-03-16 Lang team triage
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,
welcome
please
sign
in
and
who
would
like?
Can
one
of
you
take
notes
today.
A
It
goes
all
right:
okay,
upcoming,
scheduled
meetings.
Tomorrow
we
have
the
rfc
backlog.
Bonanza
recap
the
document
for
this
I'll
post
it
in
the
issue,
but
it's
the
paper
doc
from
before
the
plan
was
to
go
over
and
check
how
well
we
did
or
did
not
do
at
following
through
on
that,
so
I'll,
just
post
it
right
now,
paper
document,
okay,
and
after
that,
these
two
I
will.
A
B
Yeah
yeah,
I
have
something,
but
I
realize
there's
more
stuff.
I
need
to
probably
get
into
depth
about,
or
I
might
want
to
ralph
to
be
honest,
but
I
should
have
something
in
time
sounds
good.
A
Action
items
I
at
least
got.
I
don't
know
what
happened
last
week,
something
I
didn't
check
a
lot
of
my
boxes.
I
don't
know
about
the
rest.
Y'all
looks
like
we
need
to
follow
up
on
khan's
2b
and
do
a
few
other
things,
but
if
you're
on
that
list,
do
it
so
let's
go
move
forward.
We
have
this
pending
proposal
allowing
the
compiler
to
eagerly
drop
values.
A
I
don't
we
had
some
discussion
about
it
last
time.
I
think
there
was
a
request
to
move
some
of
that
content
into
the
proposal.
I
can't
remember
where
we
landed
on
this.
Has
anyone
been
keeping
up
with
it?
A
C
C
Yeah
postponing
it
seems
like
a
reasonable
step
and
yes,
asking
one
of
the
people
proposing
it
to
summarize,
the
discussion
so
far
might
be
potentially
viable.
C
A
A
A
A
A
Guess
so,
there's
an
action
item
to
follow
up.
Is
anyone
involved
in
this
conversation
who
wants
to
take
that
on.
A
Has
there
been
any
follow-up
here?
I
did
not
do
my
homework.
I
know
other
boxes
were
unchecked
of
people
to
do
our
homework
of
leaving
comments.
B
So
ralph
responded
to
some
of
the
feedback.
Mostly
in
terms
of
you
know,
I
tried
to
reiterate
like
be
good
to
answer
the
questions
that
mark
posed
and
ralph
basically
confirmed
my
hypothesized
summary
of
what
the
actual
effect
of
this
is.
C
Ralph
also
updated
the
rfc
to
make
it
abundantly
clear
what
some
of
those
things
were
that
I
don't
I
understand
where
he's
coming
from
that
it
felt
like
it
was
saying
those
things
already,
but
I
think
he's
updated
it
to
the
point
that
it
restates
it
in
enough
places
it's
hard
to
miss.
A
D
Dude
I
I
I
haven't.
I
see
that
there
are
still
comp
like
new
comments
as
of
like
a
day
ago
and
today
and
hours
ago,
so
I'm
not
caught
up
now
really.
D
Yeah
yeah,
the
threading,
the
threading,
okay,.
B
Was
this
this
is
just
me
I
was.
I
was
complaining
saying,
like
you're,
making
statements
about
like
the
obvious
okay,
so
there's
some
in
case
just
everyone
on
the
same
page.
The
the
basic
summary
here
is,
I
understand
that
ralph
has
confirmed.
Is
that
what
this
rf
rfc
is
really
saying?
Is
that
all
detect
all
undetected,
undefined
behavior
versus
during
compile
time
function?
B
Evaluation
will
be
quote
unquote,
non-consequential
and
what
that's
supposed
to
mean
is
basically
that
there's
going
to
be
an
obvious
semantics
to
what
those
constructs
actually
evaluate
to,
and
we
will
follow
that
obvious
semantics
and
my
complaint,
then,
was
to
say
I
don't
think
the
semantics
is
necessarily
obvious,
and
I
gave
the
concrete
example
of
unaligned
addresses
and
gave
two
different
interpretations
of
what
that
could
mean
to
evaluate
that,
and
so
ralph
has
now
said
what
the
interpretation
would
be
in
such
a
specification.
B
D
D
Right,
which
is
not
right,
so
I'm
considering
that
not
not
undefined
because
we're
defining
it
like
undefined
behavior
in
the
sense
of
like
like
we,
you
know
we
might
blow
up
your
code
right.
Who
knows,
what's
going
to
happen
like
we're
saying
we
will
provide
a
guaranteed
behavior
in
response
to
all
codes.
B
A
E
A
F
A
That
that
taylor,
your
point
is
kind
of
this-
is
there's
sort
of
mixed
messaging
around.
How
undefined
is
it
and
what
exactly
are
we
guaranteeing
and
not
guaranteeing,
and
if
we
have
it,
it's
not
a
simple
story
that
you
can
easily
explain.
D
This
is
extraordinarily
subtle
to
the
point
that,
like
I
still
don't,
I'm
still
not
sure
like
what
exactly
like
like
who
is
allowed
to
rely
on
what
behavior,
where
or
or
if
it
seems
like
that
we're
trying
to
like
make
guarantees
without
anybody
relying
on
them,
and
we
want
to
say
that
things
have
enough
like
an
obvious
semantics,
but
not
describe
what
that
semantics
is,
except
where
we
throw
an
error
and
the
places
we
throw
in
error
is
undefined,
but
except
for
some
places
where
we
throw
an
error
that
are
guaranteed.
D
I
I
don't
know
I
I
feel
like
I'm
coming
off
really
negatively
on
this,
which
maybe
is
like
I
don't
know,
maybe
is
how
I'm
feeling.
But
I
I
like
really
respect
that.
There
are
a
lot
of
people
who
put
a
lot
of
thought
into
this
and
know
much
more
about
this
space
than
I
do.
But,
but
it
seems
like
a
really
non-obvious
thing
to
like
the
advantages
of
providing.
This
guarantee
to
users
seem
really
non-obvious
to
me.
A
I
guess
I
not.
I
would
like
to
drill
a
little,
but
on
the
thread
not
live
unless
ralph
we're
here
or
something
into
what
what
advantage
this
rfc
offers
over
sort
of
the
tool.
I
know
what
the
advantage
is
over,
guaranteeing
that
we
detect
all
ub,
which
seems
to
be
compile
time
from
what
I
can
tell
or
that
plus
the
ability
to
do
optimizations.
A
D
F
We
can
make
the
code
simple
and
only
detect
ub
when
sort
of
the
the
evaluation
detects
it,
but
we
could
also
do
sort
of
a
more
invasive
right
like
what
we
discussed.
I
think
last
meeting
in
terms
of
whether
we
are
permitted
to
do
any
optimizations
on
mirror
before
running
constable
and
and
whether
we
can
even
run
constable
sort
of
on
unoptimized
versus
optimized
mirror,
because
they
could
have.
You
know
different
semantics.
A
A
D
D
The
obvious
semantics
for
like
accessing
like
a
local
variable
after
it's
been,
you
know,
moved
from
or
something
like
that,
like
a
pointer
to
it
or
like
it
doesn't
have
an
obvious
semantics
right,
and
so
that's
a
case
where,
like
you,
could
make
up
one.
But
it's
probably
not
going
to
be
the
thing
that
matches
what
you
get
if
you're
doing
an
nrvo
past
right.
A
F
F
B
Before
we
agree
to
that,
I
I
still
feel
like
like
ralph
is
pretty,
it
seems
like
ralph
is
at
least
annoyed
by
the
process.
This
point,
or
has
been
for
a
little
while
and
doesn't
know
how
to
further
approve
the
dock.
To
like
respond
to
what
we've
said,
are
we
expecting
to
have
from
the
discussion
on
thread
something
some
sort
of
concrete
feedback
for
ralph
to
move
this
forward
or,
what's
going
to
happen.
A
F
And
I
think
at
this
point,
my
feeling
at
least
is
that
one
thing
that
might
be
helpful
is
to
tell
ralph
that
I
think
it
is
true
that
there
is
not
at
least
explicit
alignment
within
the
link
team
in
the
sense
that,
like
the
comments
being
given,
are
not
necessarily
in
the
sense
of
saying
no
here
in
the
sense
of
trying
to
you,
know,
continue
discussion.
C
C
Yeah,
I
I
think,
on
balance,
it
is
safe
to
say,
nobody's,
saying
we
absolutely
shouldn't
do
this,
we're
just
trying
to
get
a
very
clear
picture
of
exactly
what
this
is
and
it
seems
like
we're
not
necessarily
disagreeing
on
principle.
Nobody's
j,
for
example,
taylor's
comment
about
wanting
to
make
sure
that
we're
not
promising
these
under
all
circumstances
as
a
guarantee,
nobody
jumped
up
and
said
no,
we
should
absolutely
promise
these
under
all
circumstances.
The
question
was
whether
the
rfc
was
claiming
that
we
were.
D
I
would
be
fine
with
like
being
in
the
minority
here
and
saying,
like
there
are
a
bunch
of
smart
people
involved
in
this
discussion.
Who
disagree
with
me
and,
like
I
like,
I
will,
like
you
know,
trust
them
to
have
made
to
look
like
thought
about
this
carefully,
but
I
I
actually
think
I'm
at
the
point
now
where
I
don't
think
that
additional
clarifications
on
the
rfc
are
what
I
need.
I
think
I
actually
just
disagree
with
what
this
rfc
is
doing.
D
I
think
that
I
actually
like
would
prefer
a
world
in
which
some
things
that
you
did
in
const
eval
that
were
undefined
behavior.
We
we
didn't
guarantee
a
behavior
for
even
if
that
means
that
we
in
practice
we
detect
them
and
and
don't
provide
you
know
mere
optimizations
on
ctfe
I
would
prefer
a
world
in
which,
like
we,
we
left
ourselves
the
option
of
doing
those
things.
B
A
A
A
C
A
Change
visibility,
scoping
rules
for
macro
removals
macros,
I
kind
of
think
we
should
just
close
this
rfc
at
present.
It's
mostly
talking
about.
I
think
we
decided
not
to
do
it
for
this
edition
and
whatever
is
going
to
happen,
it's
going
to
require
some
changes
right.
E
A
A
A
C
A
C
Don't
think
it
needs
an
owner
from
our
team,
it
couldn't
hurt
for
us
to
summarize
that
we're
expecting
this
is
the
current
blocker
and
we
would
like
someone
to
determine
that
definitively
one
way
or
another.
A
A
But
can
we
say
it
out
loud
to
make
sure
we're
on
the
same
page,
like
our
understanding
is
I'll?
Tell
you
what
I
think
it
is
we
wanted
to
have.
We,
as
the
link
team,
wanted
to
have
rep
or
c
match
the
c
compiler,
but
there
is
investigation
as
to
whether
that's
possible
or
would
break
too
much
existing
code
because
of
binden
behavior.
C
C
It's
also
worth
noting
bind
gin
itself
is
not
necessarily
a
show
stopper.
As
long
as
there
is
a
way
to
get
the
appropriate
behavior
that
bind
jen
is
expecting.
We
have
had
cases
in
the
past
where
there
was
a
missing
feature
in
the
language.
Bind-Gen
worked
around
it
and
then
the
feature
became
available
and
there
was
a
migration
required
for
when
do
people
want
to
use
that,
so
there
may
potentially
be
a
churn
in
bind
gen
as
long
as
we
don't
actively
break
existing.
A
Code,
okay,
I
see
so
you're
saying
we
can
change
what
codebind
generates
as
long
as
the
code
that
we
know
it
has
already
been
generated
is
like
mostly
still
going
to
work.
Is
that
what
you're
saying
right?
B
Yeah
I
posted
yeah.
I
guess
you
can
write
your
code
example.
First
I
mean,
I
think
the
person
posting
this
or
someone
give
feedback
said
they're.
Basically,
in
short,
that
we
should,
you
know,
disallow
types,
first
class
function,
types
with
an
unsized
return
value
in
general,
though
I
guess
there
might
be
some
cases
where
that
can
work.
I
don't
know
if
there's
cases
that
actually
can
work
and
like
I
don't
know,
if
there's
we,
since
they
can't
compile
it
today
anyway,
there's
no
harm
in
just
allowing
it
right.
A
A
A
The
return
type
there
have
been
proposals
for
what
an
unsized
type
might
mean
there,
but
not
none
that
have
gotten
that
seem
to
me
to
sort
of
they're
all
kind
of
complicated.
I
don't
think
we've
found
the
the
right
combination,
yet
the
fact
that
output
has
a
size,
bound
kind
of
boxes,
our
kind
of
blocks,
our
ability
to
do.
That,
though,
now
that
we
think
about
it,
because
there's
no
doubt
existing
code,
that
assumes
that
the
output
is
sized.
That
may
not
be
true.
There
may
not
be
stable
code.
A
Without
using
the
shorthand
notation-
and
that
requires
you
to
specify
an
explicit
return
type
so
plausibly-
we
could
remove
the
bound
from
output.
That
would
be
another
possible
fix.
F
Wouldn't
it
stop
compiling,
if
I,
I
guess
no,
that
would
be
overrestricting
yeah.
I
think
you
could
maybe
rely
on
it
today,
but
it
feels
difficult
to
come
up
with
an
example.
A
You
have
to
do
something
like
this
right,
and
that
means
that
r
sort
of
r
will
have
a
size
bound.
E
B
A
A
The
reason
I
I'm
told
about
it
is
that
I
feel
like
that
might
be
a
future
direction.
We
wanted
to
go,
and
I
don't
know
what
we,
if
we
don't
get
a
lot
from
requiring
the
things
are
sized.
Maybe
I'd
rather
have
less
requirements,
but
we
get
at
least
something
probably
the
default.
I'm
assuming
the
traits
have
some
code
in
them.
That's
assuming
that
output
is.
A
A
I
think
we
should
take
it
offline,
but
it
needs
to
be
assigned
to
someone.
I
don't
know
if
I
have
time
to
follow
up
on
it
or
I
mean
how
high
priority
do
we
think
it
is
it's
p
high
for
decompiler,
not
p
critical,
it
doesn't
seem
especially
worse
than
other
unsound
bugs
do
we
know
if
there's
even
stable
code
that
can
be
affected
by
this.
B
That's
the
that's
one
of
the
questions.
People
were
like
searching
for
ways
that
it
could
break
stable,
but
I
don't
think
I
mean
there's
claims
there
there's
a
comment
in
the
middle,
where
someone
says
you
can
observe
the
unsoundness
and
then
there's
like
feedback
like
wait.
This
isn't
actually
observing
them
soundness.
It's
just
a
case
you
might
expect
to
compile
but
shouldn't,
but
it's
not
it
sort
of
depends
on
what
you
define
as
observe
the
unsoundness.
B
I
guess
the
point
like
it
might
not
match
expectations
about
what's
being
allowed
to
compile,
but
it's
not
like,
as
far
as
we
know,
causing
uv.
B
I
take
it
that
if
we
tried
to
add
the
restriction,
your
your
point
is
going
down.
That
path
would
basically
make
it
even
harder
for
us
to
remove
this
restriction
in
the
future.
A
B
B
Well,
I
would
be
willing
to
own
just
adding
the
restriction
or
making
sure
that
it
happens,
or
rather
esteban
is
volunteered
to
add
the
restrictions
for
that
matter.
So
I
think
we
have
all
right.
Let's
do
that.
B
A
A
All
right
next,
one
define
field
element,
reference
number
933.
This
is
a
reference
issue
that
was
nominated
for
us.
The
question
is:
how
do
we
want
to
handle
terminal?
There's
a
specific
comment
from
javi.
A
A
I
don't
know
this
is
a
pretty
detailed.
A
C
B
B
C
Yeah,
I
was,
I
was
gonna
agree
with
that
as
well.
I
don't
think
that
case
three
or
for
that
matter
case
four
is
appropriate.
We
want
to
use
field
for
struts
and
we
want
to
use
element
for
arrays.
I
think
the
only
question
is:
what
is
the
name
of
the
thing
in
a
tuple?
Is
it
an
element
or
a
field.
G
C
C
Yeah,
I
I
think
that,
citing
that
as
precedent
and
saying,
here's
why
we're
calling
them
fields
seems
completely
reasonable
scott.
Do
you
want
to
summarize
that
and
point
to
the
rfc
that
you
just
impressively
remembered.
B
A
Yeah
there's
lots
of
places
where
we
treat
tuples
like
their
structs,
so
that
seems
like
reason
enough:
okay,
great.
Let's
move
on
next
issue;
rename
value,
expressions
and
place
expression
section
to
evaluation
categories.
A
This
is
about
I
don't.
This
is
about
the
section
of
describing
kinds
of
expressions
I
feel
like
we've
had
this
discussion
so
many
times.
I
don't
really
like
evaluation
categories
to
me,
because
it's
maybe
I
do
it
doesn't
sound.
A
C
So,
as
far
as
I
can
tell
the
proposal
isn't
to
rename
either
a
value,
expression
or
place
expression.
It's
what
do
we
call
the
category
of
those
things?
What
whether
something
is
an
l
value
or
an
r
value
effectively.
A
C
B
A
Okay,
consider
deprecating
weird
nesting
of
items.
Oh
we've
been
over
this
a
few
times.
We
decided
not
to
do
this
in
the
current
edition.
I
think
probably
this
can
be
on
like
we
decided
at
some
point.
If
we're
going
to
do
it,
we
should
just
oh
pink
felix
even
proposed
to
close
it
and
we
all
fcp
did
it
so
really.
We
can
just
nominate
this.
I
think
scott
did
leave
a
comment.
What's
the
right
way
to
go
forward
with
2024
scott,
I
think
the
answer
is
implement
a
deprecation
write.
A
G
It's
a
someone
needs
to
write
a
concrete
proposal
of
what
we'd
actually
be
trying
to
defecate
and
then
yeah,
because
we
have
a
bunch
of
vague
ideas
about
it,
but
I
don't
think
there's
a
concrete
description
of
it.
So
that
would
be
needed
and
then
a
limp
for
it.
And
then
we
can
talk
about
the
things
so
yeah.
A
Okay,
I
can
write
a
comment
saying
closing
the
issue
and
saying:
if
anyone
wants
to
pursue
this,
the
way
forward
is
to
propose
a
concrete
lint
as
a
either
as
a
pr
or
project
proposal.
A
Check
it
seems
like
this
was
the
pr
number
71824
check
for
live,
drops
and
constants
after
drop
elaboration.
F
A
But
the
my
opinion
is
that
the
way
it's
implemented
could
allow
that
to
happen,
but
that
would
be
a
breaking
change
right.
A
A
One
thing
that
we
were
discussing
is
what
kind
of
in
the
2021
edition
discussions,
what
kind
of
migration
we
want
here
and
if
any
and
there's
not
that
much
breakage
so
like
on
zulip
josh,
for
example,
we
were
saying:
maybe
we
don't
need
any,
but
we
were
thinking
we
aren't
ready
to
give
up
yet
on
giving
at
least
giving
users
some
warnings.
A
Oh,
you
know
what
there
was
one
other
thing
minor
thing,
but
I
suggest
changing
pat
to
pat
2015
18
20
yeah,
that's
the
minor
thing.
It
should
probably
be
2015,
because
that's
when
the
behavior
started.
A
C
C
E
C
A
A
G
A
A
Okay,
so
the
context
is
we
were
making
accessing
taking
the
address
of
packed
fields
unsafe,
but
we
now
have
a
safe
way
to
do
it
using
adder
of
and
the
proposal
is
to
start
warning
as
a
future
compatibility
warning
that
will
eventually
become
in
principle,
an
error
across
all
of
rust
to
access
fields.
In
that
way,
although
it
seems
like
the
kind
of
thing
that
may
go
to
this
to
a
hybrid
state,.
B
F
F
F
Sure
about
unsafe,
but
I
don't
know.
B
F
I
think
right,
but
I
think
ralph
is
making
the
argument
that
in
practice,
the
unsafe
block
is
not
necessary.
If
you
do
it
correctly
right,
you
want
to
always
go
through
a
raw
pointer,
and
then
you
will
need
an
unsafe
block
when
you
reference
that,
but
the
creation
of
the
raw
pointer,
which
is
the
correct
action.
It
never
requires
an
unsafe
block
and
we
don't
actually
want
to
support.
Taking
a
reference
directly.
Even
inside
unsafe
blocks
is
the
claim
being
made.
B
B
Essentially,
I
mean
I
still
regard
as
a
simplification
that,
if
this
ever,
if
this
ever
made
sense
in
the
past,
if
you
actually
could
have
a
proof
obligation
that
would
make
the
code
make
sense,
then-
and
we
just
are
saying-
there's
a
better
way
to
do
it
going
forward
in
terms
of
the
point
or
adder
of
then
I
I
think
the
form
that
is
the
old
form
should
still
require
unsafe.
I
just
I
don't
see
the
benefit
to
anyone.
Everything
unsafe.
I
can
understand
you're
saying
about
it.
B
F
Yeah,
I
I
don't
know
I
I
don't
feel
strongly.
I
guess,
but
I
feel
like
the
argument
is
being
made,
and
I
think
correctly
that
people
currently
using
the
unsafe
may
think
that
that
is
sufficient
to
get
what
they
want,
because
that
is
usually
in
some
sense.
True
about
unsafe,
like
they
think
the
proof
obligation
is
is
just
you
know,
actually
exist.
C
If
I'm
reading
this
proposal
correctly,
it's
saying
that
right
now
we're
proposing
to
warn
if
you
do
this
in
safe
code,
and
we
don't
currently
have
such
a
warning,
if
you
do
it
in
unsafe
code
and
the
new
proposed
behavior
is
to
just
always
warn
because
this
is
never
a
good
idea
in
either
safe
or
unsafe
code.
So
it's
not
that
we're
making
it
not
depend
on
unsafe.
It's
just
that.
We
are
saying
we
need
to
complain
at
you
either
way
to
not
do
this.
B
Yeah
all
right,
all
right,
I
I'm
willing
to
after
this
discussion
I
now
realize
I
misinterpret
the
current
state
of
things.
I
didn't
realize
that
we
actually
were
requiring
an
unsafe
code
block
in
every
usage.
Before
I
see
now,
it's
that
we
were
warning
and
saying
you
should
have
an
unsafe
code
block,
but
without
that
I.
C
C
C
B
F
It's
stable
on
nightly
and
beta
and
we'll
hit
stable
in
like
10
days
or
something.
A
A
There's
a
length
of
science
by
using
unsafe.
This
pr
makes
this
a
future
compatibility
warning
lint
and
recommends
the
use
of
adder
of
maybe
it
does
maybe
it
doesn't.
I
should
check
that.