►
From YouTube: 2020-11-02 Lang team triage
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.
A
I'm
gonna
start
by
looking
at
the
pending
proposals.
I
didn't
it
doesn't
look
like
we
have
any
new
pending
proposals.
A
So
we've
got
this,
which
has
an
fcp
that
I
think
is
completed
two
weeks
ago,
which
I
guess
we
can
just
close
it
at
this
point
and
type
says
cons
parameters
I
don't
recall,
but
I
think
we
had
a
pending
rfc
there
too.
Okay
just
finished.
I
believe
we
decided
to
close
this
right.
Yes,
so
I'm
gonna
go
ahead
and
do.
A
A
And
similarly,
here
I'm
just
going
to
close
this,
I
think
I'm
waiting
for.
A
Like
all
right,
very
good
in
terms
of
updates,
I
have
at
least
one
I
don't
know
if
other
people
have
any
so
in
terms
of
active
projects,
const
evaluation,
async
foundations-
I
don't
think
there's
I'm
not
I'm
not
caught
up
to
date
on
const
generics.
But
if
someone
is
in
this
meeting
and
wants
to
give
a
chat,
that's
fine
for
project
safe
transmute.
B
There
is
an
update
posted
and
I
think
it's
very
clear
on
what
has
changed
since
the
last
work.
The
whole
here
mechanism
has
been
dropped
and
the
simplified
into
just
a
trait
the
notion
being
this
doesn't
inherently
solve
the
problem
of
whether
you
want
to
be
able
to
privately
safe,
transmute
or
publicly
safe
transmute,
but
that's
not
a
problem
unique
to
safe
transmute,
that
is
in
general.
Sometimes
you
want
to
private
trade
impul,
and
sometimes
you
want
to
public
trade
impul
and
one
of
these
days
we
should
solve
that.
A
Okay,
muckable
doesn't
seem
like
it
is
that
a
working
title.
B
C
Yeah,
that's
the
idea,
and
I
I
posted
in
the
zulu,
but
giving
it
a
weird
name
is
good,
because
any
sort
of
normal
sounding
name
would
probably
promise
to
people
as
a
preconceived
notion,
something
that
it
doesn't
actually
promise
and
so
giving
it.
A
weird
name
forces
them
to
look
in
the
documentation
to
see
exactly
what
this
trade
is
about,
which
is
probably
good.
With
this
sort
of
thing.
A
Okay,
I
find
that
somewhat
persuasive,
somewhat
unpersuasive,
but
yeah
the
idea
that
weird
names
will
force
people
to
look
instead
of
guessing.
I'm
never
not
exactly
sure,
but
it
might
be
true,
the
but
okay
leaving
the
name
inside
I'm
in
favor
of
this
shift.
I
think
the
neglect
stability-
that's
fine.
A
A
Okay,
so
the
thing
I
wanted
to
note
was-
or
are
there
any
more
comments
on
project
safe
transmute?
Are
we
all
set.
E
A
Okay,
so
I
wanted
to
bring
up
the
never
type
stabilization
because
we
hit
an
interesting,
but
we
kind
of
got
the
lint
up
and
working,
but
we
encountered
these
false
warnings,
some
of
which
we
knew
about
before,
but
some
of
which
I
didn't.
This
was
one
that
I
did
know
about
before
and
you
can
debate
whether
this
is
the
lint
working
as
expected
or
what
so.
What
happens
here
in
this
call
to
partners.
A
So
this
this
line
of
code
gets
a
warning
and
with
this
lint,
and
the
reason
is
that
this
type
t
is
unconstrained.
It
appears
in
the
return
type
and
the
reason
it's
unconstrained
is
that
basically
that's
the
okay
type.
This
is
essentially
a
result.
That's
the
ok
type
and
this
function
never
generates
okay,
so
it
can
be
literally
any
type.
A
And
if
you
didn't
have
the
question
mark,
you
would
actually
get
a
compilation
error,
because
it's
unconstrained,
but
because
of
some
weirdness
in
how
question
is
de-sugared,
it
winds
up
getting
unified
with
fallback
a
fallback
variable,
and
so
it
falls
back
to
never
type
and
that's
like
changing
under
this
lint.
So
it's
not
wrong
like
it
used
to
fall
back
to
unit
and
now
it
would
fall
back
to
never.
A
Are
you
all
still
there
yeah?
Okay,
then
the
on
the
other
question
is
or
that's
one
pattern,
that's
the
one
I
already
knew
about
and
we've
seen
before,
and
I
think
it's
kind
of
potentially
good
to
get
a
lint
here
because,
as
I
said,
this
would
be
a
compilation,
error
buff
for
the
question
mark,
but
another
one
pattern
that
I
was
less
happy
with.
Is
this
function,
and
what
happens
here
is
that
this
closure
winds
up.
A
So
I
think
this
may
be
well
we'll
have
to
keep
iterating
a
little
and
maybe
like
we
can
refine
the
analysis
to
consider
a
function
like
this
dead,
but
it's
not
very
clear
to
me
yet.
So
those
are
two
of
the
cases
that
the
current
analysis
flags
that
I
think
it
shouldn't
I
believe.
A
Well,
actually,
I
realized
we
didn't
retest
this,
that
it
does
also
flag
the
case
we're
looking
for
which
is
this
case,
but
yeah,
so
we're
working
with
it.
One
thing
I
wanted
to
bring
up
is:
does
I
think
it's
my
expectation
that
this
lint
will
just
stay
on
all
the
time
that
it's
basically
warning
against?
A
E
A
Yeah,
that
seems
plausible
it's
hard
to
tell
for
now.
What
we're
going
to
do,
I
guess
is
the
next
step.
Is
we
annotated
these
code
with
explicit
type
annotations,
which
makes
the
link
go
away
and
we
will,
I
think,
do
a
crater
run
to
try
to
get
some
sense
of
how
much
code
is
affected.
If
there
are
other
patterns
we
haven't
seen.
E
Actually,
that's
a
good
point
that
this
would
assuming
that
this
lint
is
successful.
It
would
lead
shortly
to
stabilization
of
never
and
if
we
have
a
stable,
never
then
the
way
to
silence
the
lint
is
to
annotate
a
explicit
exclamation
mark
type
somewhere,
and
that
seems
like
a
good
thing.
If
you
were
inferring
an
exclamation
mark
type
somewhere,
that's
non-obvious.
A
True,
I
would
like
to
at
least
this
case.
I
don't
know
I
have
to
think
about
it,
but
that
case
really
calls
me
because
it's
like
it's
just
would
be
nice
if
it
worked.
I
don't
know
not
sure
why
it
calls
me
so
much.
I
guess
just
because
it's
it's
literally
doing
what
it's
it's
just
returning
the
type
of
disclosure
like
everything
is
working
as
designed,
but
we're
getting
a
lint
warning
so.
A
All
right
moving
on
are
there
any
updates
for
inline
assembly
or
instruction
set?
A
A
Very
good
this
in
terms
of
meetings
we
have
this
meeting
proposed
rsc
2580.
For
this
wednesday
I
did
do
a
write-up,
although
I
have
to
update
it
with
a
clearer
point
of
what
the
agenda
is,
but
basically
the
plan
is
going
to
be
to.
I
think
it's
linked
here.
I
guess
not.
A
A
The
other
thing
I
want
to
say
is
from
the
backlog
bonanza.
A
I
said
I
would
go
and
assign
things
to
people,
and
I
didn't,
but
I
will
do
that
or
people
can
just
go
pick
them
up
if
they
want.
A
All
right,
this
is
the
pr
that
we're
going
to
skip
over
this.
This
is
the
mark,
is
working
on
implementation,
so
we'll
go
down
to
nominated
pr's
got
a
lot
of
them
or
issues.
So.
Operators
in
patterns
have
incorrect
priorities,
rough
48501,
scott,
you
nominated
it.
Do
you
want
to
talk
about
it.
E
E
A
A
E
A
A
A
B
I'm
saying
the
version
in
the
expression
should
almost
never
type
check
yeah
that
doesn't,
and
you
don't
really
have
to
worry
about
that
case.
Well,
you
might
actually
because
it
would
type
check
if
you
had
an
open
bound
like
ampersand,
zero
dot.
Dot
could
be
a
range
from
where
the
lower
bound
is
a
reference.
F
A
E
F
Yeah,
sorry
to
be
pedantic
here,
the
bullet
of
presence
for
dot
dot
and
dotted
english
dimensional
context.
That
implies
that,
if
dot
equals
doesn't
match
today,
the
precedence
in
these
two
like
it
doesn't
actually
have
these
different,
two
behaviors,
then
dot
dot
equals
should
be
the
changes
to
be
more
like
dot
dot
and
have
the
context
dependent,
behavior
right.
A
A
F
A
A
A
E
E
F
A
A
There
were
some
comments
around
adding
more
aggressive
lints,
like
this
comment
by
dixie,
suggesting
that
we
should
replace,
suggest
replacing
under
four
with
open-ended
patterns
in
order
to
help
people
see,
if
that's,
not
the
semantics
that
they
actually
wanted.
A
E
E
E
A
This
has
been
fcp
merged
since
september
by
scott.
Also,
it
says,
as
it
says
right
here.
It
basically
makes
the
unsafe
codelind
also
complain
about
these
link
attributes
because
they
can
cause
one
unsafe
code
to
they
can
cause
problems
where
you
like,
overwrite
main
or
whatever.
There
was
a
oops.
Didn't
I
have
a
nice.
Oh
here
we
go,
it
was
a
crater
run
done.
It
has
relatively
limited
impact,
one
regression.
I
guess
meaning
this
of
course,
since
this
is
a
lint,
it
won't
break
any
dependencies
anyway.
But
this
affects
not
that
much
code.
A
A
A
All
right
switch
mutable,
borrow
reservation
conflict,
so
this
is
the.
A
A
They
don't
have
the
then
he
wound
up
like
pulling
back
to
so.
The
two
phase
borrows
basically
are
kind
of
like
a
raw
pointer,
which
means
you
get
less
optimization,
but
it
also
means
they're
compatible
with
this
pattern,
and
we
did
do
some.
Crater
runs
that
found
a
fair
amount
of
impact.
117
crates
would
be
affected
by
turning
this
to
deny
by
default.
A
B
A
A
G
A
Yeah,
okay,
I'm
not
sure
how
much
I
did
in
terms
of
that.
In
fact,
all
right,
maybe
somebody
can.
A
Okay,
so
at
the
last
meeting
we
had
decided
to
revert
back.
If
you
remember
we
had
this,
we
thought
we
should
revert
back
to
the
older
pattern.
I
left
the
comment:
no,
no!
No!
No!
No!
No,
because
there
was
some
regressions,
but
then
I
started
digging
a
little
more
into
this
and
I
just
wanted
to
to
call
up
and
show
people
why
petrochenkov
had
instituted
this
rule.
A
What
happens
is
this
code
basically
is
not
expected
to
work,
but
it
does
or
you
might
not
expect
it
to
work,
but
it
does
and
what
happens
is
first,
it
imports
all
the
names
from
foo
through
this
glob
at
glob,
precedence
which
is
lower,
so
it
imports
foo
bar
right,
then,
at
that
point
these
imports
are
able
to
trigger
and
this
imports
bar
bar,
which
is
fubar
bar
and
that
because
that's
an
explicit
import
that
overrides
the
precedence
of
the
glob.
A
I
guess
this
doesn't
actually
use
it,
but
so
that's
a
little
weird
and
the
property
that
this
violates
that
I
kind
of
had
in
my
head
is
like,
at
the
end
of
resolution,
you're
able
to
say
what
each
name
in
each
scope
maps
to
and
then
kind
of
re
recheck
all
the
paths
to
make
sure
that
they
still
match
so
like
here.
If
we
said
okay
bar
maps
to
fubar
bar,
then
this
would
be
an
error
because
you
can't
resolve
bar
bar
inside
of
there's
no
third
level
of
hardness
so
to
speak.
A
But
in
that's
what
people
say
or
that's
what
I
thought
of
as
time
traveling
but,
as
petrochenkov
pointed
called
it
kind
of
import
resolution
as
inference.
I
think
that's
what
what
he
was
referring
to
so
yeah.
So
that's
the
property
that
we're
losing
and
instead
we're
having
this
notion
where,
like
you,
have
to
take
into
account
kind
of
when
we
resolved
it.
What
you
knew
at
that
time.
A
Which
is
a
little
wacky,
so
this
bar
and
this
bar
are
not
the
same
bar
in
other
words,
but
it
is
respecting
this
petroshenko
called
it
causality
where,
like
there's
only
one
bar,
they
could
have
been
to
make
it
make
sense,
and
one
way
I
thought
about
this
if
we
did
want
to
accept
it,
is
that
there's
again
a
sort
of
elaboration
step
happening
here
where
this
is
like
a
because
these
these
these
uses
are
kind
of
shorthand
form
and
the
more
explicit
form
would
would
include
like
coal
and
colon
foo
colombar,
I
guess
or
self
colon
colon
and
things
like
that.
A
But
I
don't
know
it's
a
bit
of
a
hand,
wavy
justification,
so
I
guess
the
question
is:
do
we
mind
giving
up
on
that
property
in
exchange?
For
continuing
I
mean
we
all
want
to
break
code,
so
maybe
we
don't
have
much
choice,
but
I
wanted
to
bring
it
to
everyone's
attention.
A
B
B
It
seems
like
we
would
want
to
avoid
making
a
change
that
will
create
this
level
of
regression.
I'm
trying
to
figure
out
if
this
is
a
just.
A
trade-off
of
this
is
difficult,
or
if
this
is
a
trade-off
of
we're
going
to
break
one
set
of
things
or
another
set
of
things,
and
it
seems
like
it's
more.
The
former.
A
G
I
still
feel
inclined
to
say
that
like
if
we
were
to
break
something
here
and
I'm
not
entirely
objecting
like
it
does
feel
like
there
is
sort
of
confusion,
there's
potential
confusion
here
we
would
want
to
do
some
rendition
of
boundary
and
in
which
case,
we
sort
of
have
our
hands
free
to
do
so.
At
a
later
point,.
A
Yeah,
I'm
somewhat
inclined
to
agree,
and
I
want
to
have
a
nice
model,
but
I'm
also
not
like
not
sure
that
this
can't
lead
to
a
nice
model.
For
one
thing
in
seconds:
what
works
we
can
say
we
can
move,
we
can
try
to
do
it
or
in
some
disciplined
way.
We
have
a
model
that
we
want
to
move
through,
like.
D
A
F
F
A
A
A
I
do
think
I'm
wondering
if
there's
I
guess
we
can
I'll
talk
to
captain
sinclair,
if
there's
some
possibility
of
ambiguity
here
where,
if
something
could
have
resolved
either
with
the
glob
name
or
with
the
fancier
name.
Hopefully
we
catch
that
case,
but.
A
A
All
right
next,
one
built-in
implementations
have
default
so
what's
being
proposed
here.
Actually
I
won't
jump
over
all
this,
since
I
kind
of
wrote
it
here
is
that
for
for
zero
capture
closures
and
for
function
top
level
like
function
items
the
special
unique
types
that
each
of
them
have
associated
with
them.
A
For
those
two
cases
we
could
make
those
types
implement
default
and
the
motivation
is
that
it
would
be
nice
to
be
able
to
write
a
generic
wrapper
like
this,
that
wraps
those
the
wraps
a
function
like
that
and
does
something
before
and
after
it
gets
called
and
it.
If
you
want
to
do
that
and
use
you
can
do
that
with
a
closure,
but
then
you're
taking
in
well.
A
You
can't
write
it
generically
and
you're
taking
in
like
or
you're
taking
a
function
pointer
or
something,
and
then
you
have
state
if
you
just
want
a
plain
function
pointer.
This
is
rather
more
convenient,
at
least
that's
the
argument,
and
although
I'm
not
sure
how.
I
A
I
The
way
you
might
expect
and
so
standalone
functions
are
the
only
option
and
I'm
able
to
call
it
because
I
do
actually
have
an
instance
of
the
closure
that's
being
passed
in,
but
I
don't
have
access
to
it
at
the
point
where
the
thunk
is
needed
yeah,
so
I
basically
get
the
type
from
when
I
have
the
closure
and
then
that
type
gets
type
erased
later
on.
Does
that
make
sense.
A
A
A
There
was
some
proposals
for
alternatives
like
using
the
function
pointer
trait,
but
I
don't
think
that
works,
because
that
was
that
trait
was
meant
to
be
implemented,
not
just
for
zero
size
things
they
can
implement
default,
but
also
a
bunch
of
other
things.
You
could
do
some
more
general
trade,
though,
if
you
want
to.
A
I
E
A
And
there's
a
case
to
be
made
so
closures,
because
closures
are
generated
by
expressions
right,
there's
a
case
to
be
made.
That's
like
well,
okay,
even
if
they
don't
have
any
up
fires.
Maybe
still
you
wouldn't
expect
this
closure
to
exist
unless
some
state
had
been
entered
or
something
like
that,
but
I'm
not
sure.
A
If
you
could
even
get
the
closures
type
without
that,
but
like
I'm
imagining
the
closure
only
has
side
effects.
Maybe
it
prints
something
to
to
the
terminal,
but
you
only
want
to
print
that
if
a
certain
thing
has
happened
and
maybe
then
you
would
create
the
closure
and
maybe
the
using
type
inference
tricks
or
whatever
you
can
kind
of
instantiate
the
closure
outside
of
the
outside
of
that.
If
this
way
that's
sort
of
the
analogous
case
right,
although
it
won't
panic,
it
may
do
what
you
don't
expect.
G
Yeah,
I
think
sort
of
my
thoughts
on
on
the
pr
thread
were
sort
of
similar.
That
default.
Just
sort
of
feels
like
it
to
me
default
is
not
what
I
think
of
as
new.
G
If
that
makes
sense
like
it's,
not
the
zero
type
constructor
it's
different
like
it
implies
something
more,
and
I
think
that
in
general,
it's
not
what
I
think
of
as
something
closer
is
having,
but
I
think
that
sort
of
depends
on
how
you
think
about
closures,
if
you
think
of
them
as
just
sort
of
a
special
struct
with
some
special
impulse,
then
that
sort
of
falls
away
in
some
sense.
E
A
E
I
think
it's
more
obvious
to
me
that
it
would
be
reasonable
for
function,
types
to
be
to
automatically
be
safe,
transmute
to
and
into
and
from
unit
or
some
other
canonical
zst.
H
I
don't
know
and
then
shouldn't
function,
types
transmit
to.
E
A
A
E
Yeah
that
summoning
instances
from
the
ether
is
not
necessarily
something
that
makes
sense
here
that
the
same
smuggling
smuggling
it
through
some
other
storage
that
allows
that
allows
for
the
representation
of
the
same
number
of
valid
states
would
be
okay,
but
that
creating
it
from
nothing
is
not
necessarily
okay,
even
though
it
has
only
one
valid
state,
which
is
the
same
number
of
states
as
nothing.
B
Yeah
this
seems
like
it's
a
workaround
for
like
it
only
works
for
specific
types
of
closures
that
don't
capture
anything
for
obvious
reasons.
But
if
you
have
a
closure
that
doesn't
capture
anything,
we
already
have
a
way
to
turn
that
into
a
function.
Pointer,
I'm
wondering
is
there
some
way
that
we
could?
D
Okay,
next
one.
A
I
think
a
good
lesson
for
us
layout
things
come
up.
This
comes
up,
but
the
problem
being
here
we
have
a
type
that
is
empty
here
we
have
repper
transparent.
This
is
only
allowed
if
these
things
are
all
onesiest
are
all
alignment
one
zero
size
types,
these
things
being
everything
other
than
the
main
value.
A
A
It's
a
problem:
it's
annoying
certainly
related
to
the
stable
layout.
It's
transmute
questions
I
guess
but
related,
but
different.
E
Yeah
my
my
first
thought
here
of
why
I
explicitly
filed
this
mentioning
non-exhaustive
is
that
it
seems
like
we
should
clearly
not
be
doing
this
with
non-exhaustive
and
then,
as
we
get
safe
transmute.
The
conversation
about
like
the
muckable
trait
or
some
variety
of
things
like
that
say
to
me,
would
give
me
the
oh.
If
you
said
it's
muckable
and
it's
a
zst,
then
you'd
be
allowed
to
use
it
as
a
one
zst,
because
muckable
prevents
you
from
changing
that,
but
otherwise
we'd
just
not
allow
this
in
river,
transparent.
E
A
E
No
because
if
you
add
one
private
field
to
it,
you
can
get
sort
of
non-exhaustive
that
avoids
all
of
those
patterns
and
creation
things.
Basically,
the
old.
E
A
Undesirable,
but
if
you
have
a
private
zero
sized
field,
you
can
get
a
similar
pattern
one
so
because,
possibly
we
could
add
a
check
that
says,
like
kind
of
adding
the
check.
Goes,
it's
really
getting
in
exactly
the
same
issues
as
city
transmute
applause.
I
believe
we
could
add
some
kind
of
check
based
on.
E
A
E
A
H
A
H
Think
that
it
would
be
bad
for
that
to
be
the
incorrect,
like
an
increase
like
meaningfully
incorrect
right
like
you
need
to
use
the
non-exhaustive
attribute,
or
you
have
not
correctly
marked
your
self-december
for
the
future.
A
E
E
A
A
E
A
E
A
I
mean
there's
a
fine
there's,
not
much
difference.
I
would
like.
If
we
wanted,
if
we're
talking
about
exploring,
then
you
can
just
start
with
a
lint
and
turn
it
into
a
future
compatibility
warning
before
we
landed,
but
okay,
basically
category
one.
A
One
okay,
I
do
think
the
non-exhaustive
case
is
pretty
clear-cut,
even
though
I
also
agree
with
boats
that
it
would
be
good
to
cover
more
than
just
that
all
right.
Well
we're
about
out
of
time
the
last
yeah.
I
guess
we
have
time
almost
made
it.
People
want
to
weigh
in
on
renaming
overlapping
patterns
or
applying
unused
dot
comments
to
inner
items.