►
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
I
think
the
general
plan
is
to
do
a
less,
not
so
much
that
this
is
a
time
when
all
the
things
come
together,
as
this
is
a
window
for
us
to
use
in
planning
and
also
an
opportunity
for
us
to
lay
down
some
groundwork
for
future,
like
keywords
or
other
things
we
might
want
to
do,
and-
and
it
is
a
chance
for
us
to
look
back
at
all
the
stuff
we've
done,
but
so
I
think
we're
trying
to
avoid
too
much.
I
guess
the
point
is
we're
trying
to
avoid.
A
A
If
we
don't
see
that
there's
people
we're
going
to
push
that
forward,
even
if
it
seems
like
a
good
change,
there
must
be
a
reason
that
no
one's
excited
enough
to
do
it,
but
so,
in
terms
of
the
areas,
I
think
these
are
the
major
areas
that
I
see
we
have.
We
need
to
keep
working
on
async
io,
although
I'm
not
sure
how
much
of
that,
at
least
in
the
shorter
time
frame,
is
really
a
laying
effort.
I
think
not
that
much
there's,
probably
some
preparation
work
on
the
lane
side.
A
A
A
A
I
put
that
under
async,
but
I
also
felt
like
it's
probably
not.
We
should
talk
about
them.
Maybe
we'll
do
it
in
a
little
bit.
My
sense
was
that
I
don't
think
there's
a
lot
of
that.
We're
not
going
to
be
pursuing
them
in
like
this
year.
Time
frame,
though,
I
think
it
would
be
possible
if
we
had
the
right
people
to
do
it.
C
B
A
A
I
guess
that's
a
factor,
I
think
it
also
because
I
just
I
literally
don't
know
like
who's
gonna,
do
that.
That
seems
like
a
big
task
that
requires
you
know
that
will
require
some
bandwidth
to
to
do
and
like
if
you
were
gonna.
Tell
me
you
wanted
to.
I
would
be
like
okay
now
we're
talking,
but
I
think
it's
not
something
that,
like
somebody
can
mentor
with
half
a
brain.
I
guess
is
my
point.
They
need
to
really
devote
themselves
to
that
yeah.
B
A
Okay,
so
that's
a
big
point,
I
guess
is
separating
out
what
how
many
tasks
can
a
person
really
juggle
you'll
see
that
I
have
my
opinion
too
many
on
my
list,
probably,
but
so
in
terms
of
addition
changes.
This
is
probably
the
most
thing
we
need
to
really
actually
have.
Is
what
of
these
things
most
of
these
things
that
I
think
we
should
be
looking
at
in
our
priorities?
Don't
require
changes
from
what
I
can
tell.
A
I
did
include
the
gen
keyword
here,
because
I
feel
like
on
the
time
frame
of
2021
to
2024.
Generators
are
definitely
in
scope,
and
it
would
be
wise
for
us
to
lay
the
ground
for
them
as
best
we
can
now.
This
is
a
little
bit
different
than
how
we
did
keywords.
I
guess,
but
I
kind
of
think
it
fits
like
we
decided
not
to
I
don't
know
we
should
decide
how
much
we
want
to
proactively
secure
keywords,
but.
A
I
I
guess
it
seems
like
we
may
be
far
enough
and
along
in
the
design,
that
we
have
an
idea
of
what
keywords
we
need
already
just
from
the
work
that
has
been
done,
but
maybe
that's
not
the
right
policy
and
the
other
major
change
thing
that
so
there
is
some
ongoing
work
on
rfc
2229,
which
is
the
closure
capturing
pads
thing.
It
could
potentially
affect
the
drop
order.
A
A
These
are
the
main
things
I
could
remember,
I'm
not
sure
if
I'm
missing
anything
so
there's
where
was
talk
of
maybe
reviving,
let
else-
and
there
was
talk
about
keyword.
Arguments
to
function
calls
both
of
them,
I
think,
had
some
minor
grammatical
breaking
change
aspect
to
them,
but
I
guess
there's
a
question
right.
There.
A
You
don't
have
to
decide
now
who's
going
to
do
it,
but
I
do
feel
like
if
we're
going
to
do
it,
somebody
needs
to
get
on
it
and
start
talking
it
through
and
figure
out
what
those
changes
are
and
do
that
work,
but
ideally
before
the
october
and
then
there
was
a
floated,
the
idea
of
do.
We
want
a
keyword
for
inline
assembly.
A
I
don't
remember
I
want
to
throw
in
the
issue,
for
it
didn't
trade
coherence
or
something
I
don't
know
it's
in
my
list
of
prs,
and
I
remember
that
at
some
point
I
was
contemplating
if
you
might
want
to
make
changes.
This
is
it
relating
to
it.
Although
I
think
I
came
to
the
conclusion
that
we
can
do
a
sort
of
targeted
fix
to
the
rules
that
is
okay
for
now,
but
I
should
decide.
A
A
D
It
also
seems
like
something
where
just
doing
the
code
and
implementation.
There
is
one
half
of
that
and
probably
the
smaller
half,
if
we're
going
to
try
to
solve
a
soundness
hole
like
that,
I
think
we
would
need
a
pretty
detailed
look
at
the
type
system
around
traits
to
make
sure
we're
actually
cloud
closing
the
sound
as
whole.
We
think
we
are
and
not
introducing
any
more.
A
A
I'm
trying
to
peace
out
what
you're
saying
there.
I
think
I
just
I
don't
so.
I
think
the
motivation
for
opting
in
for
din
trade
kind
of
would
be
to
do
what
you're
saying
as
well
as
it's
not
the
narrowest
change
you
can
do,
but
the
idea
would
be
that
pursuing
this
change
would
be
a
way
for
us
to
both
simplify
how
we're
setting
up
the
coherence
rules
around
din
trade
which
are
currently
complicated,
and
precisely
because
we
don't
have
opt-in,
we
sort
of
have
to
figure
out
whether
your
trade
is
incompatible.
A
I
guess,
but
I
would
also
say
that
the
motivation
there
was
more
than
just
to
close
the
sound
as
well.
The
motivation
was
feeling
like
the
current
model
confuses
people
and
that
that's
the
part
I
feel
is
true,
but
probably
takes
more
exploration
to
find
out
like
what
is
most
confusing.
Is
it
really
anything
related
to
this,
or
is
it
other
problems,
and
I
suspect
other
problems.
B
B
A
A
Do
so
going
down
the
list,
then
continuing?
I
guess
so.
We
all
kind
of
agree.
That's
not
probably
the
didn't
write
down
this
stuff
is
probably
not
on
this
list,
but
it
sounds
like
for
very
for
differing,
maybe
different
reasons,
but
the
two
things
that
I'm
most
interested
in
pushing
on
right
now
and
I've
been
putting
some
thought
into
is
around
infiltrate
and
gats.
Exactly
what
scope
of
infiltrate,
I
think,
is
not
entirely
clear.
A
You
can
even
imagine
something
like
you
can
declare
type
foo
equals
infiltrate,
but
you
can
only
use
it
in
return,
type
position
and
stuff
like
that
which
avoids
some
of
the
implementation
limitations.
We've
talked
about
and
would
unlock
people
it
would.
It
would
solve
the
major
use
case
I
know
of
which
is
returning
futures.
A
And
then
we
could.
I
would
like
to
be
doing
it
in
a
way
that
is
not
just
carving
out
narrow,
narrower
subsets,
but
you
know
has
a
path
to
completion,
so
that
wouldn't
be
like
the
end
of
the
road,
but
it
seems
worth
considering
and
gats,
I
think,
are
progressing
there.
That's
more.
These
are
both
more
implementation
problems.
In
my
view,
although
there
are
some
infiltrates
somewhat
less
so
one
thing.
B
B
A
Think
we
took
it
out.
I
don't
know
that
we
yeah
it
would
probably
be
good
to
have
one
just
for
our
own
benefit
to
like
write
up
the
I'm
gonna
put
in
their
gatson
typed
hrtbs,
so
for
for
every.
I
don't
know
if
everyone's
following
this
encoded
language
that
taylor
and
I
were
using
there,
but
this
is
what
we're
talking
about
right:
the
ability
to
express
things
like
this.
A
A
A
B
B
That
returns
results,
but
it's
actually
the
bound
only
works
one
way
today,
because,
basically,
because
our
type
checker
isn't
smart
enough
to
realize
that
a
like
circular
dependency
isn't
actually
circular,
and
so
trade
aliases
would
theoretically
resolve
that
and
make
it
so
that
we
could
have
that
bound
and
have
it
work
equally.
Well,
both
ways.
But
it's
not
like
crucial
for
anything.
B
Yeah
you
can't
both
have
the
the
bound
on
the
trait
bound
and
the
for
all
impul,
or
something
like
that.
I
don't
remember
the
exact
setup
of
it,
but
that
there
was
something
to
do
with
that.
You
can't
refer
like
I
I
I
can
send
you
the
code
example,
but
it
gets
into
some
like
thing
where
the
the
trait
solver,
when
throws
itself
into
knots.
A
B
A
A
Okay,
I
don't
remember
that
being
the
major
use
case,
but
I
can
see
that
it
for
a
lot
of
people.
It
might
become
the
major
use
case.
I
remember
being
more
what
taylor
was
saying
of
like
I
have
some
underlying
traits
that
are
more
flexible,
but
I
want
shorthands
for
what
people
do
most
of
the
time
and
you
probably
want
to
be
able
to.
I
don't
know,
depending
I
guess
some
of
the
things
we
don't
already.
We
don't
support
like.
I
don't
think
we
allow
you
to
implement
and
trade
alias.
D
A
D
I
think
it's
a
good
short-term
list
that
we
have
a
hope
of
getting
done.
There's
a
nice
long,
long-term
list
that
I'd
love
to
do,
but
on
the
short
term
list.
I
think
that
this
is
reasonable
to
get
done
and
the
only
one
that's
not
really
started.
Is
that
there's
some
additional
is
the
additional
linker
support
where
we're
kind
of
piecemeal.
E
D
D
E
A
A
A
So
I
was
thinking
that
it
seems
like
that
would
be
the
place
to
my
mind
to
start.
But
what
I
could
see
happening
here
is
trying
to
make
like
an
error,
handling
working
group
or
something
that's
looking
at
this
more
holistic,
both
across
laying
and
lib.
If
we
found
the
right
person
to
do
it,
but
again
I
don't
know
who
that
person
is.
A
D
I
think
the
other
thing
that
we
should
do
before
we
start
that
is
have
at
least
a
brief
conversation
with
the
libs
team
and
figure
out.
Can
we
and
how
do
we
charter
and
liaison,
or
a
cross-team
working
group
or
project
group?
Rather,
I
think
it
makes
a
huge
amount
of
sense
to
have
one.
This
is
the
kind
of
thing
where
it
comes
up,
but
we
need
to
not
do
we
need
to
actually
talk
with
the
libs
team
before
we
can
even
pretend
to
charter
one.
A
A
A
One
thing
I
was
wondering
about
here:
there's
a
so
coming
to
the
next
bullet
point.
There's
this
unsafe
code
guidelines
bullet
we've
done
a
lot
of
work
here,
but
not
quite
finished,
and
I
have
to
check
in
with
ralph
about
exactly
where
what
he
sees
in
terms
of
kind
of
writing
up
some
basic
layout
guarantees
and
writing
up
a
lot
of
the
notions
of
what
you
can
and
can't
rely
on,
and
it
seems
like
it
would
be
nice
if
we
actually
sort
of
landed
some
of
that
spec
work.
A
But
I
don't
know
if
there's
really
that's
going
to
happen,
but
it
seems
like
the
kind
of
work
we
do
need
to
be
doing.
If
we
want
to
say
that
we're
making
progress
and
of
course
we
have
this
unsafe
up
and
unsaved
function.
Lint,
and
I
guess
you
could
include
some
of
the
things
like
rawref
in
this
headline.
A
But
I'm
how
do
we
think
that
this
would
proceed
if
we
were
going
to
do
the
layout
safety
validity
stuff
like
what
is
the
right
decision
making?
Do
we
have
an
rfc?
Should
we
talk
about
go
review?
What
the
different,
I
think,
the
last
time
we
had
a
meeting
about
this.
Actually
we
talked
about
having
a
document
that
sort
of
outlined:
here's
what
the
rules
are
and
here's.
A
A
A
I
mean
none
of
this
has
really
tied
to
the
edition,
except
for
a
few
minor
things,
I'm
more
looking
at
just
what
should
our
efforts?
Where
should
we
focus
our
energies
like
if,
on
the
next
year,
let's
say
which
brings
us
to
about
mid
2020,
which
is
about
when
the
additional
come
out,
so
anything
that
we
want
to
do
for
that.
C
A
A
It
seems
pretty
concrete
to
me,
but
I
guess
the
question
is:
how
important
is
it
really
to
have
rules
here?
I'm
sort
of
appealing
a
little
bit
to
wondering
if
taylor
hadn't
thought,
for
example,
about
I
feel
like
for
unsafe
code
authors,
we
we've
kind
of
been
telling
people
to
a
certain
extent.
You
know
there
is
no
answer
or
pointing
at
this
as
the
answer.
Whenever
questions
arise
right
and
I
don't
know
how
much,
how
big
of
an
issue
that
is
for
people
in
practice
trying
to
build
reliable
code.
A
B
Yeah
and
there's
a
there's,
a
big
visibility
problem
right
because
there's
a
really
large
temptation,
at
least
for
people,
that
I
don't
know
in
my
experience,
like
people
coming
from
c
spots,
just
kind
of
default
expect
things
to
be
the
same
and
then
are
like
shocked
and
confused
and
somewhat
outraged
when
they're
not
and
a
lot
of
times.
The
fact
that,
like
the
official
answer
for
how
to
do
this
stuff
right
was
like
go
ping
ralph
young
on
zulip
is
like
not
particularly
satisfying
that
I
like
and
like.
B
B
A
But
I
don't
know
I
mean
the
others.
My
other
concern
is
that
you
know
there's
like
just
more
and
more
code
that
exists,
but
that's
probably
that
window
is
already
pretty
far
gone,
probably,
but
it
keeps
getting
more
gone,
but
I
also
feel
like
well.
Maybe
these
particular
rules
aren't
the
most
important
but
they're
the
ones
that
we
have
mostly
done,
and
it
gives
us
some
idea,
but
coming
back
to
the
who's
going
to
do
it.
That's
another
question.
A
That's
I
mean
I
was
pretty
specific
with
this
list.
It
does
not
include
memory
model
for
a
reason,
because
those
were
the
when
we
did
that.
Last
time
we
came
up
with
this
as
a
layers
that
we
could
separate
and
within
there.
I
think
there
are
still
a
few
pending
questions
around
like
especially
around
uninitialized
integers
seems
like
yeah.
A
Yes,
probably
I
don't
know,
let's
move
on,
I
guess
from
this.
I
don't
know
that
we're
gonna,
I
guess
I
I
think
probably
the
next
step
is
to
talk
to
ralph
and
try
to
assemble
some
energy
around.
If
there's
any
energy
to
organize
this-
and
I
guess
that,
like
an
rfc
that
covers
a
lot
of
this
text,
is
not
that.
A
I
don't
know
I
don't
know
how
to
to
stabilize
it,
but
it
seems
like
the
rfc
is
something
over
formality.
Really
most
of
the
action
is
happening
in
the
unsafe
code
guidelines,
though
that's
okay,
but
it
would
have
to
be
like
presented
and
explained
to
the
community
and
that's
like
half
the
job,
and
maybe
the
answer
is
that's
not
we're
not
going
to
make
big
progress
on
that
in
the
short
time
frame.
E
Leave
the
bigger
one
that
I
wanted
to
bring
up
is
that
at
least
to
me
it
feels
like
it
would
be
potentially
valuable
to
spend
some
time
looking
into
the
reference
and
exploring,
even
if,
like
all
we
can
say,
is
there
is
no
good
answers
in
this
area
having
at
least
that
much
and
having
that
be
formally
like
checked
off
by
this
is
the
official
notice
like
we
don't
have.
A
good
answer
would
be
immensely
helpful
because
a
lot
of
the
time
when
I'm
trying
to
find
these
things,
there
is
no
answer
of.
A
E
I
guess
I
I
feel
like
it,
even
if
we
can't
necessarily
you
know,
we
don't
have
bandwidth
to
formally.
You
know,
file,
rfcs
and
making
an
accepted
thing
even
sort
of
polishing
it
up
and
saying
that
this
is
the
place
to
go
to
get
your
questions
answered.
Even
if
the
question
answer
is
you
know,
this
is
still
in
flux,
but
here
are
a
couple
bullet
points
of
what
you
should
be
doing
currently
would
already
be
helpful,
a
lot
of
the
pages
that
at
least
I
recall
mostly
say
something
like
you
know.
A
I'm
trying
to
find
some
good
examples.
Yeah
I
mean,
I
think
that's
so.
This
was
an
example
of
like
a
page
talking
about
the
layout
of
structs
and
saying
here's
something
you
can't
rely
on.
It
does
definitely
say
this
is
all
unofficial
and
that's
partly
what
I'm
wondering
is.
What
does
it
take
to
change
that
label.
E
But
I
guess
partially
what
I'm
trying
to
say
is
that,
even
if
we
just
say
that
that
page
is
official,
but
it
doesn't
actually
guarantee
anything.
It
just
says
that,
like
it
is
indeed
official
that
we
don't
have
an
answer
here
to
me,
that
would
already
be
helpful,
rather
than
sort
of
not
being
even
official
like
there
is
no
official
resource
that
says
that
there
is
no
answer.
E
A
C
A
A
A
A
E
One,
I
guess,
consideration,
I
think
at
least
some
of
these
features.
They
do
look
like
they
require
sort
of
space
and
potential
edition
break.
Even
if
that's
just
reservation
and
not
actual
like
implementation,
it
might
be
worth
sort
of
identifying
things
that
we
can
say.
We
don't
have
design
bandwidth
necessarily
to
work
through.
You
know
the
spec
or
to
implement
it,
but
like
what
else,
for
example,
maybe
we
can?
You
know,
reserve
else
after
let
in
some
vague
way
and
we
you
know
we
stop
there.
E
A
A
A
I
guess
the
question
is
like:
if
we
make
an
rfc
that
says
we're
going
to
keep
space
for
light
else,
are
we
committing
ourselves
then
to
make
what
else
not
exactly?
Obviously
we
can
let
that
space
go
we're
committing
ourselves
that
we
think
it's
a
pretty
okay
idea
enough,
good
enough
that
we
want
to
migrate
people
a
little
bit
to
make
space
for
it.
E
E
A
A
A
A
A
E
I
think
roughly,
although
I
might
go
to
the
extent
to
say
that
we
should
mostly
put
things
in
this
list
where
it's
like
more
so
that
we
think
we
probably
want
something
in
that
problem
space.
But
we
don't
know
that
this
is
the
right
solution
for
it
and
as
such,
maybe
don't
have
a
spec
for
the
solution.
E
For
example,
like
keyword
arguments
to
function
calls
I
think,
at
least
in
my
opinion,
there
is
sort
of
a
problem
there
to
potentially
solve,
and
maybe
there's
you
know
no
good
enough
solution
that
we
actually
end
up
solving
it.
But
there
is
a
sufficient
sort
of
desire,
at
least
in
my
opinion,
to
identify
that
as
a
problem
that
we
may
want
to
solve
as
such
provide
space
for
us
to
eventually
solve.
E
E
A
E
Then
I
I
don't
think
anything
except
for
maybe
the
didn't
trade
stuff
in
this
list,
at
least
in
my
opinion,
it
doesn't
rise
to
the
level
of
sort
of
definitely
needs
an
addition.
Breaking
change
in
order
to
fix
a
significant
enough
ergonomic
loss
that
we
can't
either
wait
for
three
years
or
however
long.
If
we
don't
do
it
now
or
you
know,
just
don't
have
it
like
sure.
It's
annoying
to
write
out
the
alternative
to
that
else,
but
it's
not
yeah.
E
I
don't
know
how
huge
it
is,
but
I
think
I
think
with
generators
like,
at
least
in
my
opinion,
if
we
don't
add
the
keyword,
then
like
it's
not
the
end
of
the
world,
I
I
don't
think
the
key
word
there
is
the
major
blocker
like.
If
we
end
up
with
a
complete
proposal,
it
ends
up
having
to
be.
You
know,
attribute
until
the
next
edition.
A
E
I
would
definitely
say
that,
at
least
in
my
opinion,
I
don't
think
lane.
Teams
should
spend
time
on
sort
of
trying
to
figure
out
what
they
should.
What
what?
What
proposals
in
this
list
of
the
sort
of
le
house
variety
need
to
be
championed
unless
there
is
sort
of
bandwidth
and
desire
to
drive
that
to
completion.
E
A
So
I
guess
to
close,
I
would
say
thanks,
and
this
was
useful-
to
give
feedback
on
linkedin.
If
there's
things
keep
thinking,
I
guess
think
about
if
this
list
represents
like
for
my
side,
I
think
what
I'm
really
looking
for
is.
I
want
to
start
focusing
in
right
and
I
feel
pretty
sure
that
I'm
going
to
focus
on
these
two
things,
gats
and
infiltrate
and,
to
a
lesser
extent,
some
of
the
other
items
I
would
like
to
have
some
idea
of.
I
think
it
would
be
great
if
we
can
think
about.
A
I
have
to
think
about
this
change,
but
I'm
I'm
leaning
towards
this.
This
edition
question,
I
think,
has
been
the
most
interesting
part
of
the
scenario
moving
against
leaning
towards
well.
If
somebody
comes
with
something-
and
we
have
if
there's
someone
who,
if
there's
a
proposal-
and
we
want
to
move
it
forward-
that's
fine-
I
would
reserve
it,
but
otherwise
I
think
we
shouldn't
and
we'll
make
do.
G
A
A
There's
one
other
thing:
I
want
to
add
that
I
took
out
this
well
never
mind
I'll,
just
write
it
later,
but
it
was
this
lifetime
temporary
lifetimes
question.
I
still
think
there's
a
few
like
minor
things
like
I
don't
know
how
minor
it
is,
but
things
like
and
things
like
drop
order
and
so
on
it
would
be
so
compelling
and
have
to
do
with
async.