►
From YouTube: Triage Meeting 2020-06-29
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
A
A
Let's,
let's
look
at
the
project
work,
so
there's
a
couple
of
MCPS
here.
This
one
is
the
one
that
I'm
proposing
and
I
guess.
We
should
put
that
in
some
other
column.
A
But
there
are
two
others:
portable
Cindy
project
group
and
declarative
macro
repetition
counts.
I
wanted
to
call
attention
to
especially
this
second
one,
because
it
seems
like
a
relatively
narrow
proposal.
It
probably
wouldn't
take
too
much
work
to
serve
as
a
liaison
for
there's
a
few
possible
syntax
options
and
so
on.
But
it's
not
that
big
a
thing,
and
so,
if
someone
has
some
interest
in
that
rule,
what
this
is
about
is.
A
Basically,
giving
someone
a
way
to
find
out
how
many
instances
of
dollar
value
there
are
in
effect
early
when
this
thing
matches
and
I
think
the
actual
proposal
that
they
have
is
something
like
dollar
hash
value.
I
don't
know
anyway,
but
there
was
another
couple
comments,
but
might
be
interesting.
There
you
have
it.
Cindy
is
a
little
more
complicated
but
I.
Think
Josh
you've
had
some
interest
in
sort
of
looking
into
that
right.
We're
talking
to
him
me
already
about
it.
Yeah.
C
The
declarative
macro
repetition
counts,
I
haven't
just
look
at
it.
Yet
did
this
just
mean
that
was
supposed
a
long
time
ago.
This
person
actually
reference
that
previous.
C
All
find
it
and
maybe
add
a
link
to
it.
The
very
least
yeah.
C
A
That
I'll
be
helpful,
though
I
do
think
it's
a
good
idea
to
leave.
The
note
I
would
say,
like
at
least
my
hope
is
that
these
proposals
are
not
meant
to
it's,
not
necessarily
bad.
If
they
are
not
like
super
exhaustive,
because
the
idea
is
more
just
to
decide
do
we
want
to
put
energy
into
it
earlier
on
before
drawing
up
a
fully-formed
proposals
that
it
would
be
good
to
have
it
noted
for
when
composing
the
real
art
season
as
well?
A
Okay,
then
I'll
move
on
meeting
proposals,
so
we
had
this
meeting
I
uploaded.
The
video
seemed
like
it
was
productive,
I
might
archive
it.
These
are
our
two
current
meeting
proposals.
There's
review
of
safe
transmute
scheduled
for
this
week,
and
this
one
which
we
haven't
scheduled
so
I'll,
take
it
to
Azula
by
guess,
but
we
should,
if
anyone
has
any
thoughts
of
other
things,
they'd
like
to
discuss
with
the
team,
they
should
file
an
issue
and
we
should
schedule
the
next
couple
weeks
or
I
going
to
active
projects.
A
A
C
B
A
I'm
gonna
assume
that's
confirmed.
Okay,
any
comments.
We
want
my
decibel
pings
in
people,
so
these
next
two
items
I'm
trying
to
find
someone,
may
have
found
someone
who
will
work
a
little
bit
on
this
issue
of
tainting
fall
back
and
no
real
updates
on
this
other
coherence
issue:
project
safe
transmute.
We
have
a
scheduled
meeting
any
other
updates.
A
A
A
A
A
A
So
the
next
one
was
issue:
seven,
three,
seven,
seven,
eight!
It's
a
proposal
to
allow
the
likely
and
unlikely
intrinsics
inside
a
constant
F
ends.
I
guess
basically,
because
sometimes
we
want
to
use
them
like
or
improve
runtime
performance
and
they
have
no
real
semantics.
I
think
this
is
only
allowing
them
unstable
e,
so
I
nominated
it,
but
I
said
I.
Don't
think
it
means
I!
Think
since
it's
unstable,
unless
there's
some
objection
raised
in
this
meeting,
I
think
we
can
just
do
lang
team
approval,
so
any
thoughts.
A
B
Seems
entirely
reasonable
and
I
would
agree
both
with
the
statement
that
we
don't
actually
need
to
FCP
sign
off
this,
as
well
as
the
fact
that
likely
and
unlikely
make
sense
to
use
in
functions
that
should
also
be
available
at
compile
time,
and
at
that
point
they
can
act
as
an
identity
function.
That
has
no
other
semantics.
This
seems
perfectly
reasonable.
B
B
A
A
A
C
A
Nominated
issues
one
you
already
discussed
this
last
time-
I,
don't
know
that
this
still
needs
to
be
nominated.
This
was
the
matter
of
target
feature
and
safety.
I
think
I
just
forgot
to
unknown
Nate.
The
only
thing
I
would
mention.
While
we
are
sitting
here
that
I
did
open
an
issue
you
can
see
here
related
to
discussing
the
closure.
The
question
of
like
can
a
closure
inside
of
a
function,
use
the
target
features
of
that
function?
I,
don't
think,
there's
been
any
objections
raised
to
why
that
would
be
a
problem.
A
B
B
A
Think
so,
and
I
was
gonna
sync
up
with
Kyle
just
to
check
I
guess
the
only
question
was.
It
was
a
little
hard
for
me
to
tell
whether
there
was
a
concern
around
the
system
ABI.
So
we
had
some
discussion
that
to
have
enough
time
to
read
in
depth,
but
around
windows,
I
guess
that
win
API
uses
the
system
API
extensively
and
Peter
was
arguing
that
it
should
be
that
he
might
prefer
I
guess
that
it
would
like
Windows
Bunny.
That
is
that
it
would
unwind
permit
unwinding
by
default.
A
But
on
the
other
hand
it
seemed
like
none
of
the
functions
in
question
actually
do
unwind,
except
in
the
case
of
light
forests
on
lines
with
Windows
will
do
and
responds
to
seg
faults
and
other
things.
So
I
wasn't
really
clear
why
it
would
make
any
difference,
but
I
would
be
I
guess
I
would
be
a
little
concerned
if
making
this
change
required
a
3.0
or
whatever
version
sorry
things
falling
around
if
it
required
breaking
changes
to
win.
A
A
A
A
Any
other
comments
on
that.
Otherwise,
we'll
look
at
the
RFC
bot
pending
list
we're
actually
doing
pretty
well
trying
to
get
down
to
like
not
having
a
lot
of
things
here.
God
I
see
you're
on
the
call
I'm
gonna
badger
you
about
these
to
it.
A
E
B
C
Was
one
thing
there
was
an
old
action
item
on
the
old
Dropbox
paper
which
I
don't
know
if
I
don't
I,
don't
know
if
we're
using
the
project
board
as
our
main
thing
to
drive
us
now
or
not,
but
there
was
me,
I
was
just
doing.
They
did
do
right
where
the
meeting
started.
The
yeah
there's
an
old
pair
of
proposals
regarding
Alec
air
handler.
This
is
under
the
bullet
for
rustling
rust
issue.
C
C
Just
you
know
what
I
wrote
in
like
comment
summarizing
the
situation.
So
as
far
as
I
can
tell
former
analysis
still
stands,
I
think,
and
there
was
so
there
were
these
two
super
proposals.
One
was
to
stabilize
this
special
alla
khair
air
hand
or
attribute
for
marking
a
functioning,
the
air
handler
for
allocation
failures,
and
the
other
proposal
was
not
stabilized
that
actually
brother
just
automatically
inject
one.
That
panics
calls
the
panic
handler
and
that
way
we
can
avoid
stabilizing
that
attribute.
Instead,
just
people
can,
you
know,
start
using
the
Alec
raid
on
stable,
rust.
C
It's
just
that
they'll
be
forced
to
have
this
quality
injected
handler,
that's
what
they
get
for
the
time
being.
So
our
our
inclination
before
was
that
we
should
go
ahead
and
use
or
I
shouldn't
I,
don't
efficiency,
that's
our
information
or
was
also
the
lips
team
inclination,
but
whatever
happens,
it
seemed
like
everybody
was
sort
of
agreed
that
we
should
just
go
with
the
approach
that
auto
injected
a
panic
and
a
panic
one
that
calls
the
panic,
Handler
and
I
still
think.
We
should
do
that.
C
There
was
there
some
further
further
feedback
about
whether
we
would
do
both
proposals,
which
is
something
we
were
talking
about.
As
the
lang
team
I
think
in
Langdon
has
said,
we
could
in
apparently
decide
about
whether
I
do
both
these
proposals
as
sort
of
separate
questions,
and
there
was
some
immediate
feedback
when
we
said
that
saying
why
we
do
both
things.
C
You
only
need
one
of
these
things
and
I
think
the
right
resolution
there
is
that,
while
we
don't
need
both
of
these
things,
if
it's
very
important,
if,
if
we
actually
extend
the
panic
info,
that's
sped
to
the
panic
hammer
with
information
about
the
allocation
failure,
then
we
won't
need
to
adopt
both,
but
that
hasn't
been
done
yet
as
far
as
I
know
and
I
don't
know,
what's
involved
in
doing
making
that
change.
So
if
that
doesn't
happen
in
a
reasonable
mount
of
time,
then
we
still
might
need
to
consider
this
stabilizing
this.
A
C
Expressed
in
terms
of
expressiveness
in
terms
of
that
I
think
the
first
who
wants
to
actually
respond
to
an
allocation
failure.
They
with
information
about
like
what
the
allocation
was,
that
what
the
layout
for
it
was
the
current
panic,
except
if
we
inject
something
that
automatically
panics,
then
you
can't
write
a
panic
handler.
I,
don't
even
write
a
panic
handler
that
would
be
able
to
use
the
layout
info
because
it
doesn't
have
access
to
labo
from
the
panic
Handler
itself.
A
C
Currently,
to
be
clear,
currently
we
have
this
special
attribute
and
unlikely
to
have
this
special
attribute
that
you
can
write
your
own
handler
in
and
the
one
that's
in
standard
and
it
you
know,
does
end
up
panic
thing.
I
think
any
most
reasonable
implementations
will
a
reasonable
patient
would
panic
and
the
only
concern
and
I
have
is.
If
someone
for
some
reason
has
a
vested
interest
in
inspecting
the
information
about
the
failure
like
the
lately
allocate
feet
layout.
That
was
the
cause
of
the
failure.
Then
you
can't
express
that
using
the
panic,
Handler
strategy,
the.
A
C
C
But
either
way,
this
is
all
that
all
these
things
are
somewhat
like
it's
in
the
weeds
in
terms
of
what
really
matters,
I
think
look
what
the
average
crate
author
wants
is
just
the
ability
to
make
a
nose.
Sorry,
not
average
crate
off
the
average
node
stood
author
wants
is
the
little
things
that
live
out
at
unstable
rust
and
we
can
give
them
that
you
know
and
I
suspect,
most
don't
care
about
these
details
by.
C
Doing
that's
right
either
at
the
yes
six
six
seven
forty
one
gives
them
that
six,
six,
seven
four
zero
gives
an
ideally
questions.
You
know
how
to
do
it.
The
URLs,
the
line
team
earlier
decided.
We
should
just
we
should
do
six,
six,
seven,
four,
zero,
I'm,
sorry
I,
wouldn't
I!
Think
in
the
context
here,
sixty
seven
point:
zero
is
the
proposal
that
way
do
I
get
this
right.
Yeah
sixty
seven
point:
zero
is
the
oppose
Allah,
but
that
stabilizes
this
special
attribute
that
lets
you
make
your
own
handler.
C
So
yeah,
even
one
of
those
closes
work
we
earlier
decided.
We
should
do
six,
six,
seven,
four
one
because
it
has
less
of
a
unless
if
they
a
surface
API
surface
that
we
have
to
worry
about
in
terms
of
you
know,
just
maintaining
in
the
future.