►
From YouTube: Lang Team Triage 2020.06.22
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
My
god,
my
computer's
nearly
slow.
This
idea
may
not
work
out
okay.
What
I
do
why
computer
or
you
like
this-
let's
see
if
disabling
the
video,
helps
make
this
horrible.
Okay,
first
of
all
any
new
stuff.
Here
we
got
review
safe
transmedia.
Now
that's
a
meeting
proposal.
That's
already
been
scheduled
all
right.
So
let's
take
a
look
here.
I'm
supposed
to
be
doing
this,
they
did
that
I'm
supposed
to
be
reviewing
active
items,
meter
change,
proposals,
meetings,
okay,
so.
A
A
A
A
The
my
mind
is
once
this
is
merged,
I
mean
in
the
old
model.
We
would
create
a
tracking
issue,
then
we
would
just
sort
of
go
off
our
radar
at
that
point.
Right
and
I've
been
wanting
us
to
move
to
a
model
that
involves
a
little
more
follow-through,
but
I
also
see
four
smaller
issues
like
this.
There
might
be
some
appeal
to
being
able
to
say:
okay,
we
let
this
leg
team
itself
doesn't
necessarily
need
to
be
too
involved
in
tracking
this,
though,
I
think,
if
it's
not
us
would
be
I.
A
Yeah
so
I
think
that's
a
good
I
agree
with
that.
I,
don't
know
that
I
have
two
thoughts.
I
guess,
I,
think
the
right
place
to
start
is
that
we
should
have
a
group
and
yeah.
Maybe
that
group
is
mostly
you
know
one
person
doing
implementation
where
but
I'm
wondering
about
when
it
gets
to
this
stage,
which
is
let's
zoom
in
to
us
relatively
quickly
where
it's
ready
to
be
like
it's
been
implemented,
and
we
just
need
to
sort
of
wait
until
we're
ready
to
stabilize
it
at
some
point.
A
Let's
get
to
that
point
first
and
then
we'll
worry
about
it.
I
guess
we
could
bring
it
up
for
inline
assembly,
but
so
any
updates
I
knew
these
other
items.
Creating
a
lint
I.
Don't
think,
there's
bits
here,
it's
stuff
that
I
did
send
some
messages
out
to
some
possible
people
around
doing
the
implementation
work
there.
I
haven't
really
heard
back
yet.
A
A
A
B
Couple
of
updates
yes,
so
the
change
to
allow
multiple
logical
lines
of
inline
assembly
has
been
merged
into
nightly
now,
and
the
blog
posts
example
has
been
updated
so
that
people
who
use
that
as
a
reference
will
have
that
available.
So
this
means
that
people
will
be
able
to
write
code
that
rust
format
can
properly
invent.
A
B
Not
have
to
worry
about
inserting
or
removing
white
space
inside
of
a
quoted
string,
which
would
be
dangerous,
so
should
provide
substantial
formatting
improvements
over
either
the
old
inline
assembly
style
or
what
people
typically
do
for
CN
line
assembly,
so
that
has
gone
in.
The
change
has
been
made
to
the
RFC
and
to
the
blog
post
and
at
this
point,
I
think
that
the
next
step
is
to
finish
checking
off
on
the
RFC.
B
B
B
C
B
B
B
A
A
C
B
My
part
at
least
I
would
say:
I
would
rather
not
have.
Some
ABI
is
default
to
unwind
and
some
ABI
is
default
to
no
unwind.
If
we're
going
to
say
that
B
default
to
no
unwind
and
we
have
a
the
unwind
ABI,
then
I
think
we
should
have
a
standard
call
unlock
unwind
at
a
this
call
unwind
and
maybe
even
a
system
online.
If
we
want
to
have
unwind
allowed
by
default
and
we
could
have
a
steno,
unwind
and
optionally,
a
standard
call,
no
unwind
and
so
on.
A
B
A
A
A
B
See
how
it
would
help,
but
you
still
have
to
have
individual
support
on
an
ABI.
They
ABI
basis
for
what
unwind
means
in
that
ABI.
So
one
thought,
though
we
did
have
an
unstable
concept
of
unwind
allowed
and
we
never
stabilized
it,
but
we
did
have
an
attribute
for
it
and
it's
used
in
the
standard
library
and
potentially
an
other
code
that
is
currently
unstable.
Could
we
add
a
lint
that
detects
if
you
have
a
extern,
some
ABI
that
doesn't
allow
online,
that
with
a
function,
tagged
as
unwind
allowed
and
say
hey?
B
A
A
A
Rather
so
yeah
so
I
think
we'd
give
it.
We
give
a
limb.
We'd
say
you
should
be
using
the
SI
unwind
ABI
now
or
whatever,
and
we
should
well,
but
it
should
still
work
right
like
we
should
convert
to
the
C,
unwind
ABI
and
warned
we're
doing
so,
and
it's
have
to
be
going
to
be
removed
and
the
ban
should
explicitly
adopt
the
C
unwind
API
in
order
to
be
on
the
stable
path
that
sound
right.
That.
A
A
A
A
E
A
A
A
A
A
A
A
A
Target
feed
the
new
target
feature
1.1
design,
so
the
old
target
feature
made
every
function
that
used
a
target
feature
specification
unsafe.
When
the
new
version
you
can
declare
the
function
is
safe
and
it's
just
unsafe
wallet
from
a
context
in
which
you
don't
have
the
same
target
feature
set
nice,
but
we
overlooked
something
which
is
that
these
functions
at
least
today
implement
the
offend
traits.
A
A
The
so
petrochine
calls
had
a
proposal
which
said
you
should
always
have
to
write
unsafe
function,
but
we
should
modify
the
unsafety
checker.
So
if
you're
calling
this
function
from
a
context,
right
target
features
are
in
scope,
then
you
don't
have
to
write
unsafe.
Does
that
make
sense?
I,
don't
think
that's
a
good
solution
is.
C
B
A
And
so
another
option
would
have
been
to
make
it
so
that
it
would
be
unsafe
to
reference
this
function,
so
this
line
would
be
unsafe
because
we
not
have
the
right
target
feature
set.
However,
that
would
be
kind
of
inconsistent
because
already
today
unstable
you
can
do
this,
where
you
declare
the
function
as
unsafe
and
you
reference
it,
but
you
never
call
it
for
this
functions
dead
code
stable,
yes,
sir
you're,
stable,
I.
A
A
A
B
I
guess
it
was
in
this
tab.
So
how
do
you,
if
that's
the
case,
then
how
is
it
you
can
so
to
margot
feature
one
one
breaks
this
no
target.
A
B
Is
a
hole
here
because
we
would
accept
it
I
see
but
target
feature
one
one
is
nightly
only
so.
If
we
change
this
behavior,
it
will
not
be
breaking
any
stability
guarantees
exactly
unstable.
We
don't
accept
this
okay,
so
then
the
fast
fix
to
this
would
be
to
just
make
sure
that
target
feature
functions
cannot
be
used
in
fun.
B
At
the
point
where
you
would
turn
them
into
an
implementation
of
fun
like
use
their
implementation
of
fun,
then
you
have
to
either
be
in
an
unsafe
block,
or
you
must
be
in
a
function.
That
would
also
be
permitted
to
call
that
function
without
an
unsafe
block,
meaning
one
that
uses
the
same
target
feature
so.
B
C
B
C
C
A
B
A
C
C
The
idea
that
you
put
forth
earlier
about
having
it
be
unsafe
to
reference
the
target
feature
function
rather
than
really
call
it.
You
know
you
wrote
an
example
down
why
that
would
be
someone
consistent
given
you
know,
you're
giving
some
that
already
compiles
today,
but
the
example
you
gave
up
since
I
reckon
Palace
today
doesn't
seem
like
a
really
great
motivation
right.
You
didn't
it
doesn't
listen.
I,
look
like
over,
of
course,
that
has
to
work.
I
would
be
just
as
happy
like
making
that
feature
incompatible
right
and
make
sure
you
not
attract
words
thing.
A
Two
different
proposals,
so,
okay,
the
fast
fix
I
should
add
just
to
cut
to
the
chase,
is
actually
implemented
in
a
PR
okay,
which
says
I
mean
basically
what
it
is
is
not
all
F
ends
that
you
can
write,
implement
the
FN
traits,
that's
already
true,
unsafe
functions,
don't
ones
with
different
ABI
is
don't,
and
now
we
include
in
list
also
turned
Avengers,
but
that's
a
little
bit
different
than
the
proposal
that
I
was
saying
about
unsafe
to
make
a
function
pointer.
A
Yeah
and
so
I
guess
or
unsafe,
to
make
it
to
reference
without
calling,
and
so
it
feel,
like
you
were
saying
plausibly,
we
could
back
like
make
us
focus
on
the
sticks
to
so
that
this
example
here,
which
uses
the
unsafe
keyword.
We
could
make
this
example
also
an
error,
and
we
could,
but
it
seems,
in
my
opinion,
a
more
intrusive
fix
than
the
quote
unquote
fast
fix,
because
the
fast
fix,
like
I,
said,
there's
already
like
a
variety
of
conditions
in
which
a
function.
A
A
Whereas
prevent
like
it
would
be
sort
of
unnatural
and
the
compiler
to
say
you
can
you
can
have
an
expression
use
a
VX,
but
it
has
to
be
called
like
only
if
it's
within
inside,
within
the
call
I
can't
I
can't
refactor
code
that
was
previously
doing
this.
I
can't
refactor
it
to
this.
It's
alright
to
this.
A
B
One
other
thought,
by
the
way,
the
more
ideal
proposal
that
I
was
suggesting
I'm,
not
suggesting
that
it's
I
don't
know
how
trivial
this
would
be.
Imagine
for
a
moment
instead
of
actually
like
just
having
the
function,
type
implement
those
fun
traits
and
therefore
you
can
pass
it
anywhere.
You
could
pass
that
fun.
Imagine
if
you
just
had
a
function
that
was
unsafe,
that
returned
that
trait,
as
in
you
return.
B
B
So
the
premise
would
be
that
the
askin
function
is
something
you
could
call
that
will
return
the
function.
You
call
it
on
as
an
implementer
of
the
thin
traits
and
that
function
could
itself
use
target
feature
1/1,
which
means
that
you
can
only
call
it
either
in
an
unsafe
block
or
code
that
is
using
that
feature.
So
it's
a
difference
between
this
and
the
ideal
solution.
Is
that
you
could
we
wouldn't
want
to
have
to
call
dot
as
fun,
but
this
would
be
a
thing
that
I
know
we
can
implement
today.
A
B
Kind
of
the
latter,
the
idea
would
be
that
a
target
function,
a
target
feature.
One
one
function
could
implement
this
trait.
That
provides
a
target
feature
as
fun
trait
function.
I'm
not
saying
we
would
actually
do
this
in
stable,
I'm
saying
this
is
a
pattern
that
suggests
how
we
could
implement
the
ideal
case
and
then
just
treat
it
that
way
inside
the
compiler.
A
I
guess
I
would
say
yes
and
in
other
words
yes,
I,
think
that's
true
I
think
it's
a
change
that
would
require
like
it
feels
a
little
out
of
scope
for
like
a
triage
me,
it
feels
like
a
more
of
an
RFC
worthy
topic,
but
in
terms
of
the
ideal,
I
guess
in
terms
of
these.
Both
these
ideal
features.
Certainly
this
latter
one
that
doesn't
seem
totally
implausible
to
me.
It's
the
kind
of
thing
where.
A
Both
of
these
I
mean
I
can
imagine
how
we
would
implement
them,
but
I
would
just
want
to
think
over
that,
especially
the
unsafe
case.
I,
don't
know
that
that
seems
like
okay,
the
idea
of
giving
of
having
unsafe
in
bowls
or
conditional
impulse
that
require
these
sort
of
an
basically
conditional
impulse
with
with
where
clauses
that
are
more
like
the
environment
they're
being
used
from
then
the
anything
that
was
like
and
that
that's
interesting
idea,
but
I'd
rather
explore
it.
I'm.
B
A
My
mind
it
be
something
to
rule
out
of
scope
for
the
project
group
and
weave
on
the
design
table
for
later,
like
I.
Just
it
doesn't
seem
all
that
it
seems
like
a
pretty
edge
case,
in
my
view,
just
I
guess
what
I'm
trying
to
say,
especially
given
that
you
can,
you
can
sidestep
it
with
the
closure
already
so
like.
E
B
I
see
I
mean
that
if
the
compiler
were
smart
enough,
it
could
just
say
that
the
closure
doesn't
need
to
exist
and
can
just
be.
The
function
also
use
a
VX.
A
Yeah
it
could,
as
it
is,
the
compiler
is
going
to
so
wait.
Why
did
this
I'm
actually
a
little
surprised?
Oh,
that's
interesting.
I
take
back
what
I
said:
I'm,
not
sure
if
this
is
actually
a
bit
expected,
behavior
I,
guess
that
we're
checking
we're
not
inheriting
this
target
feature
in
the
closures
that
might
be.
C
C
A
B
A
B
A
I
mean
you
could
imagine
it
being
part
of
the
API
or
something
I,
don't
know
how
do
I
eat
it.
It's
not
part
of
the
type
today
so
kind
of
can't
be
without
some
challenges,
but
like
there's
stable
code
that
has
coerces
many
things
to
unsafe
functions
that
I
guess
I,
wouldn't
I,
don't
think
it
I
don't
know,
maybe
there's
a
model
where
it
makes
sense.
But
if
you're,
if
we're
saying
that
target
features
are
more
like
determine
the
set
of
things
available
to
doing
not
something
you're
gonna
attract
on
a
fine-grained
basis.
A
A
All
right,
I
will
write
up
the
comment
about
this,
but
I
guess
my
proposal
needed.
We
accept
this
PR
to
close
the
soundness
hole,
but
we
also
fix
the
relationship
with
closures,
which
is
probably
just
a
bug
and
then
once
we
fix
those
two
things
now
it's
you
can
work
around
this
problem.
If
you
consider
it
a
real
problem,
using
closures,
I,
don't
think
it'll
happen
that
often
in
practice
and
if
we
did
find
it
was
happening
often
in
practice,
then
we
have
room
to
to
grow.
A
A
A
A
A
B
A
A
A
A
B
A
A
It
is
kind
of
confusing
there
is
a
report
here
that
tries
to
explain
it.
Okay
I
took
some
I
guess
it
was
adjusted.
The
initial
version
of
the
report
I
found
a
little
misleading
in
my
opinion,
but
the
short
version
is
the
lexer
doesn't
change,
but
we
have
new
kinds
of
tokens.
They
represent
the
pieces
of
Florida
number
and
the
parser
when
it
gets
the
parser
will
kind
of
break
down
if
it
gets
a
floating-point
token
it'll
break
it
down
into
smaller
tokens,
which
is
sort
of
internal
to
how
the
parser
works.
A
So
that
means
that
side
effect
of
this
is
that
procedural
macros
that
are
attempting
to
parse
trusts
also
have
to
have
that
logic.
Inside
on
the
plus
side.
It
doesn't
break
anything,
and
apparently
we
already
do
that
in
some
other
cases
and
I
think
as
this
last
line
alludes
to-
or
in
this
particular
case
we
already
do,
it
have
left
shift
its
being
broken
into
two
individual
tokens
and.
A
And
like
sin,
for
example,
I
get
against
must
already
a
confident
and
and
I
guess.
The
idea
is
that
we
can,
when
we're
kind
of
happy
with
where
we
are,
we
can
introduce
a
better
or
an
alternative,
lexer
API.
That
gives
me
more
fine-grained
tokens
and
I
guess
keep
the
existing
one,
probably,
which
would
build
on
the
we
should
probably
do
have
like
put
bosses
some
pass
that
lump
together.
Some
of
those
tokens
into
compounds
organs.