►
From YouTube: 2021-04-20 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,
recording
has
begun
josh,
I
will
let
you
drive
and
I
will
take
minutes
per
our
new
arrangement,
which
I
quite
like.
B
B
And
as
a
standing
reminder,
please
take
a
look
at
the
action
items
and
take
care
of
any
items
that
are
yours
that
you
haven't
already
done
or
if
you've
already.
C
Can
I
actually
ask
about
so
there?
The
action
item
written
down
was
taylor
to
close
that
rfc.
I
didn't
actually
think
that
that
was
what
we
wanted
there.
I
left
a
comment
on
it
when
we
originally
made
that
action
item
about
the
the
rfc
needs
some
amendments
to
clarify
the
behavior,
that's
intended
for
backwards
compatibility
purposes.
It
sounds
like
that.
The
decisions
there
have
actually
been
like
resolved
fairly
well
in
the
comments,
thanks
to
some
just
like
comments
that
manish
made,
but
they
haven't
ever
been
updated
in
the
rfc
itself.
C
At
this
point,
I
feel
like
like
we
kind
of
the
right
thing
is
to
do,
is
to
close
it,
but
I
kind
of
feel
like
that
should
be
almost
immediately
followed
up
by
somebody
just
reopening
it
with
those
fixes.
If
that
makes
any
sense,
I
don't
know
if
we
have
a,
I
don't
know
what
the
appropriate
procedural
step
is.
There.
B
A
A
D
A
C
Yeah,
so
this
got
linked
in
again
recently,
because
I
guess
libs
has
some
methods
that
they
want
to
add
that
overlap
with
existing
trait
methods,
and
they
don't
want.
I
I'm
sort
of
uncorrect.
I
think
that
the
thing
was
that
they
get
a
lint
when
you
import
the
trait
currently,
if
they
add
an
inherent
method
that
has
the
same.
C
That
covers
the
behavior
that
importing
the
trait
previously
provided,
and
so
now
users
no
longer
have
to
import
that
trade.
I'm
a
little
bit
unclear
on
whether
we
would
actually
want
this
like.
We
would
want
this
feature
to
change
the
behavior
of
that
lint
at
all,
so
I'm
kind
of
like
I
don't
really
know
a
good
solution
to
that
problem,
but.
E
C
B
So
the
proposal
in
the
libs
meeting
was
effectively
that
we
do
think
that
lynch
should
exist
and
the
question
was:
should
it
be
worn
by
default
or
allow
by
default
on
the
theory
that
warn
would
help
you
keep
your
import
list
pruned
for
the
latest
version
of
rust,
but
allow
would
mean
that
you
get
by
default,
the
behavior
of
being
able
to
be
compatible
with
both
old
and
new
rust,
without
worrying
about
whether
the
trait
method
was
imported
and
either
one
is
justifiable.
B
But
the
we
were
less
concerned
about
what
that
lent
would
be
and
more
thinking
there
would
be
a
lot
of
value
in
having
inherent
traits.
A
C
B
Yeah,
I
would
be
more
concerned
about
making
sure
that
the
inherent
traits
rfc
stays
alive
to
the
extent
we'd
like
it
to
so.
If
this
rfc
is
more
or
less
what
we
want,
and
it's
just
that
it
needs
to
incorporate
feedback,
then
either
we
should
get
the
presenter
of
the
rfc
to
do
that
or
see
if
somebody
else
wants
to
pick
it
up
and
run
with
it,
but
I
do
absolutely
think
we
should
keep
this
alive.
A
There
are
two
possibilities
I
mean
they
have
the
right
to
push
to
their
branch,
so
we
could
just
push
the
edits
and
merge
it,
which
I
sort
of
like
because
it
keeps
them
having
credit.
But
I
guess
if
we
rebase
their
commits,
that's
true
too.
I
don't
really
care,
but
I
would
the
question
is
mainly:
does
one
of
us
want
to
do
it,
or
should
we
put
out
a
call
for
someone
to
like
incorporate
these
edits
and
make
a
new
rfc?
D
D
It
felt
like
there
were
a
lot
of
open
questions
still
and
they
were
kind
of
I
don't
know
potentially
difficult
to
answer,
and
so
at
least
to
me
it
doesn't
feel
like
there's
a
you
know,
sit
down
for
an
hour,
retype
some
comments
into
the
rfc
text
and
it's
ready
to
merge
type
styles.
C
I
don't
think
I
don't
think
I
would
immediately
follow
up
changes
with
with
emerge
because
I,
but
I
do
think
that,
like
the
next
step
for
this
is
for
someone
to
take
this
rfc
and
just
kind
of
fill
in
answers
to
those
missing
bits.
I
agree:
they're
they're
left
as
sort
of
open
questions,
but
I
don't
think
that
they're
like
I
know
I
don't
think
they're
particularly
difficult
to
resolve,
like
I
think
there
are
reasonable
choices
for
for
all
of
them.
That
are
like.
C
Maybe
not
the
level
of
like
implementation
details
but
like
the
rfc
should
specify
a
choice
that
like
is
reasonable
and
works
and
like
then,
then
people
can
you
know
if
people
want
a
bike
shed
over
whether
it's
the
exact
best
formulation
of
it
they
can.
But
I
I
guess
I'm
saying
the
rc.
The
rfc
is
written
as
just
incomplete.
B
So
it
sounds
like
we
want
to
have
somebody
pick
it
up
and
work
on
it
and
that
would
run
counter
to
closing
it.
So
two
options
would
be
either
we
could
rfc
post
rfc
but
postpone,
and
that
would
close
the
issue
and
somebody
could
reopen
and
pick
it
up
later
or
we
could
leave
it
open
and
check
back
with
a
presenter
and
see
if
we
could
get
it
revived
taylor.
It
seems
like
you've
got
a
pretty
good
handle
on
this
one.
Would
you
be
up
for
trying
to
reach
the
presenter
or
shake
up
some
interest.
C
I
mean
I
don't
have.
I
don't
know
that
I
have
contact
information
from
them
outside
of
github.
A
A
A
A
Yeah,
I
do
want
to
check
in
on
that.
I
just
re-read
the
backlog,
bonanza
and
it
did
seem
like
everyone
was
pretty
positive,
then,
like
I
don't
want
to
pull
out.
I
don't
want
to
ask
this
person
to
pick
up
the
torch
if
we're
like
only
we're
not
sure
that
not
100
sure,
but
if
we're
not
mostly
sure
that
we're
gonna
see
it
through.
Do
you
know
what
I
mean?
So
I
don't
really
know
exactly
what
the
outstanding
questions
are.
C
A
C
C
E
It
I
think
I
ended
up
feeling
pretty
good
about
it.
I
think
I'm
convinced
by
the
like.
Well,
this
is
how
unsafe
works
normally,
so
it's
another
unsafe
trap,
but
there's
lots
of
unsafe
traps.
So
that's
okay
and
it's
not
a
safety
unsafe
trap.
So
that's
the
best
kind
of
unsafe
trap.
E
C
The
current
cost
rfc,
I
think,
just
has
const
on
the
whole
trade
dimple
rather
than
having
it
on
each
of
the
methods,
but
I
can't
like
I
just
as
a
user
would
find
it
extremely
surprising
if
I
couldn't
also
put
it
on
the
method.
So
I
like,
maybe
that's-
I
don't
know
how
other
people
feel
about
that
like
I
just
that
feels
like
a
oh
yeah,
of
course,
we
should
do
that
to
me.
F
E
C
D
C
F
B
Doing
new
design
in
this
meeting
right
now,
so
I
would
suggest
that
we
keep
the
rfc
as
it
is
to
specify
the
ability
to
emit
unsafe,
and
somebody
can
always
propose
an
rfc
to
handle
something
with
const
if
they
believe
that
it's
as
simple
as
this.
C
F
I'm
just
saying
that
doing
it
doesn't
mean
like
it's
the
same
treatment
in
both
cases.
It's
it's.
You
have
to
do
a
cement
like
if
it's
a
matter
of
like
saying
that
these
things
are
over
constraints
and
it's
the
over.
The
nature
of
an
over
constraint
is
just
different
for
unsafe
versus
const
and
that
one.
F
B
So
const
also
has
an
additional
bit
of
complexity.
On
top
of
that,
unsafe
does
not
have,
which
is,
there's
been
a
lot
of
discussion
about
const
handling
in
generic
types,
not
const
generics,
but
rather
how
do
you
write
an
impul
that
can
be
const
if
you're
operating
on
a
const
object,
but
can
also
be
cons
non-const
if
you're
operating
on
a
non-const
object?
How
do
you
specify
that
the
const
passes
through
a
generic.
C
A
B
So
I
think
what
I'm
suggesting
is.
It
sounds
like
there
is
another
rfc
that
addresses
that
particular
bit
of
interaction
with
const.
I
would
be
all
for
us
having
a
separate,
rfc
or
follow-up
or
similar
that
unifies
this
and
says
hey.
You
can
also
do
with
const
what
this
rfc
did
with
unsafe,
but
I
don't
think
that
we
should
immediately
assume
that
we
should
do
the
obvious
mapping
with
const
without
at
the
very
least,
specifying
how
this
interacts,
with
whatever
the
other
rfc
number.
C
B
C
C
E
Like
impul,
unsafe,
ord
plan
anytime
soon,
that
would
cause
weird
questions
so.
C
E
It
would
be,
it
would
be
something
like
there's
the
safe
version
of
ord
and
the
unsafe
version
of
ord,
but
they're
sort
of
the
same
trait.
But
by
saying
that
you
implement
unsafe,
then
you're
actually
reading.
B
Okay,
shall
we
move
on
to
the
next
set
of
sections?
Yes,.
A
B
All
right
we
have
two
pending
proposals
to
discuss.
One
of
them
is
lang
team
86,
allowing
the
compiler
to
eagerly
drop
values.
Nico.
You
had
an
action
item
to
make
sure
that
there
was
a
lengthy
design
note
on
this
yeah.
B
Okay,
let's
move
on,
and
then
there
is
a
proposal,
change
path,
attribute
behavior
of
modules
that
the
pitch
here
is
to
handle
module
paths
with
more
regularity
when
you
specify
an
explicit
source
path.
I
think
we
very
briefly
touched
on
this
one
last
week
and
didn't
come
to
any
hard
conclusions
other
than
it
does
seem
like
someone
should
work
on
this.
A
Presumably
not
2021
right,
okay,
I
don't
remember
this,
but
I
have
battle
scars
from
taylor
working
through
it
for
the
I
just
remember
it's
horrible.
I
don't
know.
I'm.
C
A
B
Fairly
confusing
yeah,
but
there
are
other
options
we
could
consider,
including
removing,
in
addition,
some
of
the
ability
to
combine
nested,
inline
modules
and
path
statements
if
we
felt
that
was
the
easier
way
to
regularize
this,
but
either
way.
I
think
someone
should
look
at
this.
It
sounds
like
we
have
some
consensus
that
somebody
should
look
at
this
and
try
to
fix
it.
A
E
C
Can
someone
well
like
does
the
thing
that
was
backwards,
compatibility
preserving
enough
to
not
break
the
libraries.
B
B
A
C
My
personal
intuition
would
always
be
that
path
would
be
file
system
based,
and
what
we
have
now
is
definitely
not
that,
but
what
we
have
now,
I
feel
like
is
like
relatively
consistent
for
making
the
other
choice
while
retaining
backwards.
Compatibility.
A
C
B
And
I
remember
compatibility
us
having
a
conversation
around
the
time
the
2018
module
system
was
being
designed
that
effectively
said
we
wanted
uniformity,
where
you
could
take
the
contents
of
an
out
of
line
module
and
the
inline
them
inside
braces
and
your
behavior
shouldn't
change,
and
I
think
that
was
why
we
had
this.
But
that
doesn't
necessarily
mean
it's
the
right
behavior
just
why
that
behavior
is
what
it
is.
I
believe.
B
A
B
So
I
think
the
two
things
that
need
doing
would
be
to
mention
any
of
the
new
alternatives
like
we
could
introduce
a
new
option
in
the
issue.
As
a
summary-
and
someone
should
pick
this
up
and
shepherd
this,
which
leads
us
to
the
who
wants
to
build
the
cat
question,
would
anybody
like
to
champion
this.
C
C
I
think
this
is
worth
the
effort
that
it's
gonna
take
and
it
has
to
happen
across
an
edition
boundary
and
I
think
it's
too
late
for
the
2021
edition.
So
if
we're
having
an
mcp
here,
it's
for
a
feature
that
we'll
deploy
in
2024-
and
I
just
don't
think
I
care
that
much
about
it
to
say
that
we
should
have
somebody
putting
effort
into
this.
A
D
I
I
will
say
that
you
know
whenever
I've
encountered
the
confusion
here,
which
I
did
actually
relatively
recently,
while
working
on
some
like
stuff
understood.
It
was
not
entirely
like
it's
confusing,
but
once
you
write
it
it
I
mean
it
works
and
like
it,
it
does
something,
and
maybe
you
don't
fully
understand
what
that
is.
D
But
path
is
so
rare
to
use
that
it
doesn't
seem
to
me
that
there
is
worth
in
investing
significant
effort
in
in
trying
to
make
it
very
intuitive
like
I
would
rather
do
something
else
that
makes
it
even
less
necessary
to
use
it,
but
it
already
is
really
like
really
rare.
So.
D
C
C
F
D
B
So
I
think
that
raises
another
point.
Actually,
a
minute
ago,
somebody
pointed
out
that
path
is
relatively
rare,
which
I
would
agree
with,
and
one
other
approach
to
this
rather
than
trying
to
make
path
easier
to
work
with,
would
be
to
look
at
the
cases
where
were
where
people
have
to
use
path
and
find
a
way
to
make
that
easier.
B
The
most
common
case,
I've
seen,
for
example,
is
conditional
compilation
where
it's
easier
to
say
config.
If
I'm
on
windows
then
grab
foo,
windows.rs,
otherwise
grab
foounix.rs
or
similar,
and
then
import
that
as
foo,
that
could
potentially
be
done
without
path
by
declaring
both
modules
somehow
and
then
importing
the
one
that
you
actually
need
with
a
pub
use.
B
B
A
F
F
B
Going
back
and
forth
that
I
see
so,
I
think
I'm
convinced,
based
on
the
conversation
we
just
had
that
this
is
not
worth
the
time
and
effort
to
change.
So
would
someone
be
up
for
writing
up
the
consensus
here
of
saying
we
would
need
some
evidence
that
there
are
specific
reasons
people
have
to
use
path
and
can't
use
something
else
and
also
find
this
confusing.
B
A
B
A
One
minor
thing
go
on:
there
is
in
this
one,
not
about
the
rc
itself
about
the
fact
that
we
have
three
boxes
out
of
five
checked.
I'm
not
sure
that
this
rule
that
says,
like
I
don't
know
I
I
sort
of
like
I
feel
like
we
allow
things
to
go
forward
with
relatively
narrow
consensus
without
with
the
team
as
small
as
ours.
I
know.
They're
me,
I'm
debating
about
proposing
a
change
to
the
triage.
B
Strictly
more
than
half
because
the
cargo
team
is
currently
four
people
and
the
two
boxes
is
not
enough
to
proceed.
You
need
three,
I'm
guessing
the
rule
is
strictly
more
than
50
percent,
so
we
could
tweak
that
threshold
a
little
bit
and
say
it
must
be
strictly
more
than
60
and
then
three
out
of
five
would
not
suffice.
F
B
B
No
self-admonishments
in
the
minutes
please,
but
by
all
means
please
make
it
action
items
for
yourselves.
Then
right.
B
All
right
next
up,
we
have
one
nominated
pr
for
rustling
reference.
This
was
discussed
previously
number
970
document
raw
pointer
to
you,
size
casts,
and
vice
versa.
Nico
is
going
to
leave
a
summary
comment
proposing
to
close
this
on
the
basis
that
this
is
not
ready
for
reference
work
yet
because
we're
not
actually
sure
what
we
want
the
semantic
to
be
here.
B
A
A
B
I'm
so
I
saw
the
original
rfc,
I
don't
know
the
current
state
of
the
tracking
issue.
I
would
suggest
that
we
drop
the
nominated
label
until
we
have
that
stabilization
report,
but
I'm
familiar
enough
with
this
to
think
assuming
it
is
working
as
designed
and
we
have
a
stabilization
report
then.
Yes,
I
think
we
want
this.
A
A
B
D
Yep:
okay,
do
we
want
to
leave
a
comment
saying
that
we're
generally
positive.
B
B
A
A
A
A
B
B
Sounds
about
right,
yeah!
Okay!
Next
up,
we
have
eight
three,
two
one.
Three
there
was
this
one
looks
like
it
already
got,
pre-triaged
that
it's
blocked
waiting
on
implementation
issues
and
doesn't
need
any
discussion,
so
unless
somebody
thinks
otherwise,
let's
move
on.
B
Okay,
eight
three
three
one,
two
parser
remove
support
for
inner
attributes
on
non-block
expressions.
This
was
a
proposal
from
petrochenkov
nico
has
done
an
fcp
merge.
So
I
think
this
is
just
awaiting
boxes.
A
Yeah,
but
I
did
that
just
this
morning,
people
might
wanna,
I
don't
know
if
people
will
be
into
it.
I
was
just
trying
to
keep
us
moving
specifically,
it
looks
how
I
understood
petroshenko's
comment
was
that
this
was
sort
of
going
past
what
the
rfc
had
requested
and
enabling
inner
attributes.
A
So
specifically,
if
you
click
over
on
petra
shenkov's
comment,
there's
some
good
examples,
I'll
copy
into
the
minutes,
but
like
in
our
attributes,
on
parentheses,
inside
of
the
arms
of
a
match
inside
of
struct
constructors,
which
actually
I
don't
really
like
them
being
in
most
of
those
places.
I
don't
mind
the
parentheses
necessarily
but,
and
this
is
kind
of
removing
them.
I
didn't
fully
understand
exactly
why,
but
I
trusted
petroshankov
too,
have
a
reason.
B
D
A
A
D
Yeah
I
yeah
well,
I.
E
B
D
B
E
B
A
I
think
they're
pretty
useful
and
important
in
blocks,
because
you
might
want
to
be
able
to
do
things
like
like
likely
and
unlikely
that
target
the
only
the
then
part
of
a
match
of
an
if
or
a
specific.
B
A
B
Sounds
good,
okay!
Well,
the
fcp
now
has
three
out
of
five
check
boxes
and
is
currently
in
final
comment
period,
albeit
we
just
said
that
we
would
probably
like
that
to
become
four
out
of
five.
B
Right,
but
in
any
case,
it's
just
a
general
concern,
not
a
specific
concern:
okay,
but
any
particular
change.
Next
up,
we
have
stabilize
extended
key
value,
attributes
eight
three,
three
six
six.
I
proposed
this
for
fcp
merge
recently
and
the
primary
this
allows
you
to
use
macro
expansions
in
the
value
of
a
key
value
attribute.
B
It
looks
like
there
is
a
concern
registered
on
it
from
nico.
Do
you
want
to
talk
briefly
about
that
concern?
Sure.
A
We
had
some
discussion
and
my
concern
is
not
with
the
state
of
the
code
but
with
the
state
of
the
documentation
around
the
code,
but
it
is
an
interesting
case,
so
I'll
explain
it.
It
has
to
do
with
consider
this
example
where
these
are
procedural
macros,
and
these
are
so
called
inert
or
doc,
is
the
so-called
inert
macro,
meaning
that
it's
not
a
procedural
maker.
It's
not
a
decorator.
What
happens
today
is
that
this
macro
does
not
get
expanded
until
both
of
the
procedural
macros
have
run.
A
I
don't
know
about
derive
I
forget
derive
has
funny
drive
is
funny,
but
the
the
key
analogy
that
made
this
make
sense
to
me.
So,
basically,
first
of
all
to
explain
decorators
in
case
people,
don't
remember
because
I
didn't
I
was
or
I
did,
but
I
wasn't
100
sure
decorators
apply
outside
in
so
essentially
this
stuff
is
sort
of
uninterpreted
until
after
the
decorator
is
finished.
So
this
this
first
decorator
gets
this
as
input
these
tokens,
the
second
decorator.
A
At
least
I
consider
that
analogy
to
be
reasonably
valid,
where
the
macro
also
is
not
expanded
until
after
this
decorator
has
run.
So
the
original
comment
said
either
said
in
the
comment
or
in
later
discussion
that
it
was
undefined
when
this
would
execute,
and
I'm
asking
did
it
be.
It
said
it
was
undefined,
but
observable
and
I'm
asking
that
it
just
be
defined.
B
It
does
make
well,
it
does
make
sense
that
we
expand
that
we
hand
those
attributes
the
full
token
list
from
what
follows
just
because
they're
allowed
to
invent
new
attributes.
B
The
idea
of
macros
in
a
value
position
in
a
key
value
attribute
is
new.
So
technically
we
could
define
a
semantic
for
it
that
we
would
prefer.
A
D
Yeah
this
is
commonly
used
in
in
instead
of
elsewhere,.
B
Well,
in
any
case,
if
the
it
sounds
like
your
concern
on
that,
rfc
is
just
or
on
that
issue
is
just
proposing
that
it
should
explicitly
document
the
behavior
to
match
what
the
behavior
will
actually
be,
rather
than
making
it
unspecified.
A
D
So
one
question
I
do
have
I
I
note
that
petrochenkov
left
a
comment
28
days
ago,
asking
two
questions,
one
of
them
about
whether
we
want
to
allow
arbitrary
expressions
in
this
position
and
it
looks
like
there
was
no
resolution
of
that
at
least
that
I
can
see
he's
not
aware
of
any
blockers
to
doing
so.
But
I
know
that
we
discussed
in
the
past
not
necessarily
wanting
that
and
I'm
curious
if
we
want
to
allow
that.
D
As
far
as
I
can
tell
it's
not
relevant
to
the
doc's
team
or
restock
team
request,.
B
So
so,
as
far
as
I
can
tell
it's
not
clear
to
me
that
this
pr
would
enable
that
it's
is
that
actually
being
enabled
here
or
is
that
just
a
discussion
about
what
we
might
want
to
expand
this
to
in
the
future?
B
D
A
So
that's
right,
I'm
not
sure
this
was
the
text
that
jyn
wrote
that
gave
me
the
impression-
or
maybe
it
was
that
maybe
something
else
give
me
the
impression
that
this
only
supported
metro's,
unstable
I'll
quickly
check
the
code,
but
that
that
is
a
good
question.
A
That
said,
I
don't
really
have
a
big.
I
mean
what
would
be
stabilizing
is
that
it
can
be
tokenized
more
or
less
right.
It's
still
an
error
once
it
hits
the
parser.
I
think.
A
D
A
F
The
comment
thread
the
pr
author
said,
like
arbitrary
expressions
can
be
added
later
and
still
be
backwards,
compatible
right
question
mark,
so
I
think
their
intention
was
that
they
didn't
want
to
try
to
stabilize
try
to
inject
that
as
a
feature
and
have
it
be
stabilized
inadvertently.
I
think
they
just
mean
it.
Maybe
didn't
realize
that
that
would
be
an
outcome
of
this.
F
I
don't
know,
but
let's
whatever
the
pr
does,
doesn't
matter
as
much
as
what
we
want
to
do
sure
sure,
I'm
just
trying
to
express
what
the
author's
intent
might
have
been
in
terms
of
guiding
us
towards
a
consensus
with
them
or
more
quickly.
That's
all!
Yes.
Yes,
I
think
nobody's
arguing
in
favor
of
it.
F
D
If
you
don't
pass
the
string
and
you
can
just
pass
an
expression
in
some
sense,
but
my
worry
is
that
expressions
bring
a
lot
in
from
what
I
recall
past
discussions
of
potential
like
unresolved
questions,
of
which
sort
of
context
they
expanded,
especially
if
it's
like
inside
a
function
can
I
use
you
know
a
local
variable
and
does
hygiene
like
magically
work
or
or
what
is
the
story
there,
and
so
I
feel
like
potentially
asking
to
exclude
that
from
this
stabilization
makes
sense.
D
A
D
A
Arbitrary
expression
here
so
better.
D
D
It
does
seem
like
the
only
thing
that
the
rust
stock
team
is
actually
interested
in
is,
like
literally
include,
stir
and
maybe
concat,
both
of
which
are
a
lot
simpler
and
feel
sort
of
uncontroversial,
because
they
only
receive
like
tick,
static,
stir
and
at
compile
time,
and
so
maybe
just
saying
we
stabilize
those
and
nothing
else
is
sufficient
and
we
can
leave
these
questions
for
later.
D
B
I
think
I
think
it
makes
sense
better
understood.
I
think
that's
enough
that
I
would
agree
with.
I
think
that
there
is
value
in
allowing
other
macros,
if
only
because
people
may
want
to
wrap
things
like
include
stir
in
their
own
macros,
and
that
should
still
work,
but
I
do
think
that
we
should
get
clarification
on
what
this
proposal
is
actually
enabling
and
what
it
isn't
before.
We
let
it
go
through.
E
D
A
A
B
Have
eight
three
three
eight
six,
which
switched
over
to
using
pat
param
instead
of
pat
2015,
and
that
is
currently
in
fcp
and
doesn't
need
any
further
discussion.
Unless
people
want
to
talk
about
it,
then
we
have
all
of
two
minutes
and
four
items
we're
not
going
to
get
to
all
four
of
them.
Is
there
anything
people
want
to
prioritize,
rather
than
just
going
on
to
the
very
next
one.
A
Short
version
is,
we
had
accepted
pub
pub
macro
rules,
but
then
we
kind
of
backed
off
from
moving
forward
with
that,
because
a
bunch
of
annoying
problems
arose
and
the
implementation
is
kind
of
incomplete,
it
doesn't
work
across
crates
and
stuff,
and
this
pr
basically
just
reverts
it,
because
no
one's
actively
working
on
it
and
it's
just
kind
of
dead
code.
That's
what
I
wanted.