►
From YouTube: 2020.04.20 Lang team: 2021 Edition design 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
Figure,
this
meeting
is
probably
more
of
us.
It's
probably
gonna
be
more
of
a
beginning
than
an
end,
but
we'll
see
how
far
we
get,
but
I
thought
it
would
be.
I
would
like
us
to
talk
a
little
bit
about
my
plans
over
the
next
year
or
so
little
more
than
a
year.
If
we
are
gonna,
do
a
2021
kind
of
edition.
We
didn't
have
to
start
thinking
about
and
timing
the
stuff
that
we
do
and
what
it
means
to
do.
An
edition
is
also
like
a
little
bit
about
I
think
there's
some
combination.
A
That
was
just
doing
just
using
that
as
a
good
time
goal
for
ourselves
to
do
work
that
we
think
would
make
Brust
better
and
target
existing
problems.
Even
if
it's
not
really
like
it's
not
making
to
do
it
backwards
and
compatibility
per
se,
and
then
there's
also
the
question
of.
If
there
are
going
to
be
any
backwards,
incompatible
changes,
they
would
span
in
addition,
boundary,
and
we
want
to
prioritize
those
because
you
want
to
make
sure
that
goes
smoothly.
So.
A
Let's
see
to
start,
I
can
say
that
I
a
little
work
into
just
collecting
information,
both
in
terms
of
unfinished
business
or
our
kind
of
2020
goals.
One
of
the
big
ones
was
to
clarify
and
work
through
unfinished
business
things
that
are
mostly
done,
I'm,
not
quite
and
see
what
it
takes
to
really
knock
them
off
right.
A
So
he
enumerated
some
of
the
things
here.
There
might
there's,
probably
more
and
then
down
here.
No,
no.
These
aren't
all
me
probably
but
I
think
some
of
these
are
other
people,
but
me
and
others
added
things
that
were
like
potentially
breaking
changes
that
we
might
want
to
think
about
or
prepare
for
actually
I
realize
that
these
ones
missing
so.
A
A
I
guess
to
start,
we
can
look
a
little
bit
at
the
ergonomics.
There
are
other
things
that
that
are
left
over,
that
fall
under
the
unfinished
business.
I
guess
what
I'm
hoping
we
can
come
out
of
this
strong
is
a
kind
of
shorter
list,
reasonably
short
list
of
things
we
might
think
about
doing,
and
then
we
can
try
to
decide
if
that's
actually
scheduled
and
among
other
things,
that
might
be
a
good
idea
to
take.
A
C
B
These
and
our
highest
priorities
would
be
the
ones
where
everybody's
like
yeah.
We
absolutely
need
to
do
that.
We
just
have
to
sort
out
the
bike
shedding
or
sort
out
the
you
know
some
particular
problem,
as
opposed
to
half
of
us.
Think
we
shouldn't
do
something
and
it
would
be
much
more
difficult
if
a
lot.
A
A
There's
a
few
other
details
that
I
think
we
would
want
to
resolve
with
some
of
the
implementations
that
we've
done.
I
think
it'd
be
pretty
great.
This
seems
like
one
of
the
key
things
I
think
we
should
work
to
expand
personally
and
I'm
potentially
interested
in
helping
get
involved
in
that.
But
the
reason
that
I
think
it's
great
is
not
only
simple
trade
super
useful,
but
it's
really
useful
for
async
IO.
A
A
Think
our
support
that
we
have
is
pretty
good,
but
it
has
some
some
problems
in
particular,
I
think
that
I
have
to
go
review
the
details,
but
the
way
we
do
the
inference
of
types
and
the
way
we
said
we
would
do
the
different
subtypes
doesn't
quite
line
up,
and
that
seems
like
something
we
would
want
to
review
in
detail
and
think
about
will
be
actually
one.
Last.
B
I
heard
the
idea
of
infiltrate
in
a
trait
was
something
where
there
was
some
amount
of
additional
logic
required
for
inference
it's
in
the
category
of
stuff.
That
will
be
easy
when
we
have
chalk
or
is
this
in
the
category
of.
We
have
no
idea
how
to
do
this,
and
we
need
to
come
up
with
logic,
for
it
infiltrate.
A
B
A
Complication
there
I
think
it
would
pop
I
guess,
I
think
the
work
here
would
be
to
sort
of
somebody
would
want
to
do
the
background
work
on
like
let's
write
up
all
the
places.
Something
I
wanted
to
do
at
some
point
its.
To
make
an
example
like
an
example
program
that
shows
all
the
places
that
infiltrate
can
be
used
with
little
links
or
something
that
can
help.
A
D
Yeah,
there's
some
sort
of
design
working
to
be
done
around
exactly
how
like,
when
it
can
be
substituted
with
a
real
type
and
there's
also
I
mean
it
would.
You
know,
preferred
to
have
the
same
semantics
in
return
position
as
it
does
outside
of
trace.
It
would
need
to
be
generic
exactly
a
generic
associated
type.
Is
you
know
that
Spencer
sort
of
implementation-
drug
that's
blocking
des
at
Josh's,
clever
friend,
yeah,.
A
D
A
A
B
D
D
B
I
would
agree
with
that.
I
think
the
only
downside
which
I
don't
think
is
a
blocker
I,
think
it's
just
where
it's
dating
allowed,
and
if
we
do
that,
that
means
you
can
ever
switch
from
a
generic
argument
to
argument
position
infiltrate
without
that
being
a
breaking
API
change.
That
said,
that
doesn't
seem
like
a
horribly
big
deal.
Yeah.
D
D
B
D
Yeah
and
I
actually
like
like
in
this
example.
This
is
what
I
like
to
use
simple
trait,
for
is
for
things
like
closures,
where
you
never
want
a
turbo
fish
to
type
it
just
doesn't
really
make
sense
and
like
then,
you
can
have
the
generics
be
the
things
that
you
might
actually
want
it
to
wrote
this
right.
These
are
the
types
of
it's.
A
D
B
C
B
A
B
B
A
B
B
A
Personally
would
find
this
very
nice
to
have
it's
this
relatively
small
bit.
I
miss
it
all
the
time.
It's
the
first
thing
that,
when
I
convert
from
nightly
to
stable,
I
have
to
go
change,
I,
hope,
being
climbed
to
this
big
I,
think
we've
pretty
successfully
gotten
rid
of
leading
:
pads
and
I
didn't
find
to
pick
a
meaning,
but
even
I
really
care
to
debate
the
details
of
the
ambiguity.
At
this
moment,
yeah.
D
D
D
A
B
Yeah
this
one,
it's
not
that
we
didn't
know
how
to
do
it.
It's
that
there
was
a
lot
of
controversy
around
the
idea
of
doing
so,
because
many
people
in
the
community
posted
around
the
notion
of
hey
I,
have
a
dot
RS
file
sitting
around
in
my
project,
I
didn't
anchor
it
into
the
module
hierarchy
with
a
mod
statement,
and
that
was
intentional.
It's
a
test
program.
It's
some
local
copy,
I
made
whatever
it's
a
reasonable
concern
and
it
does
change
people's
current
workflow
and
the
question
would
then
be.
B
E
A
Yes,
how
much
you
can
do
about
that
I
think
well,
actually,
I
thought
we
were
saying
I.
Remember
now
that
the
I
another
alternative
here
would
be
that
we,
oh
no,
we
didn't
want
that,
never
mind.
There
was
the
option
of
only
using
files
that
sort
of
are
mentioned
in
your
code
somewhere,
which
I
was
concerned
about
because
at
least
I
often
have
like
modules
with
just
imposing
them
that
never
get
explicitly
our
code
and
we're
requiring
some
sort
of
mind
for
like
an
artificial
use.
A
B
Point
year
there
was
one
from
so
we
don't
fully
know
the
architecture
we
went
for.
This
one
proposal
was
to
automatically
find
all
the
files
and
pretend
you
to
put
mod
statements
for
all
of
them.
Another
one
was
that
you
would
could
use
use
in
place
of
mod,
and
you
could,
for
example,
use
sub
module
and
this
wouldn't
be
fully
redundant.
If
you
didn't
already
have
a
mod
sub
module.
C
A
D
A
D
Well,
I
think
I
would
like
if
this
was
Russell
work,
I'd.
Never
in
my
statement
somehow
I
was
always
in
favor
of
this,
but
I
think
I
feel
like
we
well.
I
know
that
it'll
be
extremely
controversial
and
I
feel
also
there's
a
certain
cost
of
making
big
changes
to
the
path
system.
Again,
like
I
feel
like
we
shut
our
shot
and
we
made
the
revised
pass
system
and
we
really
can
like.
A
E
A
A
B
Also
be
in
favor
of
you
know,
as
we
experiment
with
that
lint,
we
could
also
look
at
what
would
it
take
to
auto
load
modules
in
a
mentioned
in
a
use
statement
rather
than
everywhere
in
the
program
and
whether
that
would
be
a
substantial
usability
improvement
that
this
sounds
like?
The
answer
is,
let's
add
a
lint
and
start
experimenting
rather
than
committing.
C
D
A
B
All
right
so
moving
on
to
the
next
items,
there
is
a
proposal
still
open
I
believe
to
have
generalized
type
description
available
everywhere,
the
main
advantage
being
that
you
could
write
as
less
and
:
more
I
would
certainly
love
to
have
this
I
think
the
main
blocker
was
just.
Can
the
parser
support
this,
and
will
this
introduce
any
ambiguities.
D
That's
none
so
I
well,
I
want
to
know
about
the
ads
thing,
because
I
think
that,
as
normally
isn't
Houston
that
way
like,
as
is
known,
like
changing
a
type
to
a
different
type
and
those
types
normally
don't
course
between
each
other
or
if
they
did,
it
wouldn't
be,
but
I
mean
I.
Think
for
me,
the
big
issue
with
this
was
always
that
it
conflicts
with
keyword.
Arguments
like
named
function,
arguments
I.
B
A
D
B
D
C
A
D
B
A
B
A
A
B
F
A
B
I,
don't
know
about
the
info
block
case,
but
I've
run
into
the
function
case
numerous
times
where
I
find
myself
repeating
a
block
of
three
different
trait
bounds
that
are
required
for
a
tight
anytime
I
want
to
mention
the
type
and
take
an
argument
of
the
type
you
know.
That's
the
that's
the
symptom
world
yeah.
C
C
C
C
A
B
B
But
is
there
any
way
that
we
could
not
require
you
to
specify
a
bound
if
the
only
reason
you
need
it
is
to
provide
a
type
to
that
trait?
That's
completely
generic
and
do
require
you
to
specify
a
bound.
If
you
use
it
yourself,
you
care
that
it's
copy,
you
have
to
say
it's
copy.
If
you
only
know
that
food
cares
that
it's
copy,
then
you
can
just
use
foo
and
whose
requirements
will
carry
through
I
like.
C
B
A
B
A
Let's,
let's
from
this
to
because
yeah,
but
suffice
to
say
it's
not
really
I
think
nobody
is
opposed
to
the
concept
we
just
want
to
compare
it's
not
tied
to
the
addition
per
se,
because
it's
sort
of
a
forward
compatible
thing
true,
so
it's
mostly
like:
let's
let
the
patient
proceed
and
then
we'll
explore
the
options.
I
think
that
these
kind
of
ideas,
these
more
subtle
rules,
I,
think
this
is
exactly
why
I
want
to
get
the
talk,
work
done
first,
because
I
think
we
could
definitely
do
that.
A
A
D
B
B
A
A
B
Okay,
yeah
next
one
up
is
specialization.
There
has
been
a
lot
of
iteration
on
this
lately,
including
the
whole
soundness
issue
that
came
up
there's
now,
a
new
min
specialization
variant
that
the
standard
library
is
trying
to
stay
within
the
subset
of
so
I
think
the
only
question
would
be.
Is
there
something
that
is
likely
to
help
edition
wise
here
of
moving
forward
where
it
would
be
harder
without
an
Edition.
A
Exactly
what
did
I
think
the
main
thing
main
bit
of
design
work
left
here
was
around
like
the
mid.
If
we
want
to
have
to
remember
now,
if
we
want
to
have,
if
you
want
to
be
able
to
specialize
on
traits
that,
like
for
all
T
that
implement
some
trait,
then
we
need
that
doesn't
really
work
that
well
in
the
specialization
variant
and
it's
a
pretty
common
thing
to
want
to
do
and.
B
A
In
trying
to
move
forward
with
just
that
former
case,
which
is
pretty
useful
too,
but
we
there
was
like
certain
amount
of
design
work
remaining
there
where
we
wanted
to
have
basically
about
you
mean
like
a
errands
blog
post.
It
was
kind
of
there
would
be
some
sort
of
I,
don't
know
some
way
to
say:
I'm
gonna
implement
for
all
tea.
A
A
A
A
B
A
A
B
C
B
B
Do
there
was
originally
I
think
a
proposal
for,
if
not
less,
and
it
just
became
very
confusing-
that,
if
not,
would
then
find
something
outside
of
the
if
block
there
were
also
discussions
about
a
guard
syntax
which
would
be
very
heavyweight
and
Morty
wordy
and
then
I
think.
The
last
variant
that
we
looked
at
was
effectively
a
MAF
that
was
part
of
a
Alette
finding
assignment.
There
was
a
minor
syntactic
ambiguity,
but
it
was
one
of
those
that
only
came
up
if
you
were
otherwise
going
to
buying
something
to
unit.
B
A
C
B
I
was
just
pulling
that
up.
There
is
an
RFC
1303.
They
got
postponed
quite
some
time
ago
for
well
yeah.
I,
think
the
only
ambiguity
there
would
at
would
ever
come
up
if
you
were
actually
writing
yes
on
the
right
side
of,
alas,
and
without
an
L
such
that,
then
the
expression
would
be
binding
to
the
unit
that
that
returned.
That.
A
A
C
B
D
B
A
A
B
A
Think
I
don't
know
that
I
want
to
volunteer,
but
let's
worry
about
the
who
will
do
what
little
but
I
think
an
interesting
thing
for
us
to
do
if
we
know
directly
out
of
this
meeting,
but
following
up
if
we
had
a
list
of
stuff
when
we
kind
of
said
here's,
this
there's
some
stuff
we'd
like
to
do.
This
is
what
we
sort
of
have
people
for.
This
is
what
we're
looking
for.
Someone
motivated
like
we
have
a
liaison,
but
we
don't
have
a
person
to.
E
A
A
B
A
A
A
A
B
Point
of
view,
one
of
them
is
unsafe
in
unsafe
function
where,
if
we're
going
to
make
a
backwards
incompatible
change
here,
an
addition
would
be
part
of
that
step.
I,
don't
know
that
we
can
do
this
in
one
step,
but,
for
example,
if
we
wanted
to
start
lightly
warning
about
the
then
an
addition
might
be
the
place
to
do
it
so
that
in
a
distant
future
we
have
the
opportunity
to
take
the
default.
B
A
I
would
hope
that
we
would
I
mean
I
think
we
were
trying
to
automate
this
right
prospect
yeah
and
then
the
main
question
is:
how
good
can
we
do
like
we
can
do?
A
really
I
would
not
want
to
work
even
new,
even
though
it's
not
like
hard
error.
I
would
prefer
to
have
a
rust
fix
jeremy,
and
I
think
the
question
would
be
how
narrow
can
you
make
the
unsafe
blocks
kind
of
implementation?
Question
I,
think
the
most
sort
of
bad
version
would
just
make
the
whole
function.
B
There's
also,
by
the
way,
one
slight
interaction
with
another
thing:
we've
discussed.
If
we
decide
to
introduce
a
function,
equals
expressions
impact,
then
that
would
reduce
the
number
of
races
here.
If
you
do
equals
unsafe,
open
Bray's.
That
said,
I'm
not
going
to
try
to
push
that
syntax
at
this
moment
that
I
don't
think
we
can
talk
about
it
in
five
minutes,
I'm
only
observing,
there's
an
interaction
here,
yeah.
A
B
The
rust
fix
can
come
later.
If
we're
confident
we
can
do
it.
The
question
is
that
can
we
make
the
change
by
October
or
as
it
off
as
a
thing
that
the
new
edition
implies?
Okay,
skipping
ahead
a
little
bit
to
a
couple?
Other
item
Amani:
you
do
you
want
to
talk
very
briefly
about
why
we
might
want
a
new
keyword
for
Azzam
and
contrast
that,
with
the
idea
of
as
I'm
being
a
macro.
B
Nevermind
then,
one
item,
now
that
we
are
starting
to
coalesce
around
consensus
for
tribe
locks,
then
I
think
the
next
step
on
that
is
that
it
would
be
really
nice
to
have
the
syntax
for
early
return
with
error.
I've
been
joking
with
a
couple
people
on
Twitter
that
sometimes
examples
can
just
use
the
eat
keyword,
because
we
know
that
definitely
not
what
we're
doing
so.
We
don't
have.
We
can
be
neutral
about
what
syntax
were
using,
but
more
in
all
seriousness,
whatever
keyword
we
actually
use
for,
though
we
might
want
to
reserve
for
the
addition.
B
C
B
That
was
the
proposal
here.
Yes,
the
last
time
around,
we
decided
we
didn't
want
to
just
proactively
reserved
a
keyword
for
a
feature
that
doesn't
exist
yet
so
the
implication
here
would
be.
If
somehow,
between,
Mel
and
October,
we
can
complete
our
bike
shedding
and
decide
on
a
keyword.
Then
we
could
reserve
the
keyword
and
implement
the
keyword
in
the
next
edition,
because,
frankly,
this
is
an
incredibly
small
change.
B
B
A
D
A
D
A
Have
another
caller
have
to
join
them?
I
think
we
do
have
an
upcoming
meeting
where
we
time
to
talk
about
this
discuss
it.
Then
what
would
be
good
in
the
meantime,
people
can
skim
this
duck
and
maybe
leave
comments,
and
you
can
have
some
discussion
in
there
and
we'll
figure
out
how
to
follow
up
and
go
further
with
this
planning's
I
think.