►
From YouTube: 2020-11-10 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
People
can,
I
think,
maybe
everyone
already
did,
but
if
you
want
otherwise
tossing
your
names
up
there
and
let's
see
oh,
I
did
these
things
all
right.
Well,
not
that,
but
that's
okay.
So
we
have
two
pending
proposals:
the
first
one
both
of
which
I
think
there's
someone
who's
interested.
A
The
first
one
is
aaron
proposed.
No
op
method
calls.
The
idea
is
to
basically
move.
This
is
already
a
clippy
lint,
as
I
understand
it,
but
maybe
generalize
the
mechanism,
but
give
warnings
about
these
kind
of
annoying
methods
like
the
reference.
If
this
gives
you
back
a
reference-
and
this
is
often
a
kind
of-
or
it's
sometimes
a
source
of
confusion
for
people
because
they
mean
to
clone
the
tea,
not
the
amphibian
and.
B
A
C
A
C
A
D
A
E
I
have
two
quick
comments.
One
is
this
lint
specifically
limited
to
cases
where
the
function
call
returns
exactly
the
same
type
that
that
went
into
the
function.
B
A
A
Yeah
it
didn't,
I
don't
know
you
could
ask
a
question,
I'm
not
sure
about
that.
That
would
be
something.
E
And
then,
and
then
my
final
point
that
I
wanted
to
make
was
that
I'm
not
totally
sure
I
buy
into
the
argument
about
waiting
and
starting
keeping
this
at
allow
to
begin
with,
and
I'm
curious
both.
What
you
see
is
specific
about
this
warning,
in
particular
versus
other
warnings
that
we
introduced
without
an
addition
boundary
that
makes
it
merit
that
kind
of,
like
more
like
big
flag
day
approach.
C
I
mean
it's
possible
that
I
think
what
I
would
want
is
a
crater
run
and
if
there
are
a
lot
of
crates
that
are
gonna
like
a
lot
of
it
seems
common
that
people
would
introduce
something
you
see
this
morning,
because
the
code
works
right.
That's
sort
of
the
issues,
the
code
that
they're
compiling
is
doesn't
actually
have
a
bug
is
mainly
just
helping
them.
C
C
Well,
yeah,
so
I
just
I
was
just
thinking.
Maybe
there
are
a
lot
of
people
who
will
who
have
this
without
realizing
it
and
then
we'll
trigger
the
lint,
and
then
we
don't
want
that
to
be
like
an
experience
where
you
update
your
rust
compiler
and
you
have
20
warnings
that
you
have
to
go
and
fix
in
your
code
base.
C
E
B
A
B
C
A
Two
policies
that
we
have
kind
of
been
kicking
down
the
road
I
think
a
little
bit
of
a
lint
policy
and
a
and
a
regression
treatment
like
do
we
want
to
revisit
our
notion
of
our
standards
for
what
kind
of
things
we
will
change?
Probably
should
talk
about
them,
though
they're
not
the
same.
A
Okay,
I
didn't
hear
anything
that
said,
like
don't
do
it.
It
sounded
to
me
so
the
other
point
this
was
raised
by
scott
was
pointing
out
that
we
have
in
the
macro
rules.
You
can
use
keywords
as
identifiers,
special
keyword
and
proposed.
I
think
an
addition
change
scott
is
that
right.
B
I
think
it
would
have
to
be
because
it's
very
clearly
breaking
otherwise
josh
probably
wants
to
talk
to
this
as
well,
because
he's
the
one
who
asked
me
to
write
this
mcp.
D
Yeah
part
of
yeah
part
of
the
reason
this
came
up
in
particular,
was
the
the
item
we
discussed
a
couple
of
weeks
ago
now.
I
believe
that
proposed
dollar
self
and
possibly
dollar
super
as
analogous
to
dollar
crate,
so
that
you
could
access
items
from
the
same
crate,
but
instead
of
starting
from
the
top
level,
you
start
from
the
module
that
contain
the
macro,
and
then
that
led
to
the
point,
if
you
can
actually
use
dollar
self
as
just
a
generic
macro
argument,
name
today,
there's
no
prevention
of
using
a
keyword.
D
D
In
terms
of
I
don't
know,
I
mean,
even
if
we
want
to
add,
like
interesting
repetition
mechanisms
using
dollar
for
macro
conditionals
with
dollar,
if
but
whatever
we
might
want
to
do,
having
keywords
seems
confusing
and
limits
our
future
options,
and
we
have
a
concrete
proposal
on
the
table
to
use
dollar
self
in
dollar.
C
C
Okay,
good
because
I
guess
it
was
capital
self.
That
is
not
a
keyword.
I
think
that
sounds
right
right
and
outside
of
a
nipple
block.
Capital
itself
is
not
reserved
anyway,
so
yeah
that
sounds
to
me.
This
sounds
like
yeah.
We
should
do
it
in
addition,
but
it's
a
bug
fix
basically
like
we
should
reserve
these
directly
make
words
with
dollar
signs.
B
D
I
know
just
lag
was
causing
it
crosstalk.
The
the
one
other
thing
that
we
need
to
be
concerned
about
is
how
widely
used
this
currently
is.
Obviously,
we
have
the
ability
to
make
this
change
in
an
addition,
but
we
don't
like
to
do
changes
that
are
incredibly
high
impact.
D
We
can
obviously
provide
a
rust
fix
for
this.
That
just
does
alpha
renaming,
but
nonetheless,
I
would
generally
propose
that
we
do
a
crater
run
or
or
some
equivalent
search
of
all
the
crater
accessible
code
base.
That
detects,
which
keywords
are
widely
used,
and
we
could
go
ahead
and
directly
do
in
the
addition,
a
prevention
of
using
all
the
keywords
that
would
be
low
impact,
the
ones
that,
if
there
are
any
that
would
be,
you
know,
thousands
and
thousands
of
regressions.
D
We
may
want
to
consider
a
phase
in
using
a
edition
forward
compatibility,
lint.
C
B
C
Just
need
a
convention,
I
think,
would
be
interesting
with
that
case
would
be
maybe,
instead
of
like
in
general,
we
should
just
switch
to
our
hash
like
if
someone
has,
if
our
hash,
if
maybe
herself,
would
like
bring
a
new
convention
like
we
suggest
using
this
for
that
case
and
then
restricts
them
to
canvas.
If
it's
ourselves,
then.
E
Maybe
that's
too
big
a
deviation
from
the
existing
plan,
but
it
does
seem
like
there's
an
actual
ambiguity
here,
being
suggested
by
the
syntactic
ambiguity,
which
is
that
when
you
see
dollar
signs
something
in
a
macro,
it's
not
clear
whether
it's
the
start
of
a
sort
of
semi-hygienic
path
or
whether
it's
starting
to
refer
to
a
variable
name.
And
maybe
that's
some,
an
indication
that
we
should
actually
be
coming
up
with
a
different
syntax
to
refer
to
the
two.
Rather
than
just
like
plugging.
In
more
keywords.
D
That
is
fair
if
we
wanted
a
different
syntax
for
like
meta
syntax
within
macros,
rather
than
variables.
D
Among
many
other
things,
almost
anything
starting
with
a
dollar
is
not
allowed,
so
dollar
dollar
or
any
number
of
other
things,
would
allow
us
to
have
a
standardized
syntax.
A
D
It
may
make
sense,
rather
than
having
this
proposal
narrowly
be.
We
should
reserve
keywords.
We
may
instead
want
to
charter
it
to
be.
We
should
introduce
a
forward-compatible
way
for
us
to
allow
additional
syntax
and
macros
that
we
can
make
use
of
without
any
conflict
with
users,
whether
that's,
let's
reserve
keywords
or
whether
that's,
let's
you
know,
define
a
name
space
like
dollar
dollar.
A
A
D
Well,
hypothetically,
if
we
did
introduce
a
different,
introducer
syntax
as
long
as
that
was
something
that
isn't
a
conflict
with
anything
that
works
today
like
dollar
dollar
is
not
the
start
of
any
valid
production
today,
then
it
doesn't
have
to
be
an
edition
boundary.
So
it's
not
a
big
rush.
The
only
big
rush
would
be
if
we
want
to
do
a
breaking
change
with
a
proper
transition
for
the
edition,
like
keywords.
D
A
Okay,
if
someone
wants
to
open
a
pr
or
like
try
to
find
someone
to
open
pr,
that
would
be
fine,
but
let's
move
from
this
onward,
I
guess
we.
This
is
our
kind
of
rough.
A
A
People
are
supposed
to
read
the
paper
and
there
was
a
proposal
filed
to
discuss
fair
trade
objects
in
the
2021
edition
two
weeks
ago.
I
guess
I
don't
know
if
we
want
to
use
a
meeting
to
talk
about
it.
A
A
D
Possibly
possibly
not,
the
major
thing
is
kind
of
a
question
of
taste
of
like
we
have
warned
about
this
for
a
while,
but
is
this
something
we're
prepared
to
completely
prevent
in
a
new
edition?
It
certainly
rubbed
some
people
the
wrong
way
in
2018,
but
at
the
same
time
it
is
not.
It
would
be
useful
for
syntax.
D
B
A
I
think
one
of
the
things
that
we
need
to
do
for
the
edition
is
to
kind
of
actually
soon
probably
is
to
re
look
over
the
idiom
links
and
kind
of
schedule
them
for
changing,
like,
in
other
words,
we
never
really
burned
on
the
2018
edition
indian
wins
by
2018
and
stuff
like
that,
and
there
was
a
plan
to
start
doing
that
as
part
of
the
2021
edition
rfc,
and
so
we
probably
should
review
them
in
general,
and
this
might
be
a
good
candidate
of
one
so
like
we
could
maybe
talk
about
it
as
part
of
that.
A
I'm
gonna,
I'm
gonna
write
a
meeting
proposal
around
that
important
thing
for
us
to
get
on
top
of,
and
that's
been
on
my
mind
so
review
those
or
at
least
I'll
write
up
a
document
whether
we
need
to
meet
about
it.
I
don't
know
all
right,
I'm
going
to
skip,
because
we
have
a
lot
of
nominated
things,
I'm
going
to
skip
over
the
project
board
unless
there's
any
updates
from
existing
projects.
People
want
to
surface
we're
in
the
meeting.
A
F
Am
yeah,
I
don't
know
that
we
necessarily
need
to
discuss
in
the
meeting
if
people
there
was
no
significant
change
from
what
we
had
discussed
last
time.
We
talked
about
this.
A
Okay,
I
mostly
wanted
to
let
people
know
so
you
know
we
have
this
problem.
We've
been
regression,
we've
been
working
towards
there's
a
ppr.
I
have
to
admit
I
reading
the
pr
description.
I
had
a
hard
time
understanding
exactly
what
it
did,
but
I'll
have
to
reread
it.
I
was
reading
fast,
but
we
should
probably
review
it.
F
I
guess
one
thing
to
maybe
call
out
is
that
it
does
change
the
behavior
like.
It
basically
says
that,
like
the
current
behavior
for
forbid
in
different
scopes
is
unified
with
the
new
behavior
for
forbidden
the
same
scope,
which
I
think
we
have
sort
of
brought
agreements
on.
But
it
does
mean
that
we
remove
a
hard
error
of
the
different
scope
for
bid.
If
you
have
caplintz
turned
on,
which
is
potentially
sort
of
people
might
care
about
that.
But.
F
F
A
A
A
So
we
don't
need
to
make
it
consensus
of
the
meaning
of
this
model,
so
tracking
issue,
this
one
or
patterns
people
were
asking
about
stabilizing
or
patterns,
and
I
haven't
looked
at
the
state
of
the
implementation,
but
there
are
two
unresolved
questions
that
seem
relevant.
One
of
them
was
whether
to
support
this
notation
in
closure
arguments
as
an
example,
I
think,
and
the
other
was
the
effect
on
the
pattern
meta
variable.
A
This
is
an
example
of
using
the
notation
enclosure
arguments.
I
think
this
consents
well
my
opinion.
It
looks
pretty
hard
to
be.
D
Right,
if
you
can
do
it
with
parentheses,
does
that
also
mean
you
can
do
it
at
a
lower
level
of
the
pattern
like
if
you
know
you're
matching
inside
of
a
a
new
type,
can
you
match
a
an
or
pattern
inside
the
parens
of
the
new
type,
or
do
you
need
an
additional
set
of
parens.
D
D
A
D
A
D
Interestingly,
if
you
wrote
a
closure,
sorry,
if
you
wrote
a
pattern
in
a
macro
that
was
trying
to
implement
or
patterns
in
the
most
obvious
way,
and
we
and
you
parse
things
that
are
one
or
more
patterns
separated
by
bars,
and
we
just
change
this
so
that
pattern
grabs
the
whole
thing.
Then
your
macro
will
just
trivially
work.
So
the
only
case
we
would
have
to
worry
about
is,
if
you
write
it
in
a
non-obvious
way
or
if
you're,
using
bar
to
mean
something
other
than
or
patterns.
B
A
D
D
D
Right,
I
think
that
we
probably
should
introduce
this
or
rhett
sorry,
we
should
do
a
quick
crater
run
if
we
can,
and
if
this
is
low
impact.
I
think
we
should
go
ahead
and
do
it.
The
tricky
bit
will
be
what
happens
if
it's
high
impact,
but
we
can
decide
that
if
it
happens.
A
A
A
G
A
A
A
part
try
to
it
seems
like
the
answer
is.
We
won't
be
able
to
really
assess
the
impact
at
the
moment.
As
far
as
we
know,
there
is
no
impact
because
even
normal
stack
borrows
kind
of
or
even
normal
two-phase
borrowers
makes
for
stack,
borrows
to
be
very
conservative
so
or
even
the
more
limited
form.
So
there's
really
no
reason
to
keep
denying
this
with
the
current
formulation.
D
A
A
There
were
some
further
comments.
I
still
feel
a
certain
measure
of
skepticism.
I
don't
know
if
anyone
has
any
new
thoughts
or
if
we
should
just
leave
it
for
more
discussion
on
the
thread.
F
I
think
I
would
say
that
the
discussion
has
boiled
down
to
there's
some
set
of
folks,
including
me
that
feel
that
the
right
thing
is
not
default,
but
potentially
a
new
trait,
which
sort
of
encompasses
this
set
of
types
which
have
function
impulse
and
don't
need
a
like.
The
type
itself
is
sufficient
to
call
it
essentially.
B
Part
of
me
also
thinks
that
the
the
user's
main
thrust
in
there
is
also
served
successfully
by
making
these
things
muckable
when
we
have
safe
transmute.
D
B
C
I
also
think
it's
confusing,
but
I
would
rather
implement
default
than
introduce
a
new
trait
that
users
have
to
learn
in
order
to
access
the
behavior
like
if
we're
gonna
have
the
behavior,
I
think
we
should
just
have
it
in
every
way
that
we
can
have
it
and
we
should
not
make
users
jump
through
a
hoop
to
get
access
to
it,
because
it's
a
weird
thing
to
do
so,
I
think
like.
C
Like
users
shouldn't
be
like
in
a
situation
where
they're
trying
to
do
this,
and
then
they
find
out,
it
doesn't
work
and
then
they're
frustrated
and
confused,
and
then
they
have
to
google
around
forever
to
find
the
right
way
to
do
it,
because
we
decided
that
what
they
wanted
to
do
was
confusing
right
like
either
they
do
it.
They
can
or
they
can't.
B
D
D
Is
that
something
that
we
want
to
commit
to
going
forward
that
these
closures
will
always
have
a
zero-sized,
unique
type
as
opposed
to
oh
hey,
it
looks
like
it
has
the
right
type
for
a
function.
Maybe
we
just
give
it
a
function
type
to
begin
with,
we
wouldn't
be
allowed
to
make
that
change.
If
we
do
this,
if
we
don't
do
this,
we
potentially
could
make
such
a
change.
C
C
C
D
That
I
definitely
agree
with
we
shouldn't
introduce
some
other
trait
that
does
this
instead
of
default
and
not
introduce
default,
I
think
I
would
argue
we
shouldn't
do
either,
but
I
agree
with
the
statement
that
we
shouldn't
do
the
latter
and
not
the
former.
C
C
Good
because
it's
proposed
on
a
thread
is
that
there
should
be
like
a
a
trait
for
functions
that
have
no
state
which
then
you
could
get
a
significant
value
of
them
right
but
like
that
seems
like
the
worst
of
all
worlds,
because
we
have
to
behave
here.
But
it's
really
difficult
to
figure
out
how
to
get
it.
D
D
B
C
A
F
Yeah
I
I
will
say
that
I
don't
personally
feel
that
default
is
like.
I
feel
default
is
less
intuitive
than
having
a
fourth
trait
that
is
like.
If
you're
you
know,
taking
a
function
generically
well,
there's
four
ways
to
do
it:
you
can
take
a
function
that
is
sort
of
has
no
state,
and
you
can
do
anything
you
want
with
it.
You
can
take
it.
You
know
by
sort
of
shed
reference
mutable
reference,
or
you
can
take
ownership
like
that.
F
That
feels
like
a
relatively
explainable
story
versus
no
there's
three
traits,
but
if
you,
you
know
need
to
synthesize
one
magically,
something
that
you
probably
have
never
actually
like
people
writing
a
t
default
bound
is
seems
really
rare,
like
I've,
never
done
it
outside
of
like
standard
library
methods
that
is
sort
of
weird.
B
C
I
so
yeah,
I
think
that's
actually
I
don't
disagree,
but
I
definitely
think
that
if
we
do
add
it,
then
we
should
also
add
the
implementation
of
default
like
so.
If
someone
has
an
infant
static
and
they
just
called
default
on
it
right
or
they
kind
of
passed
it
about
it
expects
default,
it
should
work
properly.
They
shouldn't
have
to
like
create
a
new
type
to
run
that
yeah.
B
I
think
josh
said
something
interesting
earlier
as
well,
that,
like
I
kind
of
like
this,
as
we
should
expose
a
valid
way
to
do
this,
but
not
necessarily
a
safe
way.
This
isn't
exactly
what
josh
said,
but
I'm
jumping
a
bit,
because
this
is
what
it
made
me
think
that
the
case
in
the
thread
has
an
instance
at
one
point,
so
the
safety
and
variant
of
you
can't
just
randomly
duplicate
instances
without
knowing
stuff
about
them
would
apply
if
we
gave
people
a
unsafe
but
valid
way
to
do
this.
Somehow.
D
One
other
question
here:
is
it
possible
that
muckable
would
or
not
muckable
safe
transmute
would
solve
this
problem
in
a
different
way,
not
that
you
would
use
safe
transmute
as
the
way
of
implementing
this,
but
rather,
if
you
know
that
the
way
that
you
can
write
in
the
type
system
disclosure
has
no
state
is,
I
can
turn
this
into
a
regular
fn
safely.
B
A
Okay,
I
want
to
call
attention
to
this
pr,
so
I
think
we
can
probably
or
plus
this,
but
this
is
a
pr
by
ralph,
basically
adding
an
annotation
to
clarify
that
the
way
lvm
works
today,
at
least
a
box
unit,
pointing
to
previously
allocated
memory
that
has
since
been
freed
is
undefined.
Behavior
drag,
but
there
it
is.
F
True
that
the
previously
previously
allocated
memory
here
is
like
provenance-wise
like
it's
not
like
it's
not
based
on
the
literal
number,
so
you
don't
run
into
trouble
if
you
like,
synthesize
non-null,
aligned,
pointers
or
whatever
right,
because
those
are
like
you
never
actually
allocate
them.
F
Because
it
seems
like
we
would
have
sort
of
potential
problems
if
we
box
ourselves
in
there.
In
some
sense,
even
if
you
know.
F
D
If
there's
no
way
for
us
to
work
around
it
so
that
it,
if
there's
no
way
for
us
to
work
around
it,
then
yes,
if
we
could
work
around
it
by
not
doing
inbounds,
then
that's
another
question.
B
Could
we
like
remove
inbounds
only
for
zst
offsets
or
something?
Well?
No,
we
don't
even
emit
zst
offsets.
So
I
don't
know
what
any
of
this
means.
A
Probably
this
will
get
yeah,
I
don't
know,
let
me
look
a
little
more
into
finding
out
what
it
means.
If
it
gets
controversial,
I
can
come
back.
I
don't
want
to
talk
about
this
too
much,
except
to
highlight
that
after
zhang
wrote,
apr
to
implement
pub
macro
rules,
which
I
guess
is
very
easy.
A
D
I
do
think
it
needs
at
least
a
minimal
spec
for
the
specific
reason
of.
If
we're
going
to
do
this,
it
should
probably
be
with
a
transition
where
things
aren't
pub
unless
they're
pub
like
this
should
be
a
transition
where
we
say
well,
this
should
be
an
alternative
to
exporting
a
macro.
You
should
also
potentially
be
able
to
pub
crate
a
macro,
so
we
should
have
a
coherent
spec.
That
says:
what's
the
preferred
alternative.
A
D
Agreed
we
should
also
make
sure
that
there's
nothing
that
we
want
to
key
off
of
it.
If
there's
some
minor
transition
in
terms
of
macro
visibility
or
macro
placement
within
crates
or
similar,
that
we've
been
meaning
to
do,
we
could
potentially
key
it
off
of.
Did
you
declare
your
macro
using
pub
macro
rules
or
macro
export
macro
rules,
and
so
we
should
do
a
quick
thought
of.
Is
there
anything
we
want
to
key
off
of
that.
A
Okay,
so
next
thing
this
is,
I
think,
pretty
minor,
but
it's
a
rename
of
the
overlapping
patterns
linked
to
overlapping
ranges.
If
I'm
not
mistaken,
they're
overlapping
range
endpoints.
A
A
A
So
we've
been
on
a
we've,
been
on
a
like
general
run
of
letting
ralph
simplify
promotion.
I
don't
assume
we're
going
to
continue
doing
that.
G
A
A
I
don't
know
whether
you
consider
that
surprising.
I
actually
don't
like
the
expected
behavior
to
me,
but.
D
D
A
B
D
Yeah,
I
would
be
entirely
in
favor
of
linting
on
a
doc
test,
written
in
a
place
where
the
doc
test
will
not
be
run.
Whether
or
not
it
is
macro
generated.
B
D
F
Dot
comments
like
it
does
seem
to
run
the
function
doctest
on
nested
functions.
So
in
that
sense,
that's
not
really
a
concern
here.
F
F
F
There
is,
I
feel,
like
there
is
sufficient
value
in
doc
comments,
even
if
I
never
look
like
for
the
compiler.
I
never
look
at
restock
because
it's
just
not
like
easy
to
do,
or
maybe
just
my
mind
doesn't
go
there,
but
doc
comments
are
still
really
useful.
A
G
So
I
one
more
thing
I
want
to
ask
here
so
this
this
lint,
I
I'm
assuming
that
if
we
were,
if
we
were
to
approve
it,
would
be
something
that
applies
to
rusty
as
well
as
rust,
stock
right
or
as
it
only
applies
to
rust
stock
when
it
runs.
G
Okay,
so
so
the
reason
why
I
asked
that
is
because
I
would
perhaps
be
inclined
to
having
some
sort
of
feedback
from
rustoc
itself,
not
necessarily
a
lint,
but
some
ways.
It's
saying
by
the
way-
hey
I
encountered
like
this
this
and
this
that,
like
I
didn't,
generate
docs
for,
like
in
case
you
care
right,
that's
something
that
someone
using
rust
stock
might
find
useful,
while
not
impeding
the
people
are
just
using
rust
c.
F
Yeah,
I
think
we
also
lack
a
mode
of
sort
of
warnings
for
people
like
using
editors
and
stuff,
like
that
sort
of
warning
is
really
annoying
to
silence.