►
From YouTube: 2021-03-02 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
Okay,
so
tomorrow
is
the
planning
meeting
just
an
update
and
I
started.
I
have
been
too
busy
to
make
a
more
organized
way
to
do
this,
but
for
the
time
being,
I
created
this
hack
md
for
people
to
leave
updates
regarding
interesting
features
like
projects
they've
been
working
on.
A
So
if
you're
you're
shepherding
any
projects,
please
take
a
look.
I
will
maybe
send
out
some
things.
If
I
I
don't
want
to
make
any
promises.
A
A
Josh,
I
don't
know
where
josh
is,
but
as
far
as
this
goes
ryan
is
going
to
orion
scott
and
I
have
a
meeting
later
to
go
over
some
of
that
stuff.
So
I
guess
we'll
do
that.
All
right,
let's
move
on
draft
patterns
fcp
is
pending.
I
don't
really
think
there's
much
of
oh.
I
wrote
action
that
I'm
here,
because
I
was
going
to
write
that
I
was
going
to
open
a
zoolop
stream
or
something,
but
I
guess
I'll
wait
till
the
fcp
is
over.
A
Am
I
audible?
Now
you
are
audible.
B
Now
excellent
wrong
microphone.
Sorry!
B
Yes,
I
did
post
to
that
one
immediately
after
last
week's
meeting
to
provide
the
summary
from
our
discussion
in
the
meeting,
so
that
has
been
updated,
but
then
there
have
been
a
few
discussions
since
then
trying
to
sort
out
exactly
what
change
should
be
made
and
how
that
could
be
done
without
breaking
existing
code.
Okay,
we'll
come
to
that
later.
B
A
All
right
so
yeah
nothing
to
do
here,
but
wait,
but
maybe
mark
you
can
note
down
this
action
item
for
me
to
remember:
yep
constitute
brfc,
so
there's
a
pending
fcp
taylor,
you
registered
a
concern.
Was
it
a
serious
concern?
What
was
your
concern.
C
Oh,
I
I
was
ralph
actually
already
responded.
My
concern
was
basically,
why
are
we
doing
this
and
in
the
sense
that
I
it's
not
clear
to
me
what
the
value
add
of
offering
these
as
guarantees,
rather
than
as
sort
of
nice
to
have
like
we
detected
that
you
have
a
bug?
Behaviors
is,
and
I
like
to
comment,
sort
of
spelling
that
out
and
talking
about
how
I
think
it
might
limit
our
abilities
to
to
optimize
in
the
future
and
also
for
alternative
rust
compilers
to
offer
a
sort
of
you
know.
C
A
I
feel
like
I
don't
find
either
thing
very
convincing
like
we
could
say
that
you're
required
to
do
it,
and
then
people
can
offer
flags
that
disable
it
for
performance
reasons
and
yeah
they're,
not
conforming
with
our
spec
or
whatever.
If
we
ever
have
another
implementation,
but
like
so
what
you
mean
like
fast
man,
yeah,
probably
I
don't
I'm.
C
C
Yeah,
I
think
I
could
be
convinced
by
that.
I
I
do
think
that
it's
not
clear
to
me
that
there's
a
ton
of
value
in
saying
that
you
know
we
promise
to
provide
errors
on
these
certain
pieces
of
undefined
behavior
and
ctfe,
which
sort
of
turns
those
pieces
of
undefined
behavior
into
effectively
defined,
behavior
or
office,
making
a
distinction
in
the
rfc
and
in
their
comment
to
between
things
that
users
of
ctfe
can
rely
on
versus
authors
of
ctfe.
C
A
Is
that,
if
basically,
that
we're
allowed
to
make
ub
stop
compiling
and
make
further
changes?
But
maybe
it's
a
good
question
exactly
what
the
way
he
phrased
it
now
that
I
think
about
it
is
a
little
strange
or
rather
we'd
be
allowed
to
at
some
point,
make
that
ub
defined,
and
so,
if
you
were
leaning
on
the
fact
that
it's
a
compilation
error
to
prevent
some
further
unsoundness,
that
is
not
directly
related
to
being
ub,
then
your
code
might
no
longer
work.
A
C
I
mean
so
the
the
two
specific
examples
were
use
of
a
poisoned
value
in
control
flow
and
and
dereferencing
a
dangling
pointer.
So
like
I
used
after
free,
for
example,
I
have
a
hard
time
imagining
that
happening,
but
I
guess
I
can
imagine,
like
maybe
matching
on
a
poison
value,
could
wind
up
being
not
uv
in
the
future
depending
on
you
know
something
something
the
discriminant's
there,
but
the
innards
aren't
or
something
like
that.
I
don't
know.
A
C
Okay,
yeah
in
general,
like
I
I
don't
like,
I
don't
hate
the
idea
I
just
like
it
seems
like
an
unnecessary
thing
to
promise
that
we
do
like
it
feels
like
the
benefits
that
we
get
out
of
promising
that
we
have.
These
checks
are
very
little
when
we
also
don't
allow
users
to
rely
on
the
fact
that
we
have
these
checks
right.
A
C
C
C
A
C
A
C
A
E
Yeah,
I
I
think,
there's
a
third
question
in
some
sense,
which
is
like
what
are
the
benefits
to
like
what
are
the
limitations
we're
imposing
on
the
language
team
in
some
sense
anymore,
for
in
the
sense
that,
like
obviously,
if
we
don't
make
this
guarantee,
we
can
always
make
it
later.
But
if
we
do
make
the
guarantee
like,
what
are
we
closing
out
from
like?
Can
we
relax
the
guarantee
later,
or
is
that
not
okay,
that
sort
of.
C
Yeah
like,
for
example,
there's
this
line
about
that,
we
will
explicitly
cause
copulation
to
stop
with
an
error
if
we
use
an
invalid
value
in
arithmetic
logic
or
logical
or
control
flow
like
that
would
imply
to
me
that
we
have
some
sort
of
defined
notion
of
what
it
means
to
use
an
invalid
value
in
those
sorts
of
places,
so
that
users,
like
you
know
I
I
feel
like
that's
like
kind
of
underspecified,
but
we're
saying
that
we
want.
We
think
it's
valuable
to
specify
that
we
will
cause
an
error
there.
E
C
A
F
Yes,
so
I'm
I'm
having
a
hard
time,
remembering
exactly
where
we
were
in
the
discussion
last
time
with
this
group,
but
essentially
we
looked
at
common
patterns
that
people
use
in
macros,
and
by
common
I
mean
you
know
not
things
that
I
wouldn't
really
classify
as
advanced
use
cases,
but
really
anything
that's
non-trivial
and
tried
to
apply
the
new
scoping
rules
that
are
being
proposed
in
the
rfc
and
in
particular,
recursive
macros,
so
macros
that
call
that
call
themselves
are
possible
but
can
be
difficult
to
pull
off
in
the
new
scheme
in
particular.
F
The
macro
definition
needs
to
use
a
full
path,
a
full
known
path
to
the
macro
inside
of
it
to
call
itself
if
you're
exporting
the
macro
from
a
crate
into
another
crate,
that's
generally
pretty
easy,
but
for
crate
local
macros
that
can
sometimes
be
difficult
or
it
might.
F
There
might
not
be
one
canonical
path
that
everywhere
else
in
the
crate
can
refer
to
that
macro
from,
and
so
you
end
up
in
a
situation
where
it
can
be
a
little
bit
yeah
difficult
to
write
a
macro
that
can
be
used
anywhere
inside
of
a
crate.
F
There
are
other,
slightly
more
advanced
use
cases
like
local
macros
or
private
macros,
so
macros
that
are
defined
within
other
macros.
F
This
is
a
less
common
use
case,
but
it
still
can
lead
to
errors
in
the
new
system
where
previously
we
accepted
them,
because
macro
shadowing
was
allowed
and
so
basically
we're
kind
of
at
an
impasse
like
I,
I
don't
exactly
know
where
to
go
from
here.
I
have
some
ideas
and
can
try
to
see
if
I
can
gain
consensus
on
them,
but
it
would
be
interesting
to
see
what
other
people,
how
other
people
feel
about
this.
This
point.
A
A
F
To
do
well,
it's
it's
not
only
that
you
can't
name
it's
that
you!
You
have
to
have
a
canonical
way
to
name
it,
so
a
way
that
you
can
name
it
from
anywhere
in
the
crate
where
you
would
use
that
and
sure,
like
that's
possible
to
do.
But
again,
you
might
run
into
a
little
a
situation
where
one
part
of
your
crate
wants
to
refer
to
it
or
wants
to
have
certain
scoping
rules.
B
I
believe
that's
an
issue
that
applies
to
things
other
than
macros
today,
and
it's
just
that
macros
happened
to
conveniently
bypass
it
somewhat
yeah.
You
already
had
to
solve
the
problem
of.
How
does
your
macro
refer
to
things
in
your
crate
that
are
not
macros,
and
that
is
an
issue
that
we
should
provide
a
solution
for,
but
it
doesn't
seem
like
one,
that's
a
critical
blocker
for
making
this
switch.
B
The
shadowing
issue
is
actually
a
potential
blocker
for
telling
people.
You
should
use
this
new
mechanism
because
we
don't
have
a
way
to
solve
that
one.
Yet
it's
not
a
blocker
for
here's,
a
new
thing
you
may
optionally
use,
but
if
we
wanted
to
say
this
is
the
only
way
that
you
should
use
macros,
we
would
need
to
solve
shadowing,
but
it's
not
critical
that
we
solve
recursion
or
similar,
because
people
can
do
that
with
a
challenge
or
they
could
do
it
by
using
the
old
system.
So.
A
B
They're
used
to
clarify
the
case
I
was
getting
at
was,
if
you
have
a
macro
that
calls
something
else
in
your
crate,
that
isn't
a
macro.
That's
an
issue
today,
because
you
have
to
go
use
a
path
to
your
crate
in
order
to
reference
that
thing
all
right,
the
so
it
was
already
an
issue
to
refer
to
things
in
your
crate
from
a
macro.
F
Yeah,
I
I
personally
think
that
you'll
you'll
run
into
this
issue
more
with
macros,
because
at
least
in
use
cases
that
I
have
used
macros
for
I
tend
to
refer
to
the
macro
itself,
particularly
in
like
little
helper
macros
that
do
things
like
define
a
whole
bunch
of
structs
for
me
or
a
whole
bunch
of
types.
For
me,
I
won't
refer
to
other
items
outside
of
of
my
scope,
but
I
might
recursively
refer
to
my
macro
and
in
that
case
you
would
run
into
this
issue
where
you
wouldn't
have
run
into
it
before.
F
So.
I
agree
like
this
is
an
issue
that
exists
already,
but
we
might
end
up
introducing
it
more
often,
or
people
might
run
into
it
more
often
in
this
world
and
what
I'm?
What
I'm
worried
about
in
particular,
is
people
encountering
this
more
often
getting
frustrated
by
it
and
knowing
that
they
can
just
remain
on
the
current
system
and
avoid
these
problems.
And
if
that's
the
case,
then
are
we
introducing
something
that
no
one
will
want
to
use?
A
So
one
thing
we
didn't
last
time
we
talked
about
this.
One
thing
we
didn't
know
for
sure
was
how
it
worked.
If
you
had
crate
the
pub
used
the
macro
and
gave
it
another
name
and
a
different
path
and
stuff
like
that,
what
did?
How
did
dollar
credit
work,
and
I
think
you
did
some
experiments
ryan
right
and
found
out
that
dollar
crate
kind
of
works
hygienically.
It
always
refers
to
the
defining
crate.
Even
if
that's
not
something
the
user
could
write
themselves.
F
But
well
again,
I
think
this
is
it's
less
likely
to
arise
in
cross
crate
usage,
because
you're
already
going
to
have
to
refer
to
you're,
referring
to
something
in
crate
b,
that
was
defined
in
crate
a,
and
so
there
will
always
be
a
canonical
way
to
refer
to
that
macro
through
a
fully
qualified
path
like
a
a
path
from
the
top
level
of
that
crate,
but
and
create
local
use
cases.
That's
not
necessarily
the
case
so
again,
you'll
run
into
this.
F
Off
off
the
top
of
my
head
in
code
here
in
this
document,
let
me
see
if
I
can,
I
might
need
a
few.
I
guess
it
would
occur
if
you
did.
F
Yeah
and
in
particular,
that
that
also
makes
it
brittle
like
if
you
require
the
user,
to
have
the
macro
referable
to
without
a
path
in
front
of
it.
You
know
that's
a
certain
use
case
that
you
would
have
to
define
like
hey.
F
Do
you
have
to
this
has
to
be
referable
by
its
name
and
only
its
name
in
order
to
be
used,
and
so
you
might
end
up
with
breakage
like
if
people
don't
read
that
document
documentation
and
they
use
the
macro
qualified
by
a
path,
it
will
not
work,
whereas
if
they
use
it
without
the
path,
it
will
work
and
that's
a
paper
cut.
A
F
A
A
G
G
G
F
A
F
So
so,
just
to
mention
there
was
this
additional
idea
of
a
dollar
sign
self,
which
has
been
met
with
some
with
a
little
bit
of
pushback.
That
kind
of
mirrors
dollar
sign
crate,
but
refers
to
the
module
in
which
you
are
defining
the
crate,
the
the
macro
to
finding
the
macro.
F
F
A
Yeah,
but
I
don't
know,
I
don't
feel
good
about
this
for
all
the
reasons
we
said
before,
like
we
first
of
all,
we
decided
it
was
a
future
compatibility
thing
and
secondly
like-
and
we
had
another
meeting
that
we
thought
was
very
obvious,
which
was,
I
think
it
was.
F
F
Yeah,
oh
exactly
sorry,
and
it
was
also
mentioned
that
it
should
probably
dollar
sign
capital
s
self
to
as
a
potential
different
syntax.
B
Right
dollar
sign,
lowercase
self,
just
breaks
too
many
things
in
the
ecosystem
to
be
reasonable
to
introduce,
but
that's
a
syntactic
issue.
If
we
have
a
mechanism
like
this,
it
will
likely
help,
but
so
will
dollar
crate
full
path.
Macro,
assuming
that
your
macro
is
exported
at
a
established
place
from
your
crate
yeah,
so
it
doesn't
seem
critical
to
have
an
equivalent
to
dollar
self
here
when
dollar
crate
full
path.
Macro
is
an
option
we
could
even
potentially
lent
for
this.
B
A
You
know
sorry,
I
think
I
actually
have
to
drop
for
this
other
meeting,
I'm
looking
at
it.
It's
a
required
training
thing.
Josh,
I'm
gonna
make
you
host.
Okay.
Do
you
mind
picking
up
the
meeting
yeah?
I
can
pick
up
from
here.
Okay,
sorry,
y'all.
B
For
this
one,
rather
than
do
an
extensive
discussion
of
trying
to
solve
the
problem
in
this
meeting,
it
seems
like
we
may
want
to
take
the
full
solution-
space
exploration
to
zulip
or
similar,
but
I
think
the
higher
level
question
is
which
of
these
problems
needs
solving.
F
Yeah
and
in
particular,
with
a
new
default
question
like
with
russ
2021,
coming
fast
approaching
and
and
the
timelines
that
have
been
set
out
for
that,
like
we
sort
of
have
to
either
solve
these
issues
immediately
or
you
know
in
the
next
couple
of
weeks
or
one
of
the
possibilities
of
this
being,
a
new
default
kind
of
false
falls
away,
at
least
for
the
next
few
years.
E
Yeah
I
I
guess
I
have
a
maybe
higher
level
question
in
some
sense,
I
I
am.
I
personally
am
getting
the
sense
that
this
is
a
pretty
big
can
of
worms
and
that
we
can
potentially
spend
a
lot
of
time.
You
know
working
out
potential
alternatives
or
the
solution
space
and
potentially,
what
we
should
say
and
said
is
that
you
know
macros
as
they
stand
today.
You
know
work,
okay
and
maybe
there's
you
know,
pain
points,
but
maybe
this
is
not
the
you
know
the
thing
to
tackle
at
this
juncture.
F
Yeah,
I
I'm
sympathetic
to
that
just
because,
given
the
the
complexity
that
we're
seeing
here,
I'm
I
I
do
wonder
if
it's
you
know
if
this
is
the
right
time
to
to
solve
this,
because
I
do
worry
most
about
ending
up
in
a
situation
where
we
have
a
hybrid
approach
and
it's
hard
to
teach,
because
in
some
situations
you
use
one
approach
and
others
you
use
another,
and
it's
really
hard
to
un
to
to
gauge
whether
the
new
public
or
the
new
scoping
rules
would
allow
enough
expressivity
in
order
to
meet
most
use
cases
to
where
99,
let's
say
of
rust,
users,
don't
ever
have
to
use
the
old
system
of
scoping.
F
If
we
could
have
a
guarantee
there
that
you
know,
most
people
will
never
see
macro
export
or
macro
use
again.
I
would
feel
a
lot
better
about
this
proposal,
but
the
fact
that
that's
you
know
we
can't
reach
that
conclusion
today
makes
me
hesitant.
B
I
would
propose
one
distinction
there.
I
think
that
this
is
a
sufficiently
large
can
of
worms
that
we
should
not
try
to
make
macro
rules,
mean
pub
self
macro
rules
and
just
completely
transition
in
in
this
next
edition.
There
are
too
many
things
that
need
solving,
and
if
we
found
two
this
quickly,
there
may
be
more
that
we're
not
aware
of,
but
that
isn't
necessarily
a
blocker
for
us
introducing
this
mechanism.
B
First
of
all,
as
an
option
for
pub
macro
rules,
pub
self
macro
rules
and
just
not
change
the
behavior
of
macro
rules,
and
it's
also
not
a
blocker
for
us
introducing
this
as
an
unstable
nightly
feature
for
people
to
experiment
with
and
try
to
find
more
of
these
problems,
and
then
we
can
evaluate
further.
If
and
when
we
decide
to
stabilize
this
whether
there
are
any
issues
that
would
block
us
from
doing
that.
G
Well,
wait
so
I
thought
ryan
had
said
that
with
their
cons,
they
had
a
concern
about.
If
you
try
to
introduce
these
new
things
without
addressing
the
problems,
then
you're
gonna
have
this
hybrid
system,
where
macro
rules
behaves
differently
from
the
case
where
you
had
pub
in
front
of
it.
It's
gonna
be
hard
for
users
to
understand
when
this
was
used.
One
versus
the
other
right
that
did
that
come
through.
B
No
that
did
come
through
that's
what
I'm
trying
to
ask
to
put
the
discussion
on,
rather
than
the
specifics
of
the
issue
related
to
trying
to
solve
the
problem
in
time.
For
an
addition,
I'm
asking
the
question
of
is
that
an
issue?
Do
we
consider
that
a
blocker
in
terms
of
having
two
different
systems
would
that
be
too
much
complexity
for
people
to
deal
with
to
experiment?
E
Yeah,
I
guess
I
I
feel
it
is-
I
I
don't
think
we
should
like.
I
would
not
want
to
spend
link
team
bandwidth
and
compiler
team
bandwidth
and
sort
of,
even
if
we
had
everything
implemented.
I
think
that
I
would
not
want
to
be
in
a
position
where
we
have
even
potentially
temporarily,
an
opt-in
to
this
alternative
system.
I
see
I.
B
B
E
E
What
it
feels
like
to
me
is
that
sort
of
the
answers
start
easily
treading
on
the
sort
of
holy
grail
of
you
know,
hygienic
macros
and-
and
since
we
haven't
solved
that
you
know
in
multiple
years
now,
it
feels
unlikely
that
you
know
half
a
month
or
a
month
of
effort
from
ryan
or
some
other
folks
is
going
to
significantly
move
the
needle
there.
E
And
it
feels
to
me
that,
without
that,
any
partial
solution
is
going
to
be
ultimately
another
stepping
stone
and
we
might
end
up
with
you
know
three
alternative
systems,
the
legacy,
one,
the
kind
of
trying
to
be
hygienic,
but
not
hygienic
and
eventually
maybe
a
hygienic
macro
solution.
That
makes
sense.
B
No,
I
certainly
don't
think
any
of
us
would
want
that
of
here's,
this
halfway
point
that
didn't
quite
make
it
and
then
here's
the
full
system
do.
Does
that
concern
apply
to
experimentation
in
nightly
in
terms
of
trying
to
get
this
right
in
progress
through
experimentation
or
just
does
that
apply
to
stable.
E
Yeah,
I
I
think
the
design
questions
here
are
significant
enough,
that
even
adding
it
to
nightly
requires
some
amount
of
like
thinking
and,
and
you
know,
sort
of
effort,
and
potentially
you
know,
there's
a
question
of
you
know.
I
don't
know
similar
to
how
we
had
with
like
macros,
1.2
or
whatever,
if
prominent
crates
in
the
ecosystem
that
are
nightly
only
for
other
reasons
start
using
it.
Then
we
sort
of
we
don't
get
locked
in
necessarily,
but
there's
sort
of
a
open
question
of
like
okay.
E
G
I'm
more
inclined
to
be
okay
with
nightly
only,
but
I
mean
I
but
it's
it's
tricky.
F
I
I
do
think,
though,
like
that,
if
we
do
reach
a
point
where
we
can
get
this
to
work
where
we
can
have
a
full
transition,
let's
say
in
rus
2024
if
that
were
to
happen
like
this
would
be
a
better
system,
and
I
don't
necessarily
think
that
the
problems
are
as
difficult
as
a
fully
hygienic
system
have
proven
to
be
so
I'm
kind
of
hopeful
that
we
can
reach
a
point
there,
and
I
would
be
a
little
sad
to
see
this
kind
of
wither
away
into
nothing
and
having
something
in
nightly
means
that
we
can
continue
to
think
through
these
problems
for
the
next.
F
You
know
couple
of
years,
but
I
am
I'm
sympathetic
to
what
mark
said
like
then,
you
end
up
in
a
weird
situation
where
somebody
starts
using
it
seriously.
B
I
should
say
I
don't
think
that
we
should
make
this
conditional
on.
Let's
not
do
anything
until
we
can
do
a
full
macros
2.0.
I
don't
think
we
should
let
the
perfect
be
the
enemy
of
the
good.
I
am
sympathetic
to
the
point
of
let's
not
do
a
partial
solution
that
we
know
has
known
issues
before
we
even
introduce
it
and
therefore
prevents
people
from
transitioning
that
I
could
sympathize
a
great
deal
with.
If
we
solve
those
issues,
we
could
potentially
introduce
this
even
if
it's
not
full
macros
2.0.
E
Yeah-
and
I
think
the
important
bit
for
me
is
also
that
it
feels
to
me
like
some
of
the
design
points
on
the
spectrum
we've
discussed
so
far
are
not
necessarily
in
conflict,
but
at
least
would
be
sort
of
like.
If
we
did
have
hygiene,
they
would
be
not
entirely
obviously
compatible
in
the
sense
that,
like
you
know,
you
would
want
to
write
it
a
different
way
and
that
way
might
require
you
to
make
some
backwards
and
compatible
change,
which
feels
unfortunate.
E
Yeah
but
but
I
agree
that
I
think
that
I
don't
sort
of
want
to
see
this
wither
away,
but
I
do
think
that
maybe
the
right
path
is
sort
of
not
even
necessarily
a
project
group.
But
more
so
saying
that,
like
hey,
you
know,
maybe
we
can
have
a
like
a
lame
team
design,
note
or
whatever,
and
if
people
are
interested
in
sort
of
investing
in
designing
a
better
system,
then
we're
broadly
interested
in.
E
You
know
that
that
work
can
happen
outside
the
lane
team,
perhaps
and
sort
of
we're
happy
to
give
feedback
on
specific
proposals.
But.
B
That's
definitely
true:
I
think
it
was
borderline
whether
we
were
going
to
do
that
transition
on
russ
2021
to
begin
with
and
we'd,
more
or
less
said
we
might
consider
it
if
there
are
no
issues.
It's
pretty
clear.
There
are
issues,
so
we're
certainly
not
going
to
do
it
for
rest
2021,
which
means
it's
decoupled
from
a
timeline.
E
Yeah,
I
I
think,
potentially
the
immediate
action
item.
I
am
happy
to
type
up
a
comment,
sort
of
summarizing
what
we
discussed
today
or
or
if
someone
else
wants
to
that's
great
too,
and
I
think
there
is
an
open
rfc.
So
potentially
we
can
fcp
close
that,
particularly
as
taylor
and
nico
are
not
here.
B
B
E
Okay,
but
in
any
case
I
I
guess,
if
no
one's
opposed,
I
can.
I
can
leave
that
comment
and
then
bring
someone
on
the
lane
team
to
actually
initiate
the
fcp.
B
Okay,
then,
let's
move
on
to
declarative
macro
metavariable
expressions.
B
This
is
rfc
3086,
so
this
grew
out
of
what
was
originally
the
declarative
macro
repetition
count
proposal
and
instead
grew
into
a
exploration
of
the
syntax
space
to
introduce,
in
general
expressions
in
macros
that
don't
conflict
with
rust
syntax
to
do
things
like
counting,
and
I
the
number
of
cases
of
an
identifier
or
obtaining
a
length
of
a
given
repetition
or
index
of
a
repetition
that
kind
of
thing
to
avoid
having
to
invent
these
as
recursive
macro
counter
helpers,
that
kind
of
thing,
so
it
there
are
kind
of
two
pieces
to
this.
B
Has
anyone
had
a
chance
to
read
this
proposal
and
there
was
a
an
action,
a
set
of
action
items
for
three
people
to
review.
It
looks
like
of
those
three
people
we
just
have
felix
here.
D
Okay,
I
have
looked
at
this
to
me.
It
looks
very
useful
and
and
yeah
I'm
all
for
it.
D
Good
feedback,
like
my
first
reaction,
was
like:
oh
that
looks
a
bit
complicated,
but
then
you
look
at
how
you
would
do
those
things
right
now
and
in
all
cases
it
would
make
it
much
much
less
complicated.
A
good
example
of
that
is
the
first
comment
on
the
rfc
itself.
There's
a
comment
that
someone's
saying
like:
oh,
you
can
already
do
this
like
this
and
then
you're
like.
Oh,
my
god,
that's
a
perfect
example
of
how
you
absolutely
do
not
want
to
do
that
right.
So
yeah.
B
B
Okay,
I
can
take
the
action
item
for
this
one
to
write
up
a
summary
and
propose
merge
with
a
note
of
expecting
that
it
may
take
some
time
to
for
people
to
review
and
check
off.
D
B
Okay,
that
is
all
of
the
new
rfcs.
Let's
take
a
look
at
some
of
the
p
high
issues.
B
So
I'm
going
to
skip
over
repercy
as
unsound
on
msvc
targets
for
the
moment,
because
I
suspect
that
12
minutes
may
not
be
enough
to
go
through
that
in
detail,
and
I
think
that
is
the
only
p
high
issue
at
the
moment.
So
I
would
suggest
that
we
actually
go
on
to
nominated
prs
and
issues
unless
people
specifically
want
to
try
to
cover
that
one.
In
this
meeting.
B
Okay,
65516
was
a
nominated
issue
proposing
to
deprecate
weird
nesting
of
items,
things
like
mods
inside
functions
or
similar,
and
this
was
proposed
some
time
ago,
and
the
proposal
in
the
notes
here
is
nico,
suggested
we
don't
do
anything
to
deprecate
this.
We
could
potentially
soft
deprecate
it
in
the
future
without
that
being
tied
to
an
addition,
but
that
we
not
try
to
do
this
for
this
edition.
B
G
B
Yeah
trying
to
deprecate
this
certainly
does
seem
like
it
would
introduce
a
substantial
amount
of
churn.
There
is
some
potential
value
attached
to
removing
syntax
in
the
future
that
ides
don't
enjoy,
but
they
will
always
need
to
deal
with
old,
rust
code
potentially.
So
I
think
that
we
should
fcp
close
this
by
way
of
not
tying
it
to
the
edition,
and
if
someone
wants
to
make
a
proposal
for
soft
deprecating
in
the
future
not
tied
to
an
addition,
we
can
do
that.
B
Okay,
all
right
next
we
have
stabilize
the
unsafe
op
and
unsafe
function
lint
and
that
one
is
in
fcp
and
is
due
to
be
merged.
So
I
don't
think
this
needs
to
be
nominated
anymore.
B
Next
up
allow
super
in
module
in
block
to
refer
to
block
items.
I
can
give
a
quick
summary
of
this
one.
It
is
a
proposal
to
handle,
oddly
enough
weird
nesting
of
items,
specifically
a
module
inside
of
a
block
or
a
module
inside
of
a
fund
to
handle
other
things
locally
defined
in
that
fund.
It
was
introduced
with
the
notion
in
mind
of
if
you
have
code
that
works
at
top
level.
It
should
also
work
if
you
drop
it
inside
of
a
function,
because
that's
what
unit
tests
or
doc
tests
rather
do.
B
The
counter
point
to
that
is
this
would
introduce
a
weird
special
case
in
our
name
resolution,
which
name
resolution
is
not
something
we
want
a
lot
of
weird
special
cases
in
and
as
an
easy
means
of
evaluating
this.
I
am
doing
a
crater
run
right
now
on
the
theory
of
if
this
introduces
even
the
slightest
amount
of
breakage,
it's
not
worth
the
transition
pain
and
we
should
try
to
solve
that
issue
an
entirely
different
way
or
at
all,
and
only
if
the
crater
run
passes.
E
I
I
guess
I'm
sympathetic
to
the
problem,
but
I
don't
think
this
is
the
right
solution
and
I
I
feel,
like
generally
I'm
not
a
fan
of
complicating
our
complex
name
resolution
system
by
adding
more
things
that
you
can
potentially
refer.
B
B
G
B
E
I
guess
to
elaborate:
it
also
feels
like
a
very
patchwork
solution
in
the
sense
that
in
I
don't
know,
I
I
rarely
use
super
colon
colon
like
I
just
don't
I
like
referring
to
things
more
generally,
I
think,
but
it
feels
like
if
we
want
to
refer
to
things
in
a
block
and
sort
of
want
to
enable
that
I
would
want
some
sort
of
sort
of
more
complete,
probably
an
rfc
that
says
okay,
so
this
is
the
problem.
Here
is
the
solution
space.
You
know
working
through
right,
more
holistically
than
just
oh.
B
And
it
seems
to
work
okay.
I
would
agree
with
that.
Ironically,
the
one
case
where
I
tend
to
use
super
is
in
writing
unit
tests
in
order
to
refer
to
the
parent
module
from
a
mod
tests,
and
that
seems
like
a
thing
unlikely
to
happen
itself
inside
a
doc
test
unless
you're
documenting
the
unit
test
mechanism.
E
B
B
Not
okay,
it
sounds
like
this
probably
isn't
a
thing
we
should
do
even
if
the
crater
run
passes,
but
regardless
we
may
want
to
consider
a
potential
solution,
but
it's
probably
shaped
differently.
B
All
right
allow
qualified
paths
instruct
construction,
eight,
zero.
E
Or
maybe
someone
else
sure
yeah
I
can
do.
B
B
B
Okay,
next
up,
we
have
allow
qualified
paths
instruct
construction,
eight,
zero,
zero,
eight
zero.
We
did
discuss
this
last
week.
The
main
thing
we
didn't
get
to
was
a
concrete
proposal
for
what
exactly
we
wanted.
Our
next
step
to
be,
but
ryan
was
going
to
ryan
suggested.
The
action
item
was
to
try
to
get
all
different
uses
implemented
and
that's
still
in
progress.
So
ryan.
Are
you
aware
of
anything
that
needs
further
evaluation
here
for
nomination.
F
B
We
have
a
lint
related
item
for
bear
trait
objects.
This
was
deferred
on
the
basis
of
let's
discuss,
lints
and
put
out
a
complete
proposal.
Ryan.
Do
you
want
to
say
more
on
that.
F
We're
meeting
after
this
meeting
to
continue
discussing
lentz,
and
I
think
what
we
should
do
is
just
from
that
return
back
to
whether
how
we
address
lints
in
general.
F
I
believe
we
were
talking
about
it
in
zulup
on
the
edition
2021
topic
and
then
inside
of
lint
promotion.
So
I
can
post
the
link
to
that.
B
Okay,
all
right,
then
we
have
in
the
one
minute
we
have
left.
Let's
see
if
we
can
get
one
more
invalid
field
is
never
read,
lent
warning
eight
one
81658.
E
I
don't,
I
don't
think
we
have
time
right
now
to
discuss
it
in
phone.
No.