►
From YouTube: 2021-04-06 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
All
right
so,
first
up
on
the
agenda,
we
have
the
action
items
from
previous
weeks.
So,
as
always,
please
take
a
look
at
that
and
see
if
there's
anything
that
you
need
to
follow
up
on
or
anything
you
already
have
followed
up
on
and
just
need
to
check
off.
Take
a
look
at
that
after
the
meeting.
Let's
go
on
to
the
next
items,
there
are
two
pending
proposals.
86
was
pending
last
week
and
we
agreed
that
we
wanted
a
summary
of
that
one
before.
A
B
Right,
yes,
so
tomorrow
is
our
monthly
planning
meeting
for
the
design
meetings.
So
if
there
are
any
items
that
you
want
to
have
a
planning
meeting
over
this
month,
then
please
make
sure
there's
already
a
meeting
proposal
filed.
There
are
a
couple
already
available.
B
Alex
crichton
has
one
regarding
webassembly
calling
conventions,
for
example,
and
we
should
discuss
those
tomorrow
and
then,
after
that
we
should,
if
we
have
time
after
planning
the
month's
meetings,
we
should
go
through
statuses
for
any
open
projects
to
see
if
there
are
any
that
we
haven't
heard
from
in
a
while
or
any
that
need
an
update
in
terms
of
moving
forward.
A
So
I
will
say,
I've
been
putting
off
for
a
while
or
just
not
getting
around
to
is
maybe
more
accurate
updating
our
list
of
projects,
but
I
really
really
want
to
do
that
today.
So
when
I
do
that,
I
will
also
ping
people
to
try
to
get
them
to
post
updates
on
the
tracking
issues
and
so
on.
B
Sounds
good,
then,
the
so
going
on
to
the
pending
projects.
86
allow
the
compiler
to
eagerly
drop
values.
We
agreed
on
a
previous
week
that
we
didn't
want
to
go
forward
with
this,
but
that
we
would
still
like
a
summary,
as
a
lang
team
design,
note
to
explain
why
and
why
this
is
complicated,
because
there
was
a
fair
bit
of
analysis
on
zulip
that
we'd
love
to
have
captured,
but
I
don't
believe
this
needs
any
further
action
from
us
today.
A
Yeah,
maybe
someone
could
take
an
action
item,
maybe
me
to
try
to,
but
I
just
want
to
make
sure
we
have
an
action
and
for
writing
the
summary
and
track
it
that
way
we
may
already
have
it
not
necessarily
writing
a
summary
but
making
sure
the
summary
happens.
I
know
I
had
an
action
name
to
reach
out
about
it
mark
if
you
want
to
record
niko
to.
B
B
B
B
This
has
come
up
a
few
times,
but
it's
the
first
time
it's
turned
into
a
proposal,
and
the
proposal
is
to
change
how
paths
resolve
when
you're
inside
a
module
that
was
declared
itself
using
a
path
attribute
to
say,
get
it
from
this
file.
B
We
should
try
to
figure
out
if
we
want
to
make
a
change
in
this
area
and
if
this
sounds
vaguely
plausible,
it's
getting
down
to
the
wire
for
addition
changes.
So
we
may
also-
and
this
is
may
or
may
not
be
something
that
is
critically
important
to
get
in,
because
we've
lived
with
it
for
three
years,
so
we
should
decide
if
this
is
something
we
want
to
try
to
push
in
through
the
agenda
as
well
as
if
this
is
something
we
want
at
all
in
its
general
form.
I
argue
it's.
A
D
And
the
prioritization
section
in
the
mcp
itself
says
not
very
urgent,
so
it
would
be
hard
to
say
no.
We
really
ought
to
push
on
it.
A
B
That
we
might
also
potentially
be
able
to
reduce
the
impact
of
path
overall
rather
than
changing
path,
relative
items
so
there's
we
should
discuss
this
in
more
detail.
I
think,
rather
than
trying
to
rush
it
by
the
by
the
deadline,
given
that
we've
kind
of
already
passed
the
deadline
to
be
clear,
I
should
say:
I'm
not
suggesting
there's
a
bunch
of
open
questions
so
much
as
I
think,
there's
some
worthwhile
discussion
to
make
sure
this
is
what
we
want.
B
B
A
C
B
Well,
there's
a
quick
summary,
which
is
when
you're
using
the
path
attribute
on
a
module
to
specify
that,
rather
than
loading
it
from
the
expected
location,
you
want
to
load
it
from
a
specific
file
that
currently
affects
the
module
path
for
how
you
would
resolve
the
name
of
that
object
and
it's
affected
by
whether
the
containing
module
is
a
mod.rs
or
a
named
file.
B
B
B
So
I
think
that
tomorrow's
planning
meeting
we
we
may
want
to
decide
if
this
is
something
that
should
have
a
design
meeting,
but
I
think
in
this
meeting
it
might
be
worthwhile
to
get
a
consensus
on.
Does
anybody
want
to
push
for
this
happening
in
the
2021
edition?
Or
is
everybody
happy
with
the
idea
of
this
happening
happening
at
some
indefinite
future
time?.
E
I
think
I'm
I'm
totally
happy
to
not
have
it
in
2021.
I
do
think
that
we've
run
the
risk
of
getting
to
a
pattern
where
we,
if
we
don't
get
something
to
a
current
edition,
it
gets
delayed
to
the
next
edition,
and
then
we
don't
consider
it
until
relatively
late
in
the
cycle
for
the
edition
in
the
first
place.
So
it
might
be
better
to
try
to
even
for
things
like
this
when
we
say
we're
delaying
it
to
still
try
to
consider
them
very
early
in
the
edition
development
cycle.
A
B
B
So
that
aside,
though,
any
further
thoughts
on
this
item
before
we
move
on.
A
C
B
So
next
up
we
have
rfc
2845.
We've
talked
about
this
rfc
before
it's
about
super
trait
item
shadowing.
To
avoid
the
issue
of
being
unable
to
define
a
sub-trait
that
inherits
from
a
super
trait,
where
both
define
the
same
method
and
deal
with
it.
Unambiguously,
there
was
a
bunch
of
discussion
about
the
behavior.
We
want
the
last
activity
on
it
was
that
I'd
posted
a
comment
back
about
a
month
ago,
exactly
suggesting
that
we
could
treat
this
as
ambiguous
for
a
forward
compatible
solution
for
now
scott
you
nominated
this
five
days
ago.
D
D
D
How
about
I
just
say
that
we
can
put
a
note
for
felix
and
nico
to.
A
D
B
That
sounds
accurate.
I
would
follow
up
as
well
that
I
don't
actually
recall
in
the
comment
that
I
posted
a
month
ago,
treating
such
method
calls
as
ambiguous.
There's
a
bunch
of
context
here.
I
believe
that
was
referring
to
nico's
comment
regarding.
B
When
you
call
the
shadowed
method
from
inside
the
definition
of
the
subtrait,
and
so
the
proposal
is
that
from
outside,
you
still
get
the
subtrait
from
inside.
You
get
an
ambiguity
error
still
just
like
you
do
today,
and
so
I
think
that
needs
an
update
to
the
rfc
to
implement
the
proposal
that
nico
and
I
seem
to
be
in
favor
of
so
in
addition
to
filing
a
concern.
I
think
that
good
nico,
you
just
filed
a
concern
so
yeah.
B
B
The
previous
discussion
was
the
one
that
discussed
along
the
lines
of
we
don't
want
to
mandate,
ub
detection.
We
just
want
to
state
that
we're
doing
ub
detection
ralph
rewrote
the
rfc
based
on
an
earlier
draft.
That
did
exactly
that.
B
B
This
was,
I
believe,
it's
still
technically
in
fcp
with
a
blocking
issue.
I
think
we
should
cancel
that
and
restart
it
if
it's
been
rewritten.
Yes,
that
seems
like
a
good
plan.
I'll
just
do
that,
so
we
should
cancel
the
fcp
and
then
propose
fcp
as
soon
as
we
have
a
chance
to
read
it,
either
that
or
go
ahead
and
propose
fcp
on
the
assumption.
We
want
this
and
then
have
people
check
off
their
boxes
when
they
have
read
this.
B
D
D
However,
there's
also
this
new
rfc
about
reserving
token
space
without
defining
semantics
for
any
of
that
reserved
token
space.
These
are
both
edition
changes,
so
we
want
one
or
the
other
of
them,
we're
pretty
sure
for
this
next
edition.
D
The
question
that
I
wanted
to
bring
up
here
is:
do
we
want
to
say,
delay
the
raw
keywords,
one
to
give
more
discussion
time
for
it
in
favor
of
switching
over
to
fcp
the
reserve
prefixes
one,
or
are
we
happy
with
where
we
are
on
all
that?
D
I,
like
the
idea
of
the
prefix
reservation,
one
there's
been
a
bunch
of
comments
on
the
rock
keywords
about
hey
this
isn't
great.
Do
we
even
want
to
do
this?
Boats
has
a
interesting
comment
there,
for
example,.
A
B
Through
I
have
read
through
the
latest-
and
I
think
there's
reason
enough
to
pause
the
fcp
on
3098..
I
do
actually
still
think
we
should
go
forward
with
3098,
rather
than
delaying
it
for
a
long
time.
I
wouldn't
favor
the
don't
do
it
until
we
need
it
approach
that
there's
a
part
of
a
proposal
is
well.
We
don't
actually
have
to
do
this
if
we
reserve
the
context
until
we
need
the
keyword.
B
B
B
I
do
think
we
should
delay
this
a
little
bit
to,
among
other
things,
let
someone
do
an
implementation
pr
for
k
hash
and
do
a
a
crater
run
which
would
allow
us
to
determine
if
we
can
just
use
k
hash
in
every
edition,
and
if
we
can,
then
I
would
be
happy
to
see
the
rfc
just
say.
Let's
do
k
hash
in
every
edition.
B
To
give
due
time
for
consideration
for
the
comments
from
boats
and
eric
huss,
saying,
let's
not
do
this
at
all.
I
don't
know
that
we
necessarily
want
to
stop
this
one.
I
personally
still
think
it's
a
good
idea,
but
we
received
a
comment
during
the
final
comment
period
and
we
should
give
it
due
consideration
before
just
letting
the
final
comment
period.
End.
A
Yep
the
another
thought
I
have
is
so
if
we
do
go
forward
with
3101,
I
guess
another
thing
we
could
do
with
an
implementation
is
to
actually
write
some
code
using
this
style
right,
which
might
help
with
because
it
seems
like
the
major
concern
raised
is
just
so
ugly
we'd.
Never
no
one
would
ever
use
it.
B
B
So
I'm
not
sure
that
so
ugly
we'd
never
use
it
is
how
I
would
summarize
the
concern.
I
think
it's
more.
The
concern
from
boats
was
more.
Would
we
actually
end
up
using
this,
or
would
we
end
up
taking
long
enough
to
process
the
keyword
change
that
we
want
to
do
sorry,
the
non-keyword
part
of
any
change
that
the
keyword
can
just
take
the
next
edition
and
it
wouldn't
be
a
long
delay.
B
I
do
think
there's
value
in
saying
we
can
try
this
right
away
on
nightly
using
a
new
keyword
that
uses
k
hash,
but
I
think
it's
worth
considering
that
and
someone
else
also
raised
to
the
question
eric
I
think,
raised
the
question:
could
we
instead
have
a
mechanism
similar
to
feature
that
lets
you
opt
in
whether
you're
on
nightly
or
stable
to
using
the
new
keyword
and
then
just
say
I
want
the
keyword
and
use
the
keyword
without
the
k
hash
and
that
one,
my
actual
thought
is,
we
could
and
that's
a
worthy
alternative.
A
A
We
want
it
to
not
be
complicated
to
figure
out
what
kind
of
rust
you're
allowed
to
use
is
sort
of
the
short
version,
and
so,
if
you
have
code
bases
that
opt
in
to
like
feature
a
but
not
feature
b
and
feature
c
but
not
feature
d,
then
you
get
a
sort
of.
A
Of
dialects
of
rust,
whereas
with
the
addition
system,
you
have
really
only
like
one
thing
to
know.
What
addition
are
you
in
that
determines
everything
else.
That's
partially
true,
the
only
part
that's
not
true
is
sometimes
people
have
like
well,
I'm
stuck
on
rust,
1.22
or
whatever,
and
it
only
has
certain
features,
but
that's
a
different
orthogonal
question
and
with
this
k
hash
you
have
even
less
to
understand
because
you
know
no
matter
which
edition
you're
in
you
sort
of
have
access
to
at
least.
A
B
E
I
don't
know
I
keep
reading
the
problem.
My
problem
is
only
just
it's
so
stupid
when
I
first
read
the
summary
I
literally
thought
ident
was
a
key
meant
to
be
a
key
word
here.
Like
I
didn't
realize
it
was
meant
to
represent
the
group
of
all
identifiers,
and
it
took
me
a
while
of
reading
the
text
to
eventually
realize
that
mistake-
and
I
was
just
trying
to
think
of
some
way
to
like
make
it
clear
in
the
presentation,
but
I
don't
even
have
a
good
suggestion.
E
B
D
For
me,
it's
much
easier
to
write
the
rfc
than
that
pr.
I
don't
know
if
someone
who
knows
more
about
tokenize,
the
tokenizer
would
say
that
the
pr
is
easier.
A
Until
rfc
30101,
first
of
all,
but
secondly,
if
we
did
do
rfc,
3101
and
there's
implementation
of
it,
we
can
presumably
check
what
that
impacts
right.
That's
a
superset
of
k,
hash
and
my
hunch
is
like
one
crater
run-
would
tell
us
whatever
answers.
We
need
right.
B
Possibly,
but
if
the,
if
the
larger
crater
run
says
that
reserving
that
syntax
in
every
edition
would
be
a
breaking
change,
that
doesn't
necessarily
mean
that
k
hash
is
a
breaking
change.
It
may
be
that
somebody
else
is
using
a
magic
prefix
for
c
strings,
for
example,
and
that
would
break.
A
A
I
think
this
is
sort
of
orthogonal
we're
going
to
pause
until
we
have
finished
up
the
discussion
about
like
whether
this
is
a
good
idea,
but
we're
independently
going
forward
with
3101
right,
which
resolves.
D
D
A
C
D
B
B
B
I
think
one
additional
item
on
3101,
though,
is
that
there
are
a
couple
of
open
discussion
points
for
which
the
rfc
needs
updating
to
reserve
some
additional
pieces
of
token
space.
Concretely,
there
was
a
proposal
to
additionally
reserve.
Can
we
summarize.
B
Originally,
it
was
proposing
to
reserve
identifier
hash,
any
identifier
which
would
cover
the
k
hash
proposal,
as
well
as
any
future
proposal
where
we
needed
an
extension
for
how
to
interpret
an
identifier
and
also
reserving
a
double
quote
space.
So
identifier,
double
quote:
string
contents,
double
quote,
which
would
allow
us
to
create
new
things
similar
to
the
existing
raw
strings
or
byte
strings.
B
The
notion
there
is
that
would
reserve
enough
space
for
us
to
implement
things
like
c
strings
or,
u
utf-16
strings
or
similar,
it's
currently
being
extended
to
also
cover
single
quotes
after
identifiers.
In
case
we
wanted
to
use
that
space
for
something
unusual
related
to
characters
or
similar
and
the
identifier
hash
number
space
as
well.
If
we
wanted
things
like
alternate
base,
specifications
or
special
number.
B
Formats
and
that
I
believe
actually
that
rfc
has
been
updated
based
on
the
latest
requests.
Now
that
I
look
at
it.
B
And
the
other
thing
that
got
updated
was
there
was
some
debate
over
whether
the
reserved
space
should
error
out
at
tokenization
time
if
we
haven't
defined
a
meaning
for
it
or
whether
it
should
pass
on
through
and
be
usable
in
a
macro
to
summarize
the
discussion
from
zulip.
B
If
we
allowed
it
to
be
passed
through
to
macros,
then
you
could
implement
prototypes
of
new
syntax,
but
on
the
other
hand,
you
could
potentially
implement
macros
that
use
this
space
in
ways
that
will
conflict
with
our
reservation
and
one
person
proposed
on
zulip
that,
if
you're
gonna
prototype,
you
might
as
well
prototype
using
the
actual
keyword
and
not
the
k,
hash
keyword
which,
among
that,
among
other
arguments,
suggests
we
should
just
error
out
at
tokenization
time
so
that
there
can
never
be
a
conflict
with
the
reserved
syntax
that
we're
proposing,
which
means
we
never
have
to
worry
about
breaking
even
a
macro.
B
There's
also
that
if
we
make
this
a
tokenization
error,
rather
than
a
passing
it
through
to
a
macro,
then
we
reserve
the
ability
to
have
this
tokenized
differently
than
just.
Here
is
one
token
we
previously
said:
oh
we're
changing
this
to
tokenize
from
three
tokens
to
one
token,
but
if
we
reserve
this
in
tokenization,
then
we
could
choose
for
this
to
expand
to
something
else
as
seen
by
macros
or
for
that
matter,
use
one
of
these
prefixes
in
macro
space,
if
we
needed
to
so.
B
B
B
B
Yeah,
okay,
if
in
that
case,
I
would
propose
we
go
ahead
with
fcp.
I
will
take
the
action
item
to
write
the
fcp
for
this
one
and
if
anybody
wants
to
obviously
please
take
a
close
look
before
checking
your
box
and
if
you
have
any
concerns,
please
raise
them
as
concerns.
D
The
one
impact
that
is
potentially
interesting
is
if
people
are
using
this
in
funky
ways
and
macros
already
like
f
strings
example
that
someone
mentioned,
but
I
think,
that's
sort
of
well
yeah
by
design
in
a
way.
B
Right,
I
think
that
the
plan
here
is,
we
would
do
a
pr.
We
would
run
that
pr
through
crater
and
based
on
the
outcome
of
that
crater
run.
We
would
choose
what
editions
to
do
this
and
we
could
do
this
only
in
the
2021
edition
or
if
it
turns
out.
Nobody
has
ever
used
this
in
a
macro
or
to
any
significant
degree.
B
A
I
have
one
question:
does
how
much
detail
does
the
rfc
go
into
with
respect
to
macros
across
crates.
A
Like
say
more,
if
we
change
the
tokenizer
and
you
invoke
a
macro
from
another
crate,
I
think
the
answer
is
you
in
a
21
in
in
a
2021
crate,
you
simply
cannot.
B
D
2018
would
see
them
as
I
think
it
would.
A
B
B
So
we
have
eight
two
six
three
three.
This
is
a
p
high
issue
on
wrestling
rust.
We
previously
discussed
this
one
and
our
consensus,
which
we
confirmed
via
an
rfc
bot
poll
on
the
issue,
was
that
we
do
want
to
prohibit
types
function,
types
that
return
an
out.
That
is
not
sized,
at
least
until
we
have
any
kind
of
unsized
type
support
in
the
future.
B
Estebank
put
in
a
pr
to
do
exactly
that.
There
is
some
discussion
about
whether
that
pr
is
sufficient,
but
it's
definitely
an
improvement.
There
is
some
discussion
about
whether
it's
still
possible
to
exploit
the
things
that
the
pr
doesn't
cover,
which
specifically
includes
infiltrate,
so
you
can
still
have
a
function
type
that
returns
an
impul
trait.
That
is
not
sized,
but
that
said,
the
pr
is
likely
an
improvement,
and
I
think
it's
up
to
compiler
folks
to
review
the
pr
ra
rather
than
language.
Folks,.
C
B
B
B
B
This
was
proposed
in
february
and
was
nominated
for
consideration
in
response
to
ralph
saying
that
lang
needs
to
make
the
call
here.
B
There's
a
question
of
whether
you
sizes
that
were
obtained
from
pointers
have
the
concept
of
provenance,
and
if
you
have
been
following
the
discussion,
then
you
would
see
there's
a
whole
bunch
of
advantages
and
disadvantages
in
both
directions.
If
you
haven't
been
following
the
discussion
and
the
general
concept
of
provenance
isn't
something
you've
seen,
then
you
may
want
to
dig
into
the
proposal
and
discussion
here.
B
In
zulu,
not
that
I'm
aware
of
and
in
particular
this
reference
pr
does
not
appear
to
summarize
any
of
the
advantages
and
disadvantages,
because
it's
just
documenting
the
language
change
itself
and
the
proposal
in
this
pr
is
that
casting
to
you
size
loses.
B
Provenance,
so
if
if
people
want
to
have
more
depth
on
that,
I
don't
think
there's
anything
other
than
zulu
available
towards
the
end
of
the
zulu
conversation
there
are.
Some
general
like
here
are
the
trade-offs
posts,
but
those
have
not
been
copied
anywhere
else.
B
B
A
I
mean
it's:
it's
certainly
something
that
raw
that
stack
borrows
like
models
when
it's
you
being
when
it's
not,
but
I
mean
okay
I'll
have
to
dig
in
too
like
like
for
a
stack
borrows
when
you
go
from
a
reference
to
a
pointer,
you
can
then
take
it
to
use
size
and
back
and
whatever
else,
and
I
think
it
doesn't
have
any
effect
on.
What's
legal
and
what's
not
legal,
and
that
was
a
design
goal
that
I'm.
A
B
B
How
we
want
the
language
to
be
defined
and
that's
a
decision
we
shouldn't
make
in
five
minutes
notice
when
a
bunch
of
people
haven't
seen
the
discussion,
so
I
think
we
need
to
take
this
one
asynchronous
and
get
a
good
summary
of
what
the
trade-offs
are
and
what
ones
we're
making.
By
accepting
this
pr.
A
C
It
also
potentially
feels
like
there
is
a
design
meeting
or
something
to
have
like
I'm
not
sure
at
least
a
a
sort
of
maybe
naive
question
might
be.
You
know,
is
this
the
right
place
to
start?
If
we
want
to
document
that
you
know
where
providence
is
kept
and
not
in
terms
of
prioritization
on
on,
like
general,
you
know
it's
probably
a
hard
question,
maybe
there's
more
importance.
A
B
Sure
I
don't
think
that
we
should.
I
agree
that
we
shouldn't
treat
this
pr
as
the
motivating
item.
It's
more
ralph
and
many
others
have
been
in
this
discussion,
trying
to
figure
out
what
the
next
step
is
for
what
we
want
to
do
about
pointer
provenance,
and
I
think
the
next
step
is
that
we
need
to
make
a
decision
about
pointer
provenance,
not
that
we
need
to
decide
whether
or
not
to
accept
this
pr.
Yeah.
C
C
C
B
Is
we
should
do
this
as
part
of
a
larger
effort,
and
we
should
check
that
if
this
is
something
we
should
do
incrementally,
then
we
can
figure
out
what
the
next
step
is
on
it.
But
yes,
I
agree
that
whether
and
what
are
both
open
questions
and
we
should
discuss
both
of
those
with
among
other
people,
ralph.
C
Can
we,
I
guess
maybe
we
can
just
discuss
tomorrow
in
terms
of
design
meeting.
A
B
Yeah,
I
think
the
action
item
would
be
to
say
that
we
want
to
wait
until
we've
actually
made
a
decision
on
this
and
that
we
need
to
defer
that
decision
to
a
design
meeting
with
which
we'd
like.
A
A
B
Okay,
next
up,
we've
got
about
10
minutes
left
and
we've
got
six
or
seven
items
to
go
through,
so
we're
probably
not
going
to
get
to
all
of
them.
So
before
we
jump
into
these,
is
there
any
particular
item
that
people
want
to
call
attention
to
that?
They
would
especially
like
to
look
at.
B
A
The
revolve
merch
doesn't
seem
super
important.
I
I
would
like
to
prayer
ask
if
there's
been
any
progress
on
con.
I,
like
addition,
related
things,
I'm
not
sure.
If
any
of
these
like
has
there
been
any
progress
on
con
generics,
I'd
probably
say:
const
generics
is
most
and
then
pat
patterns.
Second,
but
okay,.
B
B
So
I've
passed
on
the
communication
to
the
library
team
that,
from
a
language
perspective,
we
would
like
to
see
feedback
from
actual
users
and
that
we're
not
sure
that
we
see
the
value
in
dropping
this
mechanism
if
we
have
to
keep
it
eternally
for
previous
editions
anyway.
B
Beyond
that
I've
passed
on
that
we
didn't
really
have
any
other
specific
feedback
about
other
than
wanting
to
get
that
information.
B
B
B
I
would
propose
that
we
do
yes,
it
still
needs
ongoing
consideration,
but
it
certainly
doesn't
need
to
be
nominated
for
either
lang
or
lib.
We
need
the
feedback.
C
I
I
guess
one
question
I
might
have
do
we
feel
that
there
is
a
like.
Would
it
be
a
problem?
If,
essentially,
we
don't
get
this
feedback
and
we
end
up
not
doing
anything
like
we
don't
actually
change
the
behavior.
We
don't
require
it
in
2021
because
I
think
like
if
we
don't
actively
assign
someone
to.
I
don't
know
post
on
internals
drive
that
feedback.
I
don't
think
it's
gonna
happen
in
time
for
2021.
B
It's
a
reasonable
point:
would
anybody
online
be
sad
if
we
don't
make
this
change
and
we
just
always
have
a
special
case
as
a
rusty
attribute
that
allows
you
to
pass
a
cons
must
be
const
argument,
positionally
well,.
A
C
B
I
think
agreed,
and
I
think
that
this
isn't
going
to
get
any
worse
either
way.
The
compiler
has
to
keep
the
support
forever
for
compatibility
right.
B
C
It
was
a
known
misstep
in
the
stabilization.
It
was
missed
as
a
special
thing,
while
stabilizing
these
intrinsics,
because
lay
only
weighed
in
on
the
overall
idea
of
having
cmd
intrinsics
from
what
I
know,
but
the
specific.
B
So,
yes,
I
do
think
that
makes
sense.
I'm
glad
that
that
was
noted.
I
is
there
some
procedural
step
that
we
may
want
to
convey
in
terms
of
this
is
an
item
where
we
do
think,
because
normally
a
magic,
rusty,
internal
attribute
that
can't
be
used
outside
of
the
library,
it
has
not
typically
been
something
we
give
super
close
scrutiny
to.
B
That
we,
that
affect
how
you
call
the
function
and
not
just
the
internals
of
the
function,
then
we
need
to
review
that.
E
I
I
have
a
suggestion
here.
It's
pop,
I
mean
one
way
to
handle
this.
Would
you
say
that
we
just
don't
allow
russia
attributes
in
this?
Instead,
it
should
have
been
written
as
a
non-russia
attribute
that
needs
a
flag
to
get
in.
Like
may,
dangle
was
like
that
right.
The
lang
team
did
review
may
dangle.
E
That
was
part
of
the
drop
check,
work,
it's
in
vector
and
other
collection
types
and
it's
still
a
sort
of
work,
but
it's
there
it's
only
usable
by
the
standard
library
effectively
unless
people
opt
into
nightly,
and
I
think
that
that
forced
us,
my
point
only
is
that
part
of
the
issue
here
is
that
the
use
of
rusty
actually
meant
that
it's
easy
to
miss
yeah,
so
rusty
attributes.
A
C
Yeah,
I'm
happy
to
take
an
action
item
to
leave
a
summary
comment
and
nominate
for
lane
anyway.
A
B
B
See
if
we
can
get
one
more
item
done
in
the
next
two
minutes,
I
don't
actually
think
we're
going
to
be
able
to
get
through
stabilize
the
pattern
items
in
this
meeting,
because
the
thing
that's.
C
B
B
Called
but
it
does
sound,
like
the
trend
of
the
conversation,
is
leaning
towards
drop
the
name
2015
entirely
and
just
have
a
descriptive
name
that
people
can
use,
because
people
will
want
to
use
this
in
the
future.
B
Okay,
we
are
officially
out
of
time,
so
let's
go
ahead
and
wrap
for
the
day
and
any
items
that
weren't
covered
we
can
handle
asynchronously
or
next
week
thanks
everybody.