►
From YouTube: 2021-03-03 Lang Team Planning 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,
sorry,
we
missed
the
first
couple
sections,
those
of
you
who
are
watching
where
we
talked
about
type
description,
async,
foundations
and
constable,
but
on
we
go
never
tight
nothing's
happened
here.
However,
I
asked
mark
if
he
would
look
into
it
a
little
bit,
because
there
might
be
some
chance
that
we
want
to
tie
something
to
the
audition,
and
that
is
somewhat
time
sensitive
and
mark,
I
think,
is
still
game
to
do.
That
is
that
true
mark.
B
A
I
think
is
that
it
seems
like
never
type
is
becoming
increasingly.
I
don't
know
it's
always
been
useful,
but
I
think
it
was
the
tri
trait
that
pushed
me
over
the
edge
to
like
really
wanting
it
to
be
done
now,
because
it
was
such
a
nice
elegant
use
of
it
in
residuals.
A
So
I'm
still
hoping
we'll
get
this
done.
I
still
think
I
prefer
my
proposal
of
fallback.
That
depends
on
context.
A
C
I
would
love
to
have
it.
I'm
also
scared
of
it,
because
the
one
breaking
change
that
I
wasn't
expecting
for
my
try
rfc
was
something
using
never
tight.
C
A
So
constant
generics
we've
been
having
weekly
meetings
looking
at
the
implementation,
and
so
oh,
I
should
add,
min
con's
generics
is
stable
or
almost
stable.
You
hit
beta
right.
A
And
we've
been
having
weekly
meetings
and
looking
at
what
we
can
do
and
some
of
the
implementation
challenges
going
forward
and
one
of
the
things
that
came
up
this
week
was
basically
various
small
extensions.
We
can
do
to
go
past
men
con
generic
slightly.
I
made
a
little
list
here
of
the
things
that
lcn
arms
was
citing,
so
one
of
them
is
right
now,
there's
a
limitation
that
says
has
to
be
lifetimes
types
constants.
A
We
could
lift
that
so
that
you
can
have
lifetimes
and
then
types
and
constants
intermixed,
I'm
in
favor,
I'm
actually
in
favor
of
generally
removing
all
these
limitations.
You
know
when
we
get
around
to
it.
It's
a
high
priority
to
me.
There
was
some
recent,
but
there
was
an
internal
study
that
I
meant
to
link
here
but
forgot
to
arguing
against
it.
C
A
Yeah
there's
different
opinions.
I
think
the
argument
against
was
sort
of
that.
They
found
it.
They
thought
it.
They
asserted
that
it
was
more
that
it
was
more
ergonomics
to
keep
the
restriction.
I
personally
consider
I
don't.
I
don't
feel
that
way.
A
It
says
you
can
keep
the
rules
of
types
but
come
before
constants
and
the
user
friendliness
that
comes
with
it,
but
I
I
don't
find
that
user
friendly
as
a
user
but
other
people's
mileage
may
vary.
I
guess.
B
Yeah,
my
personal
sort
of
general
feeling
is
that
we
should
also
try
to,
as
we
add,
more
sort
of
con
generics
and
so
forth,
look
at
seeing
if
we
can
make
the
type
parameters
like
so
that
you
don't
have
to
like,
if
you
add
a
type
parameter,
but
it's
default,
or
it
could
be
inferred
that
you
don't
actually
have
to
list
the
underscore
which
is
super
annoying
you're.
Talking.
E
B
Question
of
do
you
remove
only
the
restriction
at
the
sort
of
declaration
site,
but
you
still
keep
the
order
in
the
sense
that
you
have
to
match
the
declaration
in
the
call
or
if
you
want
to
do
some
sort
of
like
named.
If
you
use
the
same
name,
then
you
get.
You
know.
B
B
A
A
I'm
particularly
worried
about
long
lists
of
type
parameters
where
that
are
independent,
like
box
has
a
defaulted
allocator
and
a
defaulted
whatever
else
and
defaulted
something
else,
and
I
just
want
to
specify
one
of
them.
Not
all
of
them.
You
know,
or
I
guess,
like
patch
map,
has
a
hasher,
and
you
know
here.
A
Okay,
I
think
what
we'll
do
for
these
things
probably
is
make
basically
stabilization
reports
as
they
get.
I
don't
think
rfc
is
a
necessary
step,
but
I'd
be
curious.
If
people
disagree,
maybe
this
one,
the
first
one
is
the
only
case
where
I
think
it
actually
might
make
sense.
The
other
one
is
allow
defaults
on
cons
parameters
that
seems
kind
of
like
just
a
no-brainer.
A
This
one
is
a
little
more
interesting
permitting
underscore
as
a
const
generic
argument.
The
reason
that's
interesting
is
that
currently
we
don't
currently
we
require
that
the
caller
knows
whether
the
argument
is
a
type
or
a
constant
and
underscore
supporting
underscore
would
step
away
from
that
rule
because
underscore
could
either
be
a
type
or
a
constant
to
be
inferred,
and
you
have
to
look
at
the
callee
to
figure
it
out
and
once
you
go
that
far,
you
can
do
other
things,
for
example,
values
like
unit
and
zst.
A
It's
not
that
useful
in
practice,
but
today,
if
you
had
like
aunt
t
unit
as
a
function,
you
kind
of
can't
call
it
because,
because,
when
you
write
foo
colon
unit,
it
gets
treated
as
a
type.
Until
you
get
an
error
that
makes
sense.
A
Yeah,
that's
right,
you
can
call
it.
You
have
to
put
braces,
but
we
want
to
lift
that
restriction,
and
the
same
applies
to
like
certain
kinds
of
pads
like
like
the
csd
pack
here,
yeah.
A
A
C
I
remember
type
parameter
defaults
being
somewhat
more
complicated
than
I
expected
them
to
be,
which
makes
me
think
that
the
rules
getting
written
down
in
an
rfc
somewhere
might
be
valuable,
I'm
thinking
of
like
the
default
on
hash
set
and
where
it
applies
and
where
it
doesn't
apply.
It
was
not.
C
Super
obvious
to
people
some
of.
C
A
I'm
thinking
we
want
like
a
vision
doc
here
too
there's
such
a.
This
is
such
a
clear
case
of
like
we
have
a
thing
we
want
to
get
to
and
we're
like
in
a
weird
place
in
the
middle,
and
we
want
to
be
able
to
talk
about
here's
where
we're
going.
Here's
the
actual
stuff
we're
taking
in
life
that
takes
us
closer
to
where
we're
going.
We.
A
C
D
A
A
A
Is
there
anything
else?
People
want
to
say
about.
C
It
this
seems
to
sort
of
be
bringing
in
the
thing
we
talked
about
around,
introducing
a
new
syntactic
form
for
special
things
and
the
last
time
we
talked
about
that
we
decided
not
to
do
that.
C
F
Right,
I
don't
recall
us
specifically
saying
we
don't
want
to
introduce
a
new
syntax.
I
recall
us
saying
we
don't
want
to
introduce
special
cases
and
taxes
of
let's
dedicate
dollar
sum
symbol
that
isn't
currently
assigned
to
some
specific
function,
and
I
think
we
were
primarily
concerned
about.
There
are
a
limited
number
of
extensions
we
can
make.
This
seems
like
it's
doing
what
we
actually
wanted,
which
was
to
introduce
a
generalizable
syntax
that
is
arbitrarily
extensible
in
the
future,
to
cover
anything
we
might
need.
I
actually
think
this
makes
perfect.
A
C
Or
something
like
that,
once
upon
a
time
when
we
found
out
that
the
dollar
self
can't
be
self
like
the
path,
and
then
we
had
a
conversation
about
how
much
of
this
should
be
macros
2.0
versus
macros
one.
I
guess
this.
I
guess
the
big
difference
for
this
proposal
is
that
it
has
nothing
to
do
with
hygiene.
So
exactly
most
of
the
things
that
we
were
worried
about,
there
don't
apply
to
this
one,
and
it
does
seem
pretty
reasonable
to
me.
G
A
All
right:
let's,
let's
move
this
to
the
rfc
and
keep
going.
I'm
worried
we're
spending
too
much
time
on
each
item.
So
if
there's
further
concern
instruction
set
update,
so
I
posted
this
big
comment
from
local
thor.
F
F
F
Okay,
what
I
wonder,
and
what
this
I
think
doesn't
cover
is:
is
there
some
fundamental
reason
that
instruction
set
and
inlining
couldn't
be
made
to
work
reliably
in
combination
in
that,
if
you
were
able
to
inline
from
one
to
the
other,
you
would
just
need
to
swap
instruction
set
and
say
well,
if
I'm
inlining
in
a
thumb
function,
I
need
to
generate
thumb
code.
F
F
I
agree,
I
think
the
degree
to
which
this
is
a
lengthy
question
is
perhaps
is
this
the
right
abstraction
and
if
we
have
this,
is
this
going
to
break?
Is
this
going
to
break
badly
enough
that
we
don't
end
up
wanting
it?
So
it's
a
language
decision
if
quality
of
implementation
isn't
possible.
A
A
I
don't
know
if
there's
active
work,
exploring
these
alternatives,
and
so
on.
It
also
sounds
like
this
would
be
forwards
compatible
like
you
could
stabilize
what's
there,
it
may
not
behave
how
you
expect
and
you
could
tinker
and
improve
on
the
implementation,
and
it
would
be
okay
like
if
it
were
getting
more.
F
As
long
as
the
correctness
was
not
an
issue
with
inline,
always
right
now,
it
sounds
like
if
we
stabilize
the
current
behavior,
it
would
actually
be
broken
entirely,
but
if
we
we
should
double
check
that
with
locator
and
figure
out.
If
the
current
behavior
is
safe,.
A
Okay,
yeah,
I
mean
some
of
this
language
is
very
informal.
So
it's
hard
for
me
to
tell
what
kind
of
host
items,
for
example,
but
I
would
have
assumed
it
meant
you
may
not
get
the
instructions
that
you
asked
for,
or
you
may
not
get
inlining.
You
kind
of
can't
have
both
today.
Inline
always
is
always
a
hint
even
despite
its
name
right
like
if
it's
recursive,
for
example,
yeah.
A
C
A
Okay,
let
me
take
a
look.
I
had
some
thoughts
I
wanted
to
use
for
that,
but
I
think
we
have
a
little
time
to
talk
about
trying.
C
C
C
C
I
have
a
basic
plan
for
how
this
could
be
made:
an
edition
change
so
that
2015
and
2018
this
would
still
compile
2021.
This
would
not
compile
without
being
a
major
burden
in
the
compiler
of
the
library.
C
A
C
F
I
would
personally
be
in
favor
of
removing
those
in
an
addition
if
we
expect
that
doing
so
will
not
be
a
substantial
transition
burden
for
the
vast
majority
of
code
bases.
F
I
am
a
fan
of
the
general
approach
of
having
that
special
module
within
the
new
try
proposal
to
contain
those
conversions
and
just
not
having
that
module
be
present
in
the
new
prelude.
B
H
I'm
curious
scott,
your
opinion
here,
like
the
motivation,
I
don't,
I
don't
have
a
preference
too
much
in
either
direction,
but
I'm
curious
whether
like
the
big
motivation
here
is
just
like,
like
this
is
inefficient
to
have
these
conversions
and
you're
better
off.
Writing
the
code
to
say
directly
what
the
thing
you're
making
is.
You
don't
have
the
cost
of
the
conversions
or,
if
it's
you
might
have
a
bug,
you
don't
realize
it
and
that
somehow
that
bug
is
being
masked
by
this,
although
it's
hard
to
imagine
where
that
would
arise
or
is
it
just?
C
I
don't
think
there's
any
efficiency
concern
here,
it's
more
of
a
it
loses.
C
E
Yeah,
so
the
non-error
type-
that's
using
this
is
still
unstable.
It's
just
that
you
can
accidentally
use
it
while
not
naming
it's
like
russ
analyzer
was
doing
so.
This
was
never
supposed
to
happen,
so
if
we
can
just
break
it
and
it
first
analyzes,
maybe
one
of
the
very
few
that's
actually
using
it,
then
I
would
be
all
for
it.
We
should
look
at
the
creator
and
to
see
how
how
much
of
the
world
is
brilliant.
C
The
crater
run
should
start
in
about
two
days
in
a
maybe
one
or
two
days
to
find
out
how
bad
this
is.
Overall,
I
think
the
rest
analyzer
pr
is
a
good
example
that
it
actually
wanted
to
be
using
option
the
whole
time
anyway,
and
it
just
didn't
find
out
about
it.
A
A
If
there
are
any
other
project
updates,
oh
you
should
put
them
in
people
can
leave
them
on
for
something
I
do
see.
We
have
some
more
active
projects,
but
I
don't
think
any
of
them
have
any
updates
than
I
know
so.
I
was
wrong.
There
are
some
meeting
proposals
and
I
wanted
to
add
backlog
bonanza
as
something
that
we
could
have
sort
of.
Let
go
and
might
consider
using
some
slots
for
so
I'll
open
the
floor.
C
Okay
and
not
exactly
in
a
meeting
proposal
specifically,
but
it
sounds
like
the
edition
deadlines,
gonna
be
the
end
of
march.
Maybe
I
don't
know
if
there'll
be
anything
that
we
need
a
meeting
for
before
then.
A
So,
specifically,
what
that
deadline
is
is,
if
there's
any
yeah,
it
should
have
an
approved,
rfc
or
other
formal
decision
yeah
just
for
context
for
everyone
else.
I
don't
know
of
anything
that
we
need
a
meeting
on
specifically
for
that,
but
it
may
come
up
it's
a
good
idea.
We
have
a
slot
for
it
kind
of.
H
Yeah,
am
I
muted
right
now?
No,
no!
So!
Basically
the
heart
of
this
is
I've,
been.
I
don't
know
how
much
backstory
to
get
into
here.
H
The
heart
of
it
is
that,
like
it's
not
clear
to
me
how
we
intend
people
to
write
certain
kinds
of
code
like
intrusive,
linked
lists
and
whatnot,
where,
because
we
have
this
long,
sending
issue
where,
if
you
try
to
deallocate
something
via
a
based
on
the
value
of
an
atomic
reference
count,
technically,
we
haven't
specified
like
whether
it's
legal
to
actually
still
hold
on
to
that
reference
to
do
you
have
a
reference
to
something
and
you
reference,
namely
to
the
atomic
reference
account.
H
That's
that's
stored
within
the
cell
that
you're
going
to
be
delegating
the
memory
cell
you're
going
to
be
deallocating,
then
the
active
then
using
that
the
reference
count
to
sort
of
trigger
that
the
allocation
means
you
still
have
end
up
having
your
hands
on
a
a
shared
reference
to
that
reference
to
that
atomic
reference
account
and
that
is
currently
not
allowed
in
terms
of
like
the
semantics
of
the
language
and
my
original
approach
to
trying
to
resolve
this
was
to
be
to
say
to
say:
let's,
let's
duplicate
the
api
surface,
for
the
atomic
api
to
let
you
pass
in
raw
pointers
everywhere
and
that
got
some
push
back,
because
it's
a
pretty
big
api
surface.
H
Wait,
which
thing
am
I
supposed
to
use
at
which
times
and
the
insight
that
came
up
is
that
someone
pointed
out
that,
basically,
you
could
just
say,
look
like
if
something's
allowed
to
be
mutated
under
the
hood,
because
you
had
an
unsafe
cell
or
because
it's
behind,
basically,
if
it's
behind
the
same
things,
this
unsafe
cell,
then
you're
also
allowed
to
de-allocate
it.
The
compilers
can't
assume
that
it's
going
to
stay
allocated
and
thus,
in
particular,
an
ampersand
atomic
cell
atomic
hint
would
be
able
to
be
deallocated
under
that
rule
change.
H
So
this
is
like
a
relatively
simple
change
to
the
language
semantics
in
terms
of
what
the
compiler
is
and
isn't
allowed
to
assume
that
would
solve
this
problem.
It's
just
a
question
of
doing
it
and
having
this
sort
of
you
know
buy-in
from
everyone
to
say.
Yes,
that
makes
sense
to
do
that.
H
A
H
For
me,
I
want
a
strategy
for
resolving
this
problem
because
they're
they're
customers
that
are
trying
to
write
code
that
does
this
and
they're
sitting
there
saying
I,
like
you,
know
if
they're
getting
feedback
or
they
don't,
they
aren't
clear
on.
What's
legal
and
you
know,
there's
some
incoherency
in
our
own
internal,
like
discussions
about
whether
it's
legal
or
not
so
yeah.
G
It's
worth
noting
that,
like
people
have
written
this
code
and
not
that
that's
to
say
that
you
know
we
can't
break
written
code
or
declare
that
you
know
something
that
was
pretty
poorly
specified
is
now
ub.
But
you
know
it
would
be
nice
to
make
a
semantics
here
that
doesn't
actually
miscompile
all
those
things
in
the
wild
yeah,
because
this
is
a
fairly
common
thing
to
do.
A
I
agree:
that's
a
good
constraint.
I
guess
I
think.
Let
me
rephrase
this.
I
would
like
to
do
this
more
amazon,
doc
style,
by
which
I
mean
I
would
like
there
to
be
a
write-up
beforehand.
It's
like
here's,
the
proposal,
here's
the
sort
of
frequently
asked
questions
or
whatever
else,
to
give
details
about
it.
I
don't
know
if
that
exists,
but
I
feel
like
the
closest
thing
that
exists
right
now
is
ralph
points.
You
there's
comment
on
the
issue
and
says
this
is
the
most
recent
idea
is
that
correct.
B
I
am
happy
to
sort
of
help
out
in
writing
that
document,
but
I
don't
know
to
the
extent
that
I
can
commit
to
doing
it
entirely.
B
A
All
right
discuss
the
amount
of
oversight
laying
should
have
for
lintz.
What
do
we
do?
I
think
this
bit
fair
trade.
I
don't
think
we
need
a
I
mean
for
this
weekend
over
this.
We
have
a
proposal
that
I
don't
know
what
came
out
of
that
meeting
yesterday
mark
with
ryan
and
everything,
but
I
think
we're
pretty
close
to
a
proposal
right.
B
That's
my
impression
yeah,
or
at
least
I
don't
think
we
need
a
meeting.
A
I
think
we
shouldn't
schedule
it
in
that
case
sort
of
feel
the
same
about
macros,
it's
a
little
bit
on
it's
a
little
big
for
a
topic
to
me.
F
I'm
not
sure
if
this
is
baked
enough
for
a
design
meeting.
I
wanted
to
bring
it
up
simply
because
we've
had
several
things
come
up
in
the
context
of
macros
recently
and
it
feels
like
we're
nibbling
around
the
edges.
I
don't
necessarily
think
we
should
have
a
macros
2.0
meeting
unless
somebody
is
ready
to
say
I
want
to
implement
macros
2.0,
but
I
think
there'd
be
value
in
saying.
Should
we
have
a
general
extension
point?
What
things
should
we
add
to
that
extension
point?
F
Is
the
proposal
for
the
other
rfc
that
we
saw
earlier
in
this
meeting
the
right
direction,
or
do
we
want
to
do
a
different
direction
check
it
feels
like
we
ought
to
be
able
to
provide
more
general
guidance
on
macros
that
isn't
driven
purely
by
what
have
we
been
asked
right.
This
second.
B
A
It's
fair,
so
the
other
two
things
I
wanted
to
do:
a
meeting
to
go
back
over
the
backlog,
bonanza
that
we
did
last
time
with
the
rfcs
and
like
double
check
what
happened
and
do
it
if
there's
ambiguity-
and
I
also
I've
been
working
on
this
proposal
for
a
while
to
she
by
working
on
I
mean
talking
about
mostly
though
I
have
a
sketch
somewhere
of
a
like.
A
Not
if
it
was
a
work
meeting,
maybe
not
everyone
would
have
to
attend,
but
just
if
you're
interested,
let
me
find
my
link,
but
it's
basically
around
adding,
let's,
let's
like
revise
shepard's
thing
that
we
were
talking
about
and
maybe
talking
a
little
bit
about
how
triage
should
work
so
I'd
be
willing
to
commit
to
producing
a
document
for
the
meeting.
If
we
wanted
to
do
that,
I
kind
of
already
have
it
so.
A
A
B
H
A
Which
I
actually
quite
like,
don't
know
it's
an
interesting
thought.
I'm
not
yeah.
I
like
the
amazon
way
of
saying
you
don't
read
the
duck
till
the
meetings.
I
think
it's
realistic,
the
idea
being
basically
everyone's
busy
and
that's
the
time
that's
allocated.
A
I
I
I
totally.
I
saw
no
pink
felix
and,
like
I
didn't
intentionally
not
schedule
march
10th,
but
I
I
just
forgot
that
that
didn't
mean
enough
that
we
had
he
was
available,
but
I'm
okay
scheduling
nothing
there.
H
A
For
example,
stuff
like
that
and
that's
another
thing
that
we
could
say
is
try
to
set
a
rule
for
life.
Well,
if
we're
not
expected
to
read
the
doc
until
the
meeting,
I
would
still
like
to
have
a
rule
that
says
the
doc
has
to
be
written
like
by
the
triage
meeting,
because
I
want
people
to
know
if
they
have
that
time
free
with
more.