►
From YouTube: Triage meeting 2019.04.25
Description
Triage meeting from 2019.04.25
The topics up for discussion were:
- Async-await syntax resolution plan 4 – we have a general plan for how to resolve the question of async-syntax, but we’ve not communicated it (surprise!). We are going to touch base on the plan and who will communicate what and where.
- Meta working group kickoff proposal – plan to kick off a group to discuss how working groups should function.
https://internals.rust-lang.org/t/lang-team-working-group-sync-meetings/9573/7?u=nikomatsakis
B
B
B
We've
discussed
in
Prior
meetings,
the
question
of
when
draw
order
should
occur
for
async
offends
and
we
basically
fixed
the
main
problem.
So
unused
parameters
are
now
being
dropped
at
roughly
the
time
that
you
expect
them
to
be.
However,
in
so
doing,
we
encountered
some
discrepancies
in
our
own
in
the
drop
order,
with
normal
functions
like
basically,
what
we're
doing
now
is
something
like
this,
if
you,
if
you
imagine,
there's
some
pattern
up
here
and
we're
sort
of
D
sugaring
this
something
like.
B
Which
is
sort
of
how
I
always
imagined
functions
work,
but
it
turns
out
they
actually
drop.
There
are
some
subtle
differences
in
order
which
drops
might
occur
but
like
if
you
compare
to
a
regular
function
in
the
case
where
you
have
patterns
with
underscores
and
things
like
that
and
I
forget
all
the
exact
details.
The
question
is:
how
much
do
we
care
about
this?
B
Do
we
want
to
MIT?
Do
we
want
to
sort
of
match
precisely
the
order
of
normal
offense
at
the
cost
of
the
implementation
more
complex
in
the
discovery,
much
more
complex,
or
do
we
want
to
say
that
the
ordinary
or
draw
order
of
functions
is
kind
of
wrong
and,
like
too
bad
that
I
can't
change
it?
But
you
know
it's
close
enough.
I
think
that
it's
really
drawn.
D
A
B
C
Can
see
one
matching,
which
is
that
I
would
expect
to
see
a
lot
of
the
interfaces
that
map
a
kind
of
a
slot
to
call
an
async
fun
with
an
async,
fun
and
frameworks.
For
example,
web
frameworks
other
things
where
there's
a
fixed
calling
signature
and
you
don't
always
need
all
the
pieces
of
that
calling
signature.
And
so,
if
you
force
holding
on
to
the
things
you've
been
past
until
you're
actually
called,
then
you
can't
necessarily
optimize
that
that
said,
I'm
not
suggesting.
B
But
that
feels
like
it
has
more
to
do
with
yesterday's
debate,
though,
but
like
about
the,
when
do
you
drop
relative
to
the
creation
of
the
future
versus
this
question,
which
is
more
of
like
assuming
you're
going
to
drop
after
the
future
has
been
pulled
in
what
order
within
that
we
drop,
but
let's
cover
it.
Let's,
let's
put
it
off,
because
I
think
Taylor's
right
that
we
don't
have
enough
quorum
for
maybe
we
can
elaborate
in
the
make
a
specific
example
in
the
the
issue.
D
My
wheels
trying
to
get
everybody
collected
to
to
actually
finish
up
that
Docs
that
we
can
get
it
released.
I've
been
paying
people
daily
to
try
and
get
that
photo.
I,
don't
know
what
I
guess.
We
have
a
separate
topic.
That's
this,
but
in
any
case,
aside
from
that,
it
feels
like
we're
very
close
to
having
something
that
stabilization,
ready
and
I.
D
D
B
B
D
D
B
D
B
And
you
say
if
you
have
you're
allowed
to
allied
lifetime
simple
headers
thanks
to
Wes
2018.
So,
but
you
are
not
allowed
to
elide
lifetimes
completely
invisibly,
they
can't
be
totally
hidden.
So,
for
example,
if
you
have
like
the
ref
type,
you
have
to
write
tick
underscore
when
there's
a
lifetime
parameter,
you
don't
get
to
just
leave
it
out
in
an
imp
letter.
That's
not
true
in
like
a
function
for
backwards
compatibility
reasons.
B
The
reason
we
did
this
is
because
we
intended
to
fully
deprecated
this
behavior
and
there
is
in
fact,
a
warning,
but
you
have
to
opt
in
to
the
warning
right
now.
The
reason
is
that
those
warnings
working
they
weren't
ready
to
go
when
we
did
West
2018
intention
is
to
turn
them
on
after
a
while
and
I
realize.
Now
that
that's
what
work
item
we've
been
letting
slide,
but
that's
fully
independent
from
this,
so
we
figured
there
was
no
reason
to
support
the
older
behavior
in
newer
code.
B
We
share
a
lot
of
the
code,
as
it
happens
in
the
compiler,
the
handles
imple
headers
and
async
offense,
and
so
this
this
error
miss
this.
This
issue.
It
has
to
do
with
people
who
are
we're
not
using
tik
underscore,
and
they
were
not
getting
the
results
they
expected.
One
way
to
fix.
It
is
basically
to
make
that
hard
error
in
the
same
way
that
it
is
an
implementer
saying
like
that's
deprecated,
you
should
write
tick
underscore.
B
This
is
what
I
prefer,
mostly
because
I
find
code
without
tick
on
a
square
very
hard
to
read,
but
also
because
it's
probably
easier,
it
obviously
would
be
backwards
compatible
if
we
wanted
to
allow
the
older
behavior
at
some
point,
but
central
raise
this
type.
This
I
think
because
he
thought
and
I
agree
that
it
would
be
good
to
run
it
by
people
here.
If
anyone
objects
to
that
or
feels
we
should
not
do
that.
I
think.
A
D
B
B
Alright,
anyway,
we
can
tube
there.
So
there's
two
RCS
nominated
the
I
think
this
one
we
already
talked
about
the
rod
reference
I
talked
to
Ralph,
didn't
yet
find
it
perfect
date
for
that,
but
the
other
one
existential
types
with
external
condition.
So
this
RFC
is
about.
It
was
about
allowing
you
to
define
an
existent
like
a
big,
substantial
type
infiltrate
and
then
specify
the
value
in
some
other
crate,
big
idea
being
defined
like
a
global
alligator.
This
way
or
other
kinds
of
global
configuration.
C
B
Probably
a
good
idea,
it's
certainly
I
did
I'm,
certainly
sympathetic
to
the
problem.
They're
trying
to
solve
the
Taylor
and
I
were
discussing
in
the
pre
triage
and
thinking
that
it
doesn't.
It's
not
anything.
We've
had
on
our
roadmap,
where
that
like
fits
any
of
our
priorities
and
we
were
inclined
to
hone
it
and
suggest
that
we
revisit
this
at
a
later
time,
but
for
the
temperature
of
the
room.
D
B
B
B
B
They
seem
like
things
that
would
happen
particularly
standard
or
Accardo,
which
doesn't
seem
on
a
squarely
laying
I
don't,
but
we
obviously
are
interested
in
it,
and
it
would
be
nice
to
talk
about
it
in
sort
of
tell
us
what's
to
be
interested
in
in
trying
to
figure
out
what
the
link
team
opinion
isn't.
This
I
think.
B
B
D
B
E
B
B
E
C
C
B
Well,
the
only
other.
So
there's
there
are
these
two
RFC's
that
you
open
Josh
about
floating-point
types
of
various
kinds,
and
my
main
reaction
to
them
was
that
I
had
no
idea.
They
were
coming
and
I,
don't
quite
know
how
they
fit
into
our
general
priorities.
That
guy
it's
not
clear
if
they're,
a
part
of
in
your
mind
like
a
see
parity,
FFI
thing
or
if
they
serve
a
different
function,
might
be
curious.
C
That's
something
I
wanted
to
bring
up
briefly
in
this
meeting
as
a
general
rule,
I
feel,
like
so
I
think
that
the
discussion
that
we
had
at
the
All
Hands
was
good
regarding
the
idea
that
there
are
some
RFC
is
that
we
want
to
defer,
on
a
basis
of
we
just
don't
have
the
time
and
bandwidth,
but
that's
not
so
much
a
statement
of
we
don't
care
about
these
things.
As
a
statement
of
we
can't
do
everything
and
we
have
to
prioritize
and.
E
C
B
B
B
C
Particular
oh
I'm,
trying
to
make
sure
it
is
that
one
possible
response
to
we
don't
have
enough
time
to
do
this
without
dropping
something
can
potentially
be
a
subgroup,
does
have
the
time
to
work
on
this.
Do
we
have
the
time
to
review
their
conclusions
when
they're
done?
Yes,
that
makes
sense
to
just
the
concept
of
oh
well.
This
wasn't
on
the
roadmap,
so
we
can't
do
it
if.
B
C
A
B
B
So
we
had
two
things
on
the
agenda.
One
was
hoped
to
be
sort
of
quick
which
was
about
the
async/await
syntax
checking.
So
we
had
this
plan
that
we
reviewed
last
time
to
roughly
go
over
the
a
rough
plan
to
resolve
questions
around
async/await,
syntax,
but
I,
don't
think
anything
got
announced
and
I
wanted
to
sort
of
make
it
actually
happen.
B
So
I
wrote
up
what
I
think
the
plan
is,
and
you
could,
if
we
could
like
say
who's
doing
what,
but,
since
central
it's
not
here
and
some
of
those
things
might
have
been
central,
that
might
be
harder,
but
I
guess.
The
main
question
is
for
the
summary
so
boats
there
there
were
some
additions
that
you
had
in
mind
for
this
room
you're
like
a
part
that
you
wanted
central
to
writers.
E
Does
it
like
why
we
shouldn't
like
there
was
an
argument
was
made
by
a
both
central
and
Josh
about
not
avoiding
having
syntactic
sugar
like
additional
hope
like
the
away
collection,
Marc
form
being
that's
preferable,
if
that
were
just
the
composition
of
two
indexes
that
otherwise
exist,
and
that
argument
I
think
would
be
better
if
one
of
them
made
it
then
trying
to
make
it
for
them.
I
would.
D
E
E
And
I
think
the
other
thing
is
who
finishes
the
conclusion
where
we
say
that
we're
going
to
move
on
to
next,
which
is
for
you
yeah,
so
when's
the
rest
and
then
I
can
write
that
and
then
post
it.
It
doesn't
seem
too
hard
to
write
right,
yeah,
but
then
I
don't
know
how
to
how
it
should
be
close
to
I
think
not
to
my
blog,
better
who's
posting
summer
I'm.
C
B
D
B
Plan
is
like
basically,
what
is
kind
of
summarized
to
your
right.
That
we
are
going
to
here
is
a
summary
document.
I
feel
like
we
could
even
post
it
personally
without
all
the
pieces
of,
say:
okay,
we're
still
adding
some
pieces.
Maybe
you
can
do
some
comments.
If
you
have
thoughts
over
here
or
something
but
I
don't
have
to
do
that
care
too
much
post.
The
summary
document,
then
we
say
votes
has
written
one
post.
D
B
D
D
D
D
D
C
B
B
C
Do
think
that
we
should
take
the
streaming
issue
into
account
by
way
of,
let's
create
a
an
orthogonal
syntax
that
meet
that
additional
requirement.
I
think
that
I
I
also
wanted
to
explicitly
mention
by
the
way,
I
think
boats
bringing
up
that
new
syntax
idea.
So
408
Way
is
an
important
part
of
the
discussion
and
something
we
should
roll
in.
We.
D
B
C
B
B
B
B
I
thought
that
the
first
thing
these
would
be
separate,
I
think
from
this
meeting,
and
it
would
be
open
to
people
to
attend.
But
hopefully
not
everybody
in
this
group
would
have
to
attend
because,
like
any
working
group,
it
should
come
back,
and
the
first
thing
I
was
thinking
that
would
be
really
good
to
agree
on
is
to
kind
of
hammer
out.
Actually
what
are
the
problems?
We're
trying
to
solve
talk
a
little
bit
about
problems.
I
have
some
thoughts
here.
B
B
I
think
it
makes
more
sense
for
it
to
be
a
per
working
group
concept.
So
you
could
imagine,
like
the
RF
FFI,
just
trying
to
hammer
out
the
problems
that
there's
specific
scenarios
and
things
that
we
are
trying
to
do
and
why
and
so
on
and
then
in
the
second
phase
here
going
into
the
exact
solutions
and
in
more
detail,
so
that
that
was
kind
of
the
spirit
in
which
I
thought
about
coming
up
with
problems
and
here's.
B
B
I'm,
assuming
that's
a
yes,
so
when
I
thought
about
what
are
the
problems
that
I
see
that
I
would
like
to
sort
of
solve
by
jigging
up
our
process.
This
is
the
stuff
that
I
came
up
with
I,
actually
Josh
I
think
this
last
point
relates
to
what
we
were
saying
about
the
earlier,
which
is
you
know,
first,
that
not
everybody
needs
to
make
every
decision
that
right
now
we
kind
of
have
only
this
one
meeting
and
it's
not
every
times
things
aren't
that
exciting
or
relevant.
So
it's
kind
of
hard
to.
C
B
I
think
a
big
one
is
that
we're
not
communicating
very
well
to
the
outside
world.
What
what
does
the
team
think
and
what
are
the
things
that
we
are
working
on
and
prioritizing
like?
We
have
kind
of
a
lot
of
individual
comments
about
what
we
as
individuals
feel,
but
we're
not
like
sending
a
clear
signal
about
actually
laying
team's
focus
on
X
Y,
&
Z
right
now.
That's
what
we're
spending
our
timeline,
which
I
think
could
be
really
divergent
right.
B
We
might
as
individuals
to
be
really
interested
in
all
kinds
of
features
and
hammering
out
speculative
discussion,
but
that's
not
necessarily
where
the
team
is
I
personally,
feel
this
a
lot
that
there's
a
lot
of
work
around
a
feature
and
we're
not
very
good
at
dividing
it
up.
I
would
like
it
if
we
were
better
so
that
we
could
basic
I
think
what
winds
up
happening
is
we
just
don't
do
all
the
work
that
we
could
be
doing
like
we
don't
have
it's
really
hard
to
follow
the
discussions?
B
We
don't
centralize
the
results
so
that
you
can
later
come
back
and
understand
the
reasoning
for
any
given
thing.
We
don't
have
explainers
telling
you
how
to
use
features
most
of
the
time
we
don't
for
a
lot
of
features.
We
don't
have
documentation
like
the
rest.
Reference
may
or
may
not
get
fully
updated
and
so
on.
I
feel,
like
those
things,
are
really
part
of
the
job,
and
we
should
be
doing
them
as
we
go
and
you
should
be
trying
to
do
them
together.
What
is
this?
B
I
have
no
idea,
I
meant
by
this
Ted
scored
on
RFC
cred.
Oh
just
that
there
is
discord,
not
discord.
The
chatting
mechanism,
just
that
often
there's
conflict
on
RFC,
threads
and
I-
think
that's
partly
a
symptom
of
them
trying
to
serve
too
many
purposes,
and
so
on.
That's
right.
It's
the
last
one
I
want
to
focus
on,
which
is
that
we
should
be
able
to.
B
We
should
be
sure
that
we're
spending
our
time
and
energy
on
the
right
things
I
think
right
now
it
we
often
get
like
when
people
open,
rfcs
and
so
on
our
practice
a
lot
of
time.
We
know
spending
potentially
a
lot
of
time
sort
of
dealing
with
ideas
that
are
dragging
us
off
of
the
course
we
wanted
to
set.
I
would
like
to
make
sure
we're
making
progress
on
items
we
feel
are
essential.
B
C
One
other
item,
which
is
when
opening
an
RFC
there
is
a
degree
to
which
we
are
either
relying
on
on
organic
discovery,
or
we
heard
manually
rallying
people
who
think
might
care
to
an
RFC.
The
former
has
the
notion
that
the
tone
of
an
entire
RFC
discussion
can
be
set
by
the
first
couple
of
people
to
show
up
and
if
the
first
couple
of
people
to
show
up
take
a
general
tone
of
you
know,
I
don't
want
this
so
go
away.
C
It
must
not
be
important,
then
that
can
set
the
entire
tone
of
an
RFC
thread.
It
is
difficult
after
that
point
to
try
to
get
more
voices
involved
and
especially
to
get
more
voices
involved
without
the
feeling
like.
Let
me
go
rally
people
that
I
know
actually
want
this.
So
there's
a
degree
to
which
not
just
team
attention,
but
community
attention
is
a
concern
and
getting
things
raised
up
the
flagpole
for
people
to
notice.
B
B
The
it's
probably
also
just
where
earlier
just
in
general,
my
assumption
about
the
conflict
on
RFC
threads
that
I
didn't
really
spell
out,
but
I
think
it's
relevant
to
what
you
said.
It's
that
I
think
that
the
more
that
we
can
get
a
team
of
people
sort
of
involved
as
early
as
possible,
but
teams
yep
whether
we
can
engender
a
group
and
feeling
that,
basically
the
better
off
we
will
be
as
well
as
keeping
our
discussions.