►
From YouTube: 2021-05-11 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).
B
Awesome
so
we
have
three
meetings
scheduled
for
design
meetings
in
the
next
month,
most
notably
tomorrow
we
have
a
generator
planning
meeting
up
for
discussion
may
19th.
We
have
a
discussion
on
guiding
principles
for
rust,
driven
by
some
of
the
work
there.
B
Oh,
that
is
backward
yes
right
19th
we
will
do
some
belated
status
updates
and
the
26th
we
will
do
rest
language
writing
principles.
B
Meanwhile,
as
usual,
please
take
a
look
at
the
action
items
list
and,
if
there's
anything
that
you
either
haven't
done
or
have
done
but
haven't
checked
off,
please
update
that
pending.
There
is
a
pending
proposal
listed
that
I'm
assuming
the
action
item
is
still
the
same
of
summarizing.
The
current
situation.
D
Yeah,
I
I
didn't
nominate
it,
but
we
discussed
in
this
meeting
that
we
were
going
to
emerge
the
over
constraining
and
omitting
unsafe
impulse
rfc,
but
I
have
proposed
merge
and
then
no
one
else
checked
their
box.
So
if
we're
having
second
thoughts
about
that
or
if
it's.
A
B
So
yeah
folks
take
a
look
at
that.
One
there's
also
one
other
one
that
I
proposed
to
merge
84988,
so
that
one
needs
a
look
from
other
people
as
well.
The
short
version
is
that
webassembly
doesn't
have
the
constraints
that
motivated
us
to
originally
make
target
feature
unsafe,
because
webassembly
verification
will
always
make
sure
that
either
you
can
run
something
or
you
can't,
but
you
can't
run
something
your
cpu
doesn't
understand.
B
This
was
on
also
on
the
rfc
bot
list.
I
was
pulling
up
that
list
to
see
if
anything
else
had
slipped
by.
D
D
A
B
Seems
like
a
good
idea,
I
mean
we
might
be
able
to
borrow
some
of
the
summary
code
from
rfc
bot
itself
since
or
rather
rfc.rs,
because
it
would
be
helpful
to
have
the
list
of
who
hasn't
checked
off
as
well.
B
Okay,
going
back
to
items
that
are
on
this
list,
so
I'm
assuming
that
eight
two,
six
three
three
and
eight
four
three,
six
six,
don't
have
any
current
updates
at
this
time.
A
A
We
decided
that
I
think
we
decided
we
don't
like
we
we
narrowed
down
to
the
approach
we
want
to
do,
which
was
basically
what
esteban
did
in
his
pr,
except
that
for
some
reason,
the
pr
has
a
lot
of
kind
of
little
ifs
and
conditions
and
stuff
that
makes
it
more
complicated
than
it
seems
like
it
should
be.
So
the
action
item
now
is
to
spend
some
more
time
trying
to
reproduce
where
all
those
came
from
and
why
they
seemed
necessary
and
how
we
could
fix
it.
A
So
we
made
some
progress.
We
ruled
out
of
the
three
approaches
we
narrowed
it
down
to.
One
just
didn't
quite
understand
why
the
pr
had
as
many
caveats
as
it
did.
A
E
B
E
B
Okay,
then
one
we
don't
have
any
notes
on
is
eight
four
five,
three
three
functions,
closures
and
higher-ranked
trait
bound
trait
objects
can
implement
traits
such
that
the
validity
of
associated
types
is
never
checked.
A
Yeah
that
I
haven't
had
dumbest
time
to
dig
into.
I
think
it's
if
I
remember,
I
think
it's
pretty
related
to
some
other
bugs
that
were
long-standing,
bugs
that
we've
been
working
towards
fixing
and
we're
actually
making
some
progress
around
dealing
with
stuff
under
binders
and
so
forth,
but
yeah
none
one
thing.
A
A
A
Inflation,
so
maybe
we
want
to
change
our
triage
report
to
be
critical.
Arguably
I
don't
know
I
would
like
to
have
a
sort
of
soundness
review,
but
I'm
not
sure
that
this
triage
meeting
is
the
best
forum
for
that.
B
A
C
B
Ongoing
discussions
about
where
type
system
soundness
traits
and
similar
should
be
discussed.
I
think
nico.
You
mentioned
the
idea
of
taking
some
of
these
to
wg
traits.
E
This
particular
issue,
it's
really
hard
for
me
to
tell
from
the
I'll
call
it
the
comment
stream
from
the
author,
like
whether
it
really
is
related
to
a
pre-existing
bug
that
has
been
filed
or
if
they
believe
the
announcements
distinct.
Even
if
it
is
a
long-standing
issue-
and
we
noted
that
the
compiler
team
we
just
said.
We
believe
this
is
a
long-standing
issue.
But
it's
really
hard
to,
like
you
know,
make
sense
of
whether
it's.
A
A
This
is
my
hunch
for
reading
the
example
like
it's,
it's
not
the
same
exact
manifestation,
but
it
is
sort
of
the
same
underlying
problem,
but
this
this
scheme
was
just
flawed,
but
I'm
not
sure
I
have
to
read
it
more
closely.
B
If
we
do
end
up
with
a
deep
dive
meeting,
then
I
may
be
able
to
scare
up
some
additional
type
system
help
to
drive
in
that
direction.
B
B
A
Yeah
only
to
say
that
it
looks
it
feels
very
similar
to
the
prior
pin
on
soundnesses
that
we
had.
I
haven't
quite
figured
out.
If
it's
is
it
some?
A
B
F
One
thing:
I'll:
do
you
want
an
action
item
for
either
of
these.
A
I
don't
know
I
don't
usually
track
that
that
way,
I'll
write
them
down.
One
thing
I
wanted
to
say
is:
I
am
interested
in
some.
I
have
not
figured
out
how
best
to
assess
priority,
sometimes
it's
very
clear
that
something
is
very
important
and
other
times
like
a
lot
of
these.
It's
sort
of
unclear
to
me,
and
so
that's
something
I'm
interested
in
hearing
thoughts
on
if
people
have
them
offline.
B
But
okay
stepping
forward
a
bit,
we
don't
have
any
rustling
reference
nominations
today.
So
let's
go
on
to
nominated
prs
and
issues.
We
have
a
tracking
issue
for
2345,
allow
panicking
and
constants.
It
looks
like
ali
obk
nominated
this
16
days
ago
to
review
a
stabilization
report
proposal.
B
It
does
look
like
there's
some
further
ongoing
discussion,
but
it's
not
clear
if
any
of
that
invalidates
the
stabilization
proposal.
B
It
looks
like
the
main
point
of
continued
discussion
is
whether
we're
on
the
scale
from
hard
error
to
deny
by
default
lint.
We
want
constant,
panics
and
similar
constant
errors.
B
All
right
next
up,
we
have
an
addition
item.
Add
expert
2020x
macro
pattern.
I
believe
there
is
discussion
in
this
context
about
whether
and
what
to
call.
A
Yeah,
I
think,
there's
no
desire
to
do
this
for
the
current
edition.
However,
the
short
version
is
that
we
have
some
divergence
in
the
set
of
expressions
that
we
accept
in
different
places
apparently
over
time,
and
we
may
want
to
sort
of
for
edition.next
a
new
non-terminal
that
or
redefine
the
expert
on
terminal
and
make
some
new
non-terminals
for
the
other
pieces.
I
guess
I
think
I
would
maybe
ask.
B
B
It
sounds
like
the
question
is:
how
do
we
want
to
handle
the
fact
that
expression
syntax
has
diverged
from
what
macro
expert
accepts
and
the
two
independent
questions
are?
What
might
we
do
to
transition
to?
Should
we
transition
to
expert
matching
that
in
a
future
edition,
not
2021,
because
it's
too
late
for
that,
and
if
we
do,
then
what
should
we
use
as
naming
to
facilitate
that
transition.
B
So,
for
example,
we
could
choose
to
switch
exper
over
in
2024
and
have
an
expert,
2021
or
expert
2015,
whatever
we
see
as
an
appropriate
name
or
vice
versa,
we
may
want
to
forward
reference
the
new
expert
syntax
from
the
current
edition,
but
naming
is
not
our
primary
difficulty
there.
The
primary
question
is:
what
do
we
want
to
do
for
this
transition.
B
A
F
Who
cares
unless
it
has
implications
right
for
their
stabilization?
I
guess,
but
it
it.
It
does
feel
like.
What's
missing,
at
least
for
me
is
like
a
sort
of
assessment
from
someone
of
like
I
don't
know,
there's
there's
some
sort
of
vagus
comments,
but
it
feels
like
maybe
petra
shank
off
or
something
could
you
know
say
definitively.
E
A
A
Right
and
it
might
be
that
the
content
is
in
those
paragraphs-
it's
just
it's
not
expressed
in
the
I
have
to
like
sit
and
read
them
to
really
know,
and
I
can't
do
that
so
I
want
it
expressed
in
a
clearer
way,
I'm
willing
to
take
an
action
item
on
that,
but
I'd
also
be
game
to
I'm
also
going
to
propose.
I
think
if,
unless
anyone
strongly
disagrees,
that
we
not
do
this
until
one
of
those
features
stabilizes
or
is
needed
to
stabilize
one
of
those
features.
B
B
B
Well,
I
I
do
think
that
your
point
nico
was
a
good
one
to
start
with,
which
is
we
don't
want
to
try
to
make
forward
progress
on
this
until
one
or
the
other,
or
both
of
those
features
is
stabilized,
but
in
the
meantime
that
gives
people
plenty
of
time
to
summarize
what
we
should
do
going
forward
and
that
one
do
you
want
to
take
the
action
item
for
that
one
or
is
there
anybody
who
could
help
share
that
load
potentially.
E
B
And
to
narrowly
scope
that
action
item,
the
request
does
not
solve
the
problem.
The
action
item
is
get
there
to
be
a
clear
summary
of
desired
behavior
here
right,
so
just
to
make
sure
that
this
is
not
a
solve
the
entire
problem
action
item.
E
B
A
G
A
A
B
A
B
B
Sounds
reasonable,
and
that
is
exactly
the
kind
of
summary
that
I
think
it
will
make
it
easier
for
us
to
figure
this
out.
If
we're
talking
something
that
doesn't
actually
have
any
real
ambiguity,
we
might
not
need
an
addition.
Migration.
If
there's
a
concrete
ambiguity,
then
we
need
to
plan
for
an
addition,
migration,
okay,
does
anybody
else
have
anything
else
to
add
to
84364
before
we
move
on.
B
B
A
B
A
B
A
B
B
All
right
next
up
is
there
new
information
to
be
discussed
on
eight
one.
Seven,
eight
nine
new
lint
for
disc,
detecting
buggy
pointer
to
int,
casts
I
believe.
Last
week
we
had
some
summary
of
what
we
wanted
to
request
in
so
far
as
separating
the
idea
of
solving
the
previous
issue,
with
the
idea
of
coming
up
with
a
lint
that
people
will
find
generally
useful.
A
B
B
But
we
wanted
to
wait
before
calling
that
a
consensus,
because
taylor,
you
were
the
primary
person
with
objections
to
the
previous
approach.
So
we
didn't
want
to
assume
that
we
had
a
consensus
on
a
new
approach
without
getting
feedback.
D
Yeah
I
just
read
that
comment
and
then
also
nico's
response
seems
like
the.
The
remaining
question
is
not
not
about
whether
this
solves
the
original
now
or
the
original
problem
now,
but
about
whether
or
not
this
lint
itself
is
independently
valuable
and
introduces
false
positives
in
terms
of
storing
a
pointer
in
a
u32.
D
D
G
F
B
Yeah,
so
I
would
say
this:
I
have
written
large
quantities
of
a
very
low-level
bit
manipulation
code
for
file
system
stuff
in
rust,
and
I
found
myself
adding
a
lot
of,
as
casts
for
changing
between
various
kinds
of
types,
and
while
I
wasn't
intentionally
stuffing
a
pointer
into
any
of
those
things,
I
was
definitely
stuffing
slices
of
things
and
similar
into
various
places,
and
it's
not
hard
to
imagine
accidentally
having
a
pointer
instead
of
what
I
wanted,
and
it
is
not
super
comforting
that
this
is
actually
an
area.
B
Where
c
would
give
me
more
cross
checks
via
compiler
warnings
than
rust.
Does
because
c
does
tell
you,
even
if
you
cast
that
you
should
not
cast
directly
from
a
pointer
to
a
smaller
than
pointer
sized
integer
type
on
the
platform.
They
don't
care
about
portability.
They
will
warn
you
if
you
do
pointer
to
32-bit,
but
only
if
you're
on
64-bit
it
still
is
a
useful
catch.
To
tell
you
hey,
you
did
something
questionable
here's
how
to
override
that.
If
you
really
wanted
to
do
that.
D
A
It's
a
different
case,
but
I'm
just
thinking
about
one
of
the
worst
rust
bugs
I
ever
had
to
debug
came
from
casting
a
fat
pointer
to
a
thin,
probably
to
a
you
size
where
it
stripped
out
the
the
extra
word
automatically
without
telling
me,
and
then
I
then
I
somehow
got
it
back.
A
B
That's
fair.
Most
of
the
cases
I
was
dealing
with,
I
had
sizes
ranging
from
u8
to
u64,
and
it
would
have
potentially
helped
to
be
more
confident
that
I
wasn't
accidentally
leaving
off
a
dereference
or
similar
and
ending
up
throwing
a
pointer
into
something
whenever
I
use
as
I
do
feel
like,
I
am
telling
the
compiler.
I
know
what
I'm
doing
and
I
don't
actually
want
to
get
rid
of
all
the
guard
whales.
I
just
need
to
make
something
fit
into
something
else.
Yeah.
I
still
like.
G
G
So
tier
to
the
thing,
that's
that
you
were
mentioning
about
the
sea
warnings.
How
do
we
feel
about
lints
that
are
aware
of
the
target
they're
compiling
for
because
we
could
do
the
you're
compiling
for
64-bit?
And
you
cast
to
something
to
you
32,
but
allow
that
on?
If
you're
targeting
a
32-bit
platform
like
would
we
feel
bad
about?
That
is
that
you
know
an
acceptable
trade-off
for
reducing
false
positives.
B
C
G
B
It
you
would
get
the
warnings
precisely
on
the
platforms
that
are
more
likely
to
break.
B
F
F
I
do
think
that
there
is
a
lot
to
be
said
for
for
avoiding
doing
that.
I
know
that
even
today,
sort
of
like
in
rust
ci
if
there's
a
lint
or
something
that
triggers
on
a
I
don't
know
not
usual
lin
configuration
like
even
if
it's
windows,
but
most
people
develop
on
linux
or
if
it's
like,
I
don't
know
rust,
stock
lints,
which
aren't
caught
by
press
c
itself.
F
So
if
you
run
xbox,
if
I
check
it
doesn't
give
you
it
there's
you
know
it
it's
confusing
and
often
painful,
because
it's
either
hard
to
run
those
locally
or
you
have
to
figure
out
what
even
is
being
run
and,
I
think
adding
a
another
dimension
of
you
know.
I
see
a
lint
about
a
cast
that
you
know
I'm
clearly
compiling
the
same
code,
there's
no
configs
anywhere.
A
I
I
I'm
against
it
unless
we
have
a
really
strong
evidence
like
I
feel,
like
that's
a
cure
worse
than
the
disease,
and
that
I
don't,
I
think,
people
who
are
targeting
32-bit,
probably
like
and
only
32-bit,
it's
probably
okay,.
B
That's
an
interesting
point.
The
I
would
also
add
that
I
would
be
happy
to
have
a
version
of
this,
even
if
it
were
something
I
could
opt
into,
and
I
would
happily
opt
into
it
when
writing
a
bunch
of
low-level
code
like
that.
I
certainly
think
this
is
not
something
that
has
to
start
as
a
warn.
B
We
could
make
something
that
starts
as
an
allow
can
be
opted
into,
and
then
that
will
give
us
the
opportunity
to
see
how
well
that
works
in
practice
and
people
can
say:
hey
yeah,
I'm
doing
deny
that
on
my
code
base
and
haven't
run
into
any
false
positives,
but
here's
some
bugs
it
caught
or
even
just
it
makes
me
feel
safer.
G
Yeah,
so
the
the
other
direction
I
think
we
could
go
here
is
we're
having
trouble
with
this,
because
there
isn't
really
another
way
to
do
it.
We
conveniently
have
two
people
here
with
libs
who
could
put
on
live
hats
for
a
bit
if
we
had
a
method
like
I
really
like
the
cast
methods
on
pointers
right
now,
so
that
I
can't
you
know
accidentally
change
the
consonants
of
something
using
the
cast
method,
and
it's
more
likely
that
I
got
get
that
one
right.
G
G
G
B
And,
for
example,
if
you
had
a
truncate
method
that
only
took
integer
to
smaller
integer,
but
otherwise
did
not
let
you
get
away
with
anything
else
that
could
potentially
help
people
not
do
things.
They
don't
mean
to
do
with
az.
H
B
H
C
A
That
still
could
be
fat,
but
I
I
would
agree
with
make
it
explicit:
don't
allow
it
on
fat
pointers.
If
you
want
the
data
pointer
from
a
fat
pointer,
you
can
say
so.
G
A
A
A
B
B
A
B
B
In
any
case,
it
sounds
like
there's
a
family
of
things
going
on
here,
and
this
might
be
worth
a
discussion
inspired
by
this
one
in
a
libs
meeting
to
try
to
figure
out,
or
at
least
for
a
start,
possibly
a
thread
on
the
tlibs
zulip
stream
mara.
What
do
you
think
about
the
two
of
us
starting
something
like
that
for
potential
discussion?
A
B
Sounds
good.
We
should
also
cc
t
lang
to
drag
people
into
that
discussion.
B
Sure,
okay,
then,
let's
hit
pause
on
that
one
for
the
moment
in
favor
of
a
t-libs
discussion
to
give
ourselves
more
options
to
potentially
direct
people
to.
A
So
we
got
josh
and
mara
to
start
thread,
and
is
there
a
actually
in
the
pr
itself?
Should
we
just
close
it
or
we
should
at
least
denominate
it
please,
but.
B
Denominate,
yes,
I
think
we
should
summarize
and
say
we
would
like
to
have
some
libs
options,
or
we
would
like
to
entertain
the
idea
of
some
libs
options
for
alternative
methods
that
are
more
precise
about
what
you
want,
so
that,
if
we're
going
to
lint
against
uses
of
as
we
have
something
more
precise
for
people
to
point
to,
I
certainly
would
be
happier
if
cases
of
false
positives
on
and
as
went,
were
not
steered
towards
as
bigger
number
as
smaller
number.
If
we
instead
had
something
smarter
to
point,
people
to
that
would
be
great.
B
Okay,
let's
move
on,
we
have
six
more
items
in
15
minutes,
so
I
think
we're
not
going
to
get
through
all
of
these.
Would
anybody
like
to
bubble
one
to
the
top
before
we
dive
just
linearly
through
them.
B
Sure,
okay,
all
right!
Let's
talk
about
that
one
briefly
and
then,
if
anybody
else
wants
to
bump
one
of
the
other
five
to
the
top,
then
please
by
all
means
bump
it
up,
so
that
we're
more
likely
to
talk
about
before
the
end
of
the
meeting,
so
84879
add
back
support
for
inner
attributes
on
non-block
expressions.
B
B
B
I
don't
recall
which
one
of
those
was
using
it,
and
there
was
an
issue
with
this
when
there
was
an
attempt
to
rebase,
but
at
the
same
time
the
two
one
of
the
tool
maintainers
was
willing
to
just
drop
the
use
of
it,
so
it
was
not
actually
critical,
but
nonetheless
we
should
still
make
a
an
intentional
decision
here
rather
than
just
well.
I
guess
we've
left
it
this
way
and
we
haven't
reverted.
It.
A
B
A
Also,
I
I
remember
now
I
reread
aaron's
comment.
You
see
that
I
wrote
this
and
aaron
hill
and
he,
although
the
performance
is
not
an
issue
now,
it
sounded
like
the
way
that
they
made
performance
work
was
basically
by
hacking,
like
hard-coding
various
patterns,
which
was
not
great,
so
it
did
affect
my
opinion
somewhat.
I'm
somewhat
inclined
to
that
made.
G
Me
somewhat
inclined
to
just
let
it
stand.
Yeah
aaron's
comment
there
that
says
I'm
fairly
indifferent
to
the
question
of
inner
attributes
in
general.
I
like
agreed
on
that
one
like
for
inside
a
module
or
something
sure,
but
right
I've
never
felt
like.
Oh,
yes,
it
would
be
really
really
handy
to
put
this
inside
the
struct
instead
of
outside
the
struct
and
to
have
it
still
be
a
dot
comment.
B
A
A
That's
not
affected
by
this
change
and
well.
B
One
thought
there:
if
we're
specifically
talking
about
things
like
likely
and
unlikely,
I
don't
think,
there's
a
fundamental
reason.
We
couldn't
make
that
an
outer
attribute
on
the
33.
B
B
A
I
think
in
general
I
would
yeah.
If
else
ambiguity,
I
would
say
like
so
there's
this
right.
There's
this
is
is
very
unclear.
This
doesn't
make
any
sense.
How
do
you
even
tag
the
elf
else
right.
F
A
G
So
if
I
look
at
that
match
example
in
the
notes
right
now,
I'm
pretty
sure
that
one
is
allowed
right
now,
because
that's
a
block,
expression
and
inner
attributes
are
still
supported
there.
I
agree
this
example
is
still
allowed.
A
B
A
B
Well,
I
mean
I
wanted
to
phrase
that
very
openly
like
this
is
not
a
please.
You
know
bow
to
the
consensus
I
genuinely
want
to
ask.
Would
anybody
like
to
suggest
that
there
is
a
reason
we
should
keep
this
and
revert
the
change
based
just
on
what
we
know
today
and
what
people
want
to
do
with
attributes
today
it
broke.
F
B
This
is
true:
do
we
have
a
link
somewhere
for
those
crates
and
have
they
already
been
fixed
in
the
current
version?
I
don't
know
I
can
well,
I
mean
they're
if
they're
public,
then.
A
E
G
C
B
It
looks
like
there's
two
cases,
there's
they're,
they
all
occur
inside
of
a
match.
One
of
them
is
a
dot
comment.
That
probably
didn't
mean
to
be
a
dot
comment,
and
the
other
three
are
lint
allows.
A
F
I
think
if
we
allow
macro
attributes-
and
we
don't
or
you
know,
we
don't
want
to
disallow
them,
then
currently
the
implementation
of
how
we
do
macros.
You
have
to
sort
of
re-tokenize
the
whole
thing
that
you're
passing
to
the
macro,
and
so
obviously,
if
sort
of
you
see
a
potential
call
to
a
macro,
it
carries
some
performance
costs
because
you
have
to
carry
around
that.
G
C
G
F
A
If
the,
if
the
special
ic
or
no
custom
inner
attributes
are
banned,
so
you
only
need
to
pessimize
token
collection.
I
think
the
problem
with
performance
came
about
from
like
expressions
are
super
common,
and
so,
if
it
could
be
on
any
expression,
I
don't
know
we
could
ask.
I
think,
like
just
having
it
applied.
A
match
may
already
be
quite
a
bit
better,
but.
G
H
G
G
B
So
the
two
options
for
us
to
solve
that
are
either
to
rapidly
discuss
it
and
figure
out.
If
we
want
to
let
it
stand
before
it
finds
itself
in
a
stabler
beta
or
alternatively,
to
revert
it
and
then
discuss
it
at
our
leisure
and
phrased
that
way,
even
if
we
want
to
keep
it,
there
is
no
huge
rush
to
keep
it,
but
there
is
a
huge
rush
to
if
we
want
to
not
keep
it.
G
G
B
Would
it
make
sense
for
us
if
we
want
to
phase
this
out
to,
rather
than
just
immediately
remove
it
instead
introduce
a
worn
by
default
or
deny
by
default
lint,
which
would
be.
A
B
A
B
A
G
F
A
B
A
B
Let's
try
to
avoid
keeping
people
too
far
after
the
after
the
hour,
so
I
think
we're
going
to
need
to
take
this
offline
yeah.
B
Okay,
you
said
we:
why
don't
we
leave
a
comment.
E
B
Okay,
let's
let
everybody
go
for
three
minutes
after
the
hour
here
then
thanks.
Everyone
thanks.