►
From YouTube: 2021-04-27 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
to
this
lang,
team
meeting.
Folks,
don't
forget
to
log
your
attendance
so
scheduled
meetings.
A
We
have
we
had
the
abi
wasm
meeting.
We
should
probably
push
those
notes
into
the
repo.
I
don't
think
I
did
that.
Can
you
take
that
as
an
action
item
mark
yep,
we
had
planned
the
generators
meeting.
I
did
not
hear
anything
from
esteban
whether
there
is
a
document
available
so
unless
he
gets
back
to
us
shortly,
I'll
cancel
the
meeting
and
we'll
reschedule
it
next
time
I
knew
I
do
know
he
was
working
on
something.
A
So
probably
there
is,
but
unless
it's
in
the
issue
I
didn't
actually
look,
doesn't
look
like
it.
So,
okay,
we'll
see.
A
Action
items-
I'm
not
gonna
do
that
live
so
as
far
as
those
pending
proposals,
we
have
allowing
the
compiler
to
eagerly
drop
values
still
waiting
on
some
kind
of
summary.
Sorry,
this
is
not
accurate,
changing
path.
Behavior
of
modules
we
did
an
fcp
to
close.
There
was
no
real
discussion
afterwards.
I
don't
think
there
was
one
comment
which
was
basically
pointing
out
that
there
might
be
reasons
to
use
paths
around
platform
independence
which
we
had
already
talked
about.
I
think
we
should
close
unless
anyone
has
any
objection.
A
Motivation,
yeah
action
item.
To
close,
I
nominate
scott
sure,
since
you
made
the
mistake
of
speaking
okay,
add
const
to
brfc.
Oh
wait.
I
put
this
comp.
This
was
that
was
okay.
C
A
Not
planning
to
close
right,
that's
merge.
No!
No.
That
was
meant
to
be
put
in
this
section
when
I
was
pre,
pre
pre-pre-processing
the
agenda-
I
don't
know,
what's
the
status
of
this,
because
apparently
I
overlooked
it.
I
think
this
is
probably
ready
to
be
merged.
Is
that
right?
It
was
in
fcp
last
I
checked.
A
Welcome
back
josh,
it
looks
like
the
constitute
brc
can
be
merged.
That's
an
action
item.
I
don't
know.
E
D
F
Okay,
you
all
should
have
access
to
the
to
the
rc's
repo.
You
just
need
to
approve
the
pr.
You
can't
push
directly
yeah.
I
had
some.
A
A
A
So
there's
two
p
high
issues,
both
of
which
have
open
pr's.
Probably
I
don't
know
that
we
needed
to
do
any
particular
discussion.
Yeah.
This
is
nico.
Sorry
esteban
opened
a
pr.
I
took
a
look.
I
prepared
an
alternative
fix,
I'm
not
really
happy
with
either
of
them.
I
probably
should
look
again
and
try
to
come
to
a
third
one.
What
this
this
particular
issue
comes
down
to.
A
The
impul
for
the
impul
of
the
fn
traits
for
function
types
is
built
into
the
compiler
and
finding
the
I
want
to
find
the
place
in
the
compiler
that
most
closely
resembles
what
would
happen
if
you
had
written
the
impo
by
hand-
and
I
think
esteban's
is
closer
to
that,
but
has
a
bunch
of
other
stuff
in
it
that
I'm
not
sure
why
it's
there
and
mine
is
a
little
further
away.
On
the
other
hand,
mine
has
less
fallout
and
probably
solves
the
bug
for
now,
and
we
could
probably
revisit
this
with
chalk
or
something.
A
So
I'm
not
sure
I
have
to
look
at
it.
I
don't
know
I'm.
I
guess
this
is
more
of
a
compiler
team
question
around
priority
and
dates
and
everything
how
hard
I
should
work
at
this,
probably
harder
than
I
have
it's
been
out
there
for
a
while,
on
the
other
hand,
it's
kind
of
a
random
both
of
these
bugs
are
like
pi,
because
they
were
recently
discovered
and
we
should
close
them,
but
I
think
quite
old
yeah.
A
Yeah
this
closure
issue
has
to
do
with
sort
of
similar-ish
thing
where
the
built-in
rules
don't
aren't
as
restrictive
as
the
rules
that
your
code
has
to
obey
and
as
a
result,
we
overlooked
something.
I
think
the
fix
that
aaron
put
in
is
probably
the
right
one.
There's
a
pending
pr.
I
haven't
looked
at
it
that
recently,
but
so
I
guess
it's
mostly
a
question
of
fallout
and
whether
we
want
to
do
anything
around
merging
it.
A
Okay
tracking
issue
for
rfc
2345
allow
panicking
and
constants.
We
asked
for
a
stabilization
report
and
we
got
one.
I
haven't
looked
at
the
rest
of
the
thread.
I
don't
know
if
anyone
else
has.
A
C
Sorry,
I'm
just
looking
in
this
now.
It
looks
like
there's
two
unresolved
questions
that
are
still
unchecked
in
the
original
thing.
Should
there
be
some
additional
messages
in
the
error
about
this
being
a
panic
trend
here
or
this
answered
in
the
stabilization
report,
probably
that's
something
I
could
figure
out
asynchronously.
A
Yeah,
I
guess
the
action.
I
think
we
should
all
just
take
an
action
name
to
review
this
and
be
ready
for
next
week
and
if
somebody
wants
to,
I
wouldn't
object
to
you,
know,
moving
to
merge
and
we'll
don't
have
to
check
our
boxes
until
we're
happy
so,
but
let
me
make
an
action
item
to
move
it
to
another
thread
so
that
we
have
the
move
to
merge
is
not
I
like
it's
kind
of
a
mess.
Otherwise,
oh
and
there's
multiple
fcps
on
some
single
issue
in
case
it
doesn't
go
through
I'll.
A
A
We
weren't
really
sure
what
we
wanted.
The
lint
was
not
like
directly
targeting
the
bug
but
did
prevent
the
buggy
case,
or
I
don't
know,
I
don't
think,
there's
been
any
responses.
I
think
this
is
nothing
to
do
here
at
this
time.
C
That
sounds
right
to
me,
although,
like
I
don't
know,
maybe
the
thing
to
do
is
for
other
people
to
read
my
comments,
see
if
it
accurately
like
represents
their
views,
because
there
was
a
lot
of
discussion
on
this
in
the
meeting
and
there
were
a
lot
of
sort
of.
There
was
a
lot
of
back
and
forth,
and
I
I
think
I
I
think
I
summarized
all
the
like
major
things
we
discussed,
but
there
might
be
something
I
missed.
G
G
A
G
D
I
would
say
I
think
the
overall
description
of
we
felt
fairly
hesitant
seems
like
a
stronger
consensus
than
was
present.
Personally,
I
would
love
to
see
this
lint
happen.
I
do
agree
that
all
of
the
stated
related
issues
you
mentioned
were
not
necessarily
covered,
so
I
think
there
is
a
broader
set
of
things
it
needs
addressing,
but
personally
I
would
still
like
to
see
this
lint
happen.
It
just
doesn't
solve
the
full
problem.
C
B
I
definitely
like
all
your
bullet
points
in
there,
though
taylor
that
yeah
absolutely
well
to
me.
A
Shall
we
do
we
want
to
talk
more
about
it
and
try
to
hammer
into
what
you
think
we
should
do
I'd
like
to
I'm
going
to
table
that
and
we'll
come
back
if
we
have
extra
time,
because
I'd
like
to
see
if
we
can
actually
get
through
the
list
for
once,
parser
remove
support
for
inner
attributes
on
non-block
expressions
rust,
eight
three
three
one
two,
this
is
in
fcp
aaron,
left
a
comment
which
I
think
basically
said.
A
We
did
find
some
better
ways
to
implement
this
or
something
but
wasn't
really
objecting
to
the
fcp
per
se.
Others
can
read
it
and
take
a
look.
I
mean
it's
worth
pointing
out
that
removing
these
items
now
doesn't
prevent
us
from
adding
them
in
the
future.
If
we
should
so
choose
so
I
feel
still
pretty
okay,
myself
about
the
fcp
as
it
stands,.
C
B
C
C
A
Newer,
newer
syntax,
we
have
been
using
the
crude
but
effective,
sort
of
per
per
file
check
or
whatever
you
know.
That
means
you
have
to
like
cfg
the
whole
file.
If
it
has
news.
F
C
A
I
didn't
fully
process
that
part.
I'm
glad
you
bring
this
up.
A
I'm
checking
just
to
see,
but
it
sounds
like
you're
correct
that
they
did
once
parse
yeah.
They
definitely
did
parse
before,
because
this
this
compiles
on
nightly
today
or
sorry
nightly,
is
not
the
question,
but
I
don't
need
a
future
gate.
A
F
Right
well,
patrick
does
note
that
there
were
some
stability
holes
right
with
this
whole
thing,
because
attributes
in
general
are
not
we're
not
good
at
checking
stability
on
them.
B
A
G
A
A
Changed
it
from
tt
to
expert?
Oh,
oh,
okay,
yeah!
I
imagine
tt
as
as
scott
pointed
out,
will
probably
still
work
before
and.
F
C
H
A
F
Yeah,
so
this
this
does
fail
with
the
pr
with
x-per
and
I'm
checking
tt
now
for
what
it's
worth
rest
format
eats
the
inner
attribute
in
that
context,
anyway,.
F
C
A
A
A
So
these
are
the
examples.
This
is
what
patreon
gov
quoted
right.
Yes,
so
what
I
understand
is
so
this
parsed,
but
it
would
error,
wouldn't
it
or
okay,
we
just
allowed
it
unstable.
A
A
F
F
C
A
F
F
F
But
but
in
any
case
I
I
don't
know
it
feels
like
we
do
want.
I
generally
also
want
to
be
more
strict
about
stability,
but
I
also
don't
know
that
this
is
the
thing
that
right.
C
H
F
One
thing
that
it
does
seem
sort
of
I
don't
know
potentially
interesting
is
that
if
it
is
true
that
we
can
get
performance
wins
for
you
know
99
of
russ
code
by
not
using
this
like
not
allowing
this
at
all,
which
seems
to
cis.
This
is
like
odd,
but
you
know,
maybe
then
I
don't
know
seems
seems
worth
to
not
allow
it.
F
A
A
Raise
a
concern
to
understand
the
motivations,
because
I
don't
I
didn't
fully
understand
the
back.
I
was,
I
missed
the
backwards
compatibility
concerns
and
then
I
don't
know
it
feels
like
we're
just
removing
something
that
that
works.
It
is.
It
was
past
the
rfc,
but.
F
A
F
B
A
So
I
propose
we
move
on
I'm
going
to
leave
a
concern
and
we'll
discuss
this
a
little
more
on
thread.
I
want
to
try
to
get
to
more
items.
I
don't
think
we're
going
to
arrive
at
a
consensus
in
this
meeting
right
now.
F
I'll
I'll
leave
a
comment
as
well
with,
with
my
point
about
confusion
in
terms
of
what
it
means
yeah.
A
I'd
appreciate
it
and
if
you
could
action
item
for
me
to
leave
a
comment,
so
I
don't
forget:
okay
stabilize
extended
key
value
attributes.
A
I
think
that
the
last
time
we
had
this
discussion,
I
said
what
happened.
We
are
sort
of
waiting
for
right.
There
was
this
question
about
arbitrary
expressions.
That's
what
it
was
so
the
forget
this
comment.
This
doesn't
make
any
sense,
the
pr,
the
pr
stabilizes
arbitrary
expressions
in
that
position.
A
And
it's
not
clear
why
we
would
be
concerned
about
that
specifically.
D
A
Right,
the
only
reason
that
I
can
see-
or
our
hypothesis
last
time
was
that
maybe
there
is
some
reason
regarding
hygiene,
why
we
might
be
concerned,
and
I
guess
that
the
way
I
understand
our
hygiene
system
at
least
that
would
show
up
in
the
form
of
the
spans
that
you
get
from
those
expressions
or
something.
But
I
don't
know
why
it
would
be
any
different,
like
I'm
not
sure
why.
That
would
be
any
different
for
expressions
that
appear
in
that
position
versus
expressions
that
appear
in
the
function
body
or
all
the
other
places.
A
One
could
have
expressions
that
could
get
processed
by
macros
and.
C
I
think
the
last
time
we
discussed
this,
I
had
a
concern
around
the
fact
that
the
macros
being
used
in
these
expression
positions
are
look
like
they're
evaluated
eagerly
here,
which
isn't
something
that
attribute
macros
can
like.
That's,
not
the
normal
behavior
of
attribute
macros.
A
They're
not
actually
about
eagerly,
though,
or
it
depends
what
you
mean
by
eagerly,
I
guess
but
like
if
you,
if
you
have
procedural
macros,
those
procedural
macros,
see
them
pre-expansion.
C
Correct
but
the
dock,
the
two
examples
that
are
actually
given
in
this
in
the
the
pr
at
the
top
that
the
dock
equals
and
the
path
equals
that
sort
of
suggests
like
those
are
built-in
attributes,
so
they
can
do
whatever
they
want.
I
guess,
but
the
fact
that
they
do
something
here
that
is
magically
inaccessible
to
you
know
normal
users
is
upsetting
to
me.
I
don't
know.
C
A
A
A
But
to
be
clear,
like
procedural
macros,
do
they
accept
those?
I
guess
they
do
accept
that
form.
C
C
A
It's
we're
definitely
hitting
like.
I
was
comfortable
because
the
phase
ordering
here
was
the
same
as
macros
that
appear
anywhere
else.
Right
like
there
could
be
macros
in
the
function
body
there
could
be
macros
on
the
fields
or
sorry.
There
could
be
attributes
that
reference
macros
or
there
could
be
expressions
that
reference
macros
in
the
body
and
they
would
none
of
those
get
expanded
at
the
time
your
procedural
macro
runs.
So
it
seems
like
at
some
future
time
we
might
enable
expansion
and
we're
still
uniform
that
procedural
macros
by
default
get
unexpanded
stuff.
A
That
was
my
main
concern,
but
that
wasn't
really
considering
the
user.
Surprise
factor
just
like
the
we're,
not
inconsistent,
vector.
C
F
C
To
clarify
the
issue,
isn't
specifically,
the
issue
is
like
if
I
have
a
macro
macro
like
a
derived
macro,
for
example,
that
lets
you
place
struct
attributes
that
have
key
value
pairs.
F
C
You
would
think
perhaps
like
for
a
command
line
one
like
maybe
you
have
some
help
text,
but
you
want
the
body
of
the
health
text
to
be
in
another
file.
So
so,
as
a
user,
you
think,
oh
I
you
know,
I
can
stick
macros
in
this
key
value
position
right,
and
so
I
would
stick
an
include
stir
to
include
in
the
contents
of
my
you
know:
external
help,
documentation
right
right.
F
Because
you
can
just
put
that
include
stir
as
an
expression
wherever
you
need
that
help
documentation,
just
like
any
other
expression,
if
you're,
not
parsing,
that
express,
like
the
the
macro
call
still
parses
as
an
expression
and
everything
right
so
like
there
should
be
no
problem
with
moving
that
token
thing
to
some
other
location,
for
example.
In
I
don't
know,
printf
call
and
and
so
as
long
as
you
don't
actually
need
to
know.
What's
inside
the
like,
if
you
don't
care
that
the
compiler
does
the
sort
of
include
for
you,
then
it
should
work.
F
Fine,
if
you
want
that,
then
like
we
just
don't
support
that
today.
C
Maybe
that
wasn't
a
great
example.
I've
wanted
this
before,
for
example,
for
like
include
banging
another
file.
I
know
there's
like
there's
some
proc
macros
out
in
the
world
that
do
crazy
things
where,
like
you,
give
them
a
string
and
then
they
go
and
open
the
file.
C
That
is
at
the
position
of
that
string
and
then
parse
that
file
for
some
syntax
thing
that
exists
like
in
in
multiple
crates
in
the
real
world,
and
I
would
like
the
ability
to
have
it
do
something
else,
and
so
like
a
natural
thing
to
me
to
have
to
do
would
be
to
pass
it
like
an
inline
syntax,
but
use
like
an
include
bang
to
pull
in
that
other
file.
Yeah.
F
C
B
B
A
B
E
E
F
E
A
C
A
A
A
All
right,
I'm
gonna,
move
on
then
and
assume
that
anyone
who
wants
to
raise
a
concern,
it's
on
your
own
conscience
or
ask
asks
mark
to
put
an
action
item
for
you
and
this
one.
I
would
like
to
get
to
because
it's
kind
of
relatively
timely
we've
finally
settled
on
pat
prem
as
the
name
for
patterns
oops,
sorry
felix,
and
I
guess
I'm
not
interfering
with
you
by
putting
my
own
cursor
there
anyway.
A
We
finally
settled
on
pat
param,
but
there
is
a
question
of
whether
pat
2021
as
a
name
should
still
exist
or
whether
we
just
want
to
have
pat
sort
of
the
only
way
to
get
the
the
dish.
The
new
edition
semantics
is
to
be
in
the
new
edition
and
using
pat
sorry,
including
the
or
the
including
ore
patterns,
and
the
prs
stands,
keeps
pat
2021
as
the
explicit
way
to
say
it
and
just
changes
what
pat
maps
to
either
it
maps
to
pat
prem
or
to
pat
2021
at
first.
A
I
did
not
like
that,
but
upon
consideration
I
decided
that
I
did
because
it
seems
to
be
the
direction
we're
going
is
that
we
would
expose
features
in
older
additions
via
less
good
syntax,
and
this
is
a
sort
of
precedent
or
this
seems
to
fit
that
model,
and
it
also
gives
people
a
way
to
you
know
migrate
forward
if
they
want
to
eagerly
adopt
this
new.
E
What
you
say
about
the
syntax
and
all
their
editions,
like
dk
hash
thing,
is
not
necessarily
about
making
things
like
backboarding
things,
it's
more
about
making
things
possible
without
having
to
wait
for
the
new
edition.
But
I
don't
think
if
we
are
already
in
say
the
2024
edition.
It
already
exists
and
we
add
something.
I
don't
think
we
want
to
like.
Add
it
to
the
older
ones
like
we
could.
But
that's
not
the
main
point.
A
A
E
A
B
A
You
don't
need
it
yeah,
mario.
A
D
In
terms
of
naming
the
for
pat
param,
it
made
sense
that
we
know
what
the
pattern
represents
relative
to
other
things
for
pat
2021.
I
think
the
name
pat
2021
makes
sense,
because
at
the
moment
the
only
thing
we
know
is
this
is
patterns
as
defined
in
the
2021
edition
in
the
future
in
2024
or
2027.
D
If
we
come
up
with
a
new
extension
to
patterns,
then
we
may
decide
to
add
an
alias
for
pat
2021.
That
explains.
Oh,
this
is
patterns
without
this
thing
or
come
up
with
a
positive
equivalent.
The
way
we
did
pat
param,
but
we
don't
know
what
that
is
yet
because
we
don't
know
what
it's
relative
to.
A
Right
if
its
purpose,
as
I
see
it,
the
purpose
of
this
is
to
allow
people
to
opt
in
to
the
semantics
before
the
addition
is
stable
and
just
I
guess
going
forward,
and
for
that
purpose
the
name
2021
feels
like
a
tolerable
name.
I
think
that's
the
same
sort
of
the
same
point.
You
were
making
josh
but
slightly
different.
E
E
A
A
A
E
The
same
ones
as
that
I
had
for
renaming
that
2015
to
something
more
reasonable.
In
this
case,
I
think
something
more
reasonable
is
just
not
naming
it.
A
E
A
Pat
2015
did
not,
but
that
doesn't
seem
to
apply
to
pat
2021,
because
I
don't
expect
people
to
use
it
unless
they're
trying
to
jump
forward
in
time.
And
then
the
year
is
the
right
thing.
But.
A
E
G
Yes,
I
have
to
admit
I'm
I'm,
even
though
I
do
a
spouse,
the
thing
that
nico
mentioned
earlier,
I'm
finding
it
pretty
hard.
I
think
I'm
in
mars
camp
here.
I
think
pretty
somewhat
hard
to
believe
that
at
least
very
many
russ
developers
are
gonna
understand
the
idea
that
josh
is
putting
forward
that
someone
is
like
you
know,
wants
to
be
sure
that
their
code
is
going
to
be.
I
operate
the
same
way,
regardless
of
what
happens
in
the
future.
I
just
don't
know
if
it's
realistic
expect
people
to
do
so.
D
G
Okay,
but
at
that
point,
if
you're
actually
talking
about
maintaining
the
code,
then
you
could
presumably
migrate
at
that
point
to
whatever
name
like
I'm,
assuming
that
in
the
future,
if
we
make
changes,
we
might
rename
pat
to
the
pet
2021
thing
to
pat
minus
new
feature
right.
Some
sensible
name
that
likewise
sort
of
corresponds.
D
E
A
E
A
E
I
just
feel
like
this
is
the
kind
of
thing
that
we
would
forget
about
and
that
will
slowly
start
to
to
rot.
In
the
background
like,
if
you
make
a
list
of
all
the
different
fragment
specifiers
you
can
have
for
in
macro
rules,
then
this
one
is
not
going
to
be
on
the
list
and
the
one
that
you're
forgetting
about
and.
B
A
A
G
I
I
guess
I
want
to
try
to
understand.
Well,
okay,
the
argument
that
josh's
putting
forward
is
that
we
would
not.
We
cannot
add
things
to
the
2015
or
2018
editions
that
we
just
can't.
We
can't
put
in
other
variants.
A
A
A
I
know
I
know
and
then
and
the
question
is,
do
we
have
pat
2021
that
is
pat
with
pipe
in
all
editions
and
I
think
the
reasons
to
do
so
is
basically
it
is
nice
if
older
editions
can
access
newer
semantics,
albeit
with
a
more
confusing
way,
and
the
reasons
not
to
do
so
is
essentially
a
they
can
access
the
newer
semantics
by
doing.
A
Newer
editions
have
no
use
for
this,
because
it's
just
the
same
as
pet
and
c.
I
guess,
if
we
add
a
new
variant
of
pat,
we
can
give
it
a
meaningful
name
like
pat
for
him
at
that
time
and
d
croft.
C
Maybe
it's
worth
saying
that,
like
I
don't,
I
think
it
would
be
unfortunate
if
what
number
is
it
a
were
actually
a
thing
that
we
told
people
to
do,
because
it
seems
likely
to
me
that,
like
people
writing
that
by
hand
would
write
something
that
is
like
subtly
different
from
what
is
accepted
by
pat
in
2021
edition.
E
C
E
A
We
generally
do-
and
I
think
I
stand
by
that
principle-
want
people
to
upgrade
all
things
being
considered.
A
Yeah,
I
guess
there's
a
that
last
bullet
point.
It
would
be
a
shame
if
we
ended
up
with
a
big
list.
I
think
that's
like
that's
perhaps
part
of
the
the
the
core
question.
Is
that
a
shame
or
is
it
totally
irrelevant.
E
H
E
E
A
C
Like
I,
I
guess
I'm
I'm
personally
having
a
hard
time
imagining
that
many
people
being
like,
oh
the
2021
edition's
out,
I'm
really
excited
about
this
new
feature
that
it
offers
for
patterns.
Let
me
use
that
in
my
library
that
I
am
not
going
to
upgrade
to
rush
2021.
C
A
A
F
B
B
Another
look,
we
broke
something
and
it's
not
backwards
compatible,
but
we
did
it
on
purpose.
B
Ones,
but
I
think
we
already
decided
this
one,
so
it's
just
a
saying:
yes,
we
already
decided
that.
B
B
B
So
now
it
fails
to
compile,
and
I
think
this
is
a
yes,
we
know,
okay,
so
I
think
we
just
say
yeah.
This
is
intentional
and
close.
The
issue
and
okay.
F
Sorry
mark
go
ahead,
I
it
was
discussed
in
in
some
pr.
We
we've
we've
had,
I
think
over
the
last.
I
don't
know
five
releases.
Each
releases
contained
one
or
two
additional
attribute
checks.
A
A
Scott
action
item
to
leave
that
comment
great
all
right.
Well,
we
totally
did
not
at
all
succeed
in
getting
through
this
list,
but
that's
okay.
We
had
good
discussion.
Oh.