►
From YouTube: Backlog bonanza, part 2
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
A
A
A
B
A
A
A
B
B
A
A
A
B
A
B
A
Right,
so
I
think
that
the
design
is
probably
roughly
right
and
it
went
through
already
an
extensive
internals
process.
However,
I
have
some
concerns.
Like
it's
a
large
implementation
effort,
I
think
it's
a
stale
sort
of
a
stale
community
so
to
speak
like
right
with
a
lot
of
action,
but
now
it's
old
and.
A
A
Right,
in
fact,
we
could
revive
that
community,
but
I
guess
what
I'm
saying
is:
I
would
be
hesitant
to
merge
in
until
we
not
because
of
the
design,
but
because,
like
more
of
the
project
management
side
of
this,
like
is
this
a
project
we
want
to
take
on
now,
and
will
we
have
the
energy
to
see
it
through
and
so
forth
right
and
how
does
it?
What
is
it
in?
What
way
does
it
fit
our
priorities
of
closing,
finishing
up
old
work
and
seems
like.
B
B
A
A
A
B
Over
we
could
absolutely
like
poke
the
thread
and
say
we
talked
this
over.
We
think
this
might
be.
You
know,
despite
the
time,
lag
something
that
we're
interested
in
merging
here's,
some
minor
notes
and
are
people
still
around
and
interested
in,
seeing
this
merged
and
willing
to
do
implementation
work.
Let
me
let
me
talk
about
this
a
different
way.
I
feel.
A
A
Size
and
size
of
effort
that
is
in
flight
and
just
having
too
many
big
things
in
flight
like
major
additions
to
the
language
and
so
on,
seems
sub-optimal.
So
I
don't
know,
I'm
I'm
just
a
little.
That's
more
the
perspective
I'm
coming
out
of
like
you
can
poke
the
thread
and
definitely
say
we're
still
interested,
but
I
would
also
want
to
see
how
what
we
see
with
the
other
things.
So
maybe
we
should
move
to
those
other
things
and
come
back,
but.
A
B
B
I
mean
in
general,
I
think
most
rfcs
on
this
list
are
likely
to
be
opening
new
areas
of
work
rather
than
closing
previous
things
unless
they're
things
we're
already
working
on.
So
if
we
don't
feel
like,
we
have
the
bandwidth
to
do
new
things
right
now.
I
think
that
the
answer
to
almost
all
of
these
is
going
to
be
not
right
now
and
I'm
not
sure
that's
where
we
want
to
be.
B
I
guess
this
feels
like
a
relatively
small
addition
anyway,
fair
enough
moving
on
to
2442
for
the
moment,
so
this
one's
mine-
and
I
opened
this
because
I
felt
like
it
would
answer
a
lot
of
different
things
that
were
going
on
at
the
time.
It
also
interacted
with
a
weight
syntax
which
has
now
been
resolved,
so
that's
no
longer
applicable.
B
If
we
offered
a
new
kind
of
postfix
macro,
but
I
think
there's
enough
value
in
this
and
in
particular
enough
value
for
the
ability
to
experiment
with
interesting
new
syntax
like
let's
see
what
dot
match
would
look
like
or
what
dot,
if
would
look
like
or
dot,
four
would
look
like
and
be
able
to
experiment
with
that.
I
think
there's
value
in
that,
and
there
was
dispute
on
the
language
team.
B
B
B
B
A
A
B
A
A
A
A
A
I
think
I've
previously
been
in
favor
of
type
based
dispatch
also,
but
I
think
I'm
now
in
the
not
in
a
camp
yet,
but
I
see
the
appeal
of
like
okay,
that
does
sound
cool,
but
we
have
to
wait.
We're
gonna
have
to
wait
for
years
to
ever.
You
know
he
may
never
really
do
that,
but
we
could
do
this
today
and
there's
a
lot
of
stuff
people
want
to
do
with
it
and
it
would
mostly
work
just
fine
and
I
think,
that's
probably
true,.
A
A
A
A
B
I
think
it's
likely,
I
will
say
this.
I
absolutely
think
it
should
stay
nightly
only
with
a
feature
flag
for
quite
some
time,
not
just
because
of
how
it
interacts
with
other
bits
of
the
language
and
whether
the
feature
itself
was
stable,
but
because
a
critical
part
of
this
is,
let's
see
how
people
in
the
ecosystem
make
use
of
it,
and
if
what
we
see
looks
really
interesting,
that
may
be
compelling
and
if
what
we
see
is
really
horrifying,
we
might
want
to
say
you
know
what
nope.
B
B
A
B
There
was
a
bunch
of
discussion
on
this.
I
remember
because
I
was
in
that
discussion
and
I
think
one
of
the
big
points
of
dispute
on
this
one
is
should
can
cat
do
this,
or
should
we
have
a
can
cat
bites?
That
does
this
so
that
it's
type
safe.
I
very
much
argued
we
shouldn't
have.
Can
cat
like
do
different
things
based
on
its
arguments.
We
should
have
two
different
types,
but
otherwise
I
think
it's
perfectly
fine
to
have
a
thing
that
does.
B
A
B
A
A
B
B
B
Yeah
reading
the
section
on
better
naming
of
unnameable
types,
it
sounds
like
this
is
effectively
type
alias
infiltrate
without
having
to
name
all
the
traits
and
instead
just
having
the
compiler
infer
them.
That
seems
like
global
type
inference,
and
my
first
instinct
is
to
say
we
really
don't
want
this.
C
A
A
A
You
know
my
mind
but
such
that
it
gets
inferred
like
because
this
method
returns
a
self
item
you're
allowed
to
you
don't
have
to
like
do
repeat
yourself.
The
main
reason
I
think
I
would
like
that
is
that
it
ties
into
well
just
because
it
seems
like
repeating
yourself,
so
it's
related
to
this
rfc,
but
different,
because
it
could
be
a
much
more
limited
special
purpose
feature
if
we
ever
label
it
anyway.
I
think
this
stupid,
maybe
a
good
idea,
but
we
should
lay
the
groundwork
first.
D
B
I
think
that's
a
reasonable
question,
because
this
use
case
sounds
completely
justified
to
me
and
the
idea
of
change
the
thing
that
is
dependent
on
the
generic
type
and
keep
all
the
other
fields.
That
aren't
seems
completely
reasonable,
but
changing
from
one
entirely
unrelated
struct
type
to
another,
because
the
fields
happen
to
match.
B
A
A
A
A
I
guess
I
think
I'll
have
to
look
at
what
the
inference
does.
My
expectation
would
be
that
you
make
fresh
inference
variables
for
all
the
generics
you
assign
the
type
of
the
fields
that
were
given,
and
then
you
assign
the
types
of
the
fields
that
came
from
the
construct
that
you
have
the
dot
dot
with
like
the
ones
that
are
not
listed
explicitly
and
that
should
fully
constrain
like
that.
Should
just
be
it.
A
A
A
B
B
A
B
C
A
A
A
A
A
B
Yes,
this
there
have
been
several
variations
of
this
one.
I
feel
like
I've
filed
one
of
them,
and
this
is
another
one
and
they
pretty
much
boil
down
to
you
shouldn't
have
to
count
the
number
of
things
in
your
initializer
and
put
that
number
into
the
size
of
your
array.
You
should
be
able
to
write,
underscore
and
have
the
compiler
say
I'll.
Look
at
how
long
your
string
is,
or
I
will
look
at
how
long
your
slice
is.
B
B
A
A
A
C
A
A
A
Nonetheless,
I
think
that's
how
I
would
expect
to
implement
a
more
general
version
in
the
future.
Yes,
but
I
think
like
it's
not
only
that,
but
it's
like
that's
how
actually,
how
it's
hard
for
me
to
imagine
how
we
would
implement
this
in
the
compiler
without
leveraging
const
generics.
So
I
think
what
we
would
probably
do
is.
We
would
create
a
constant
inference
variable
for
that
underscore
and
we
would
handle
the
type
you
know
and
and
then
read
out
what
value
we
got.
A
A
A
A
A
A
A
A
A
A
A
A
C
A
A
A
And
maybe
it's
just
going
to
be
comments
in
the
rfc,
but
I
think
it
would
be
nicer
if
we
had
like
maybe
on
the
lane
team
website.
I've
always
dreamed
that
for
these
ideas
we
can
kind
of
write
up,
write
up
these
concerns
and
thoughts
and
then
link
to
the
rfc
like
in
shorthand
form,
but
so
that
you
can
easily
remember
wait.
What
was
the
major
concern
of
that?
Oh
right.
B
A
A
A
A
D
D
A
A
A
A
A
A
It's
interesting
I'm
reading
simone's
comments
here.
The
2019
road
map
includes
finnish
long-standing
dangers.
I
argue
resolving
a
1.0
tracking
era
issue
fits
into
that
discussion.
That
actually
sounds
like
a
reasonably
good
case,
but
basically
he
was
kind
of
saying
look.
I
did
the
work
of
trying
to
make
the
intersection.
A
You
know
the
forward
compatible
intersection
of
so
we
don't
have
to
solve
the
hard
problems,
but
we
can
solve
the
easy
ones
right
and
then
we
should
do
that,
and
I
agree
with
that
concept,
but
I
think
the
right
thing
I
have
to
reread
it
now.
I
remember
thinking
when
I
read
it
last
time
that
it
didn't
really.
A
A
B
A
A
A
B
A
A
A
A
D
A
They
were,
we
have
a
challenge
to
figure
out
what
is
the
canonical
representation,
but
maybe
they
get
sorted,
but
that's
you
know
so
anyway.
My
point
is,
it
doesn't
add
a
fundamental
capability,
so
union
is
requiring,
like
unsafe
guidelines,
interaction,
all
kinds
of
interaction
which
is
fine
because
we
needed
that.
But
this
doesn't
this
one
isn't
as
bad
as
that
in
terms
of
touching
everything,
but
also-
and
by
the
same
token,
it's
not
as
important
as
that.
A
B
A
A
A
A
C
A
I
was
just
gonna
say:
I'm
not
sure
whether
one
thing
I
would
want
to
consider
in
in
that
is
conditions,
and
whether
like
this
is
something
we
might
face
in
across
an
addition
boundary.
If
there
are
some
ways
that
we
can
make
inference,
behave
better
that
wouldn't
be
strictly
backwards
compatible,
I'm
not
sure.
B
I
think
we
should
ask
for
a
project
proposal,
because
we
want
to
ask
somebody
to
commit
to
shepherding
it
all
the
way
through
the
process
like
be
there
as
the
champion
of
the
rfc
to
talk
to
the
implementer
or
potentially
be
the
implementer.
Considering
that
varcour
was
the
one
to
propose
it
and
they
certainly
know
the
compiler.
B
A
I
think
that
I
wanted
to
have.
I
wanted
to
go
through
the
project
process
and
I
want
to
have
us
like
talk
about
it,
freshly
and
get.
You
know
what
I
mean.
I
don't
want
to
just
like.
Take
some
stale
rfc
and
approve
it
and
then
make
a
tracking
issue
and
call
it
done,
and
I
would
rather
that
we
try
to
do
it
in
a
more
healthy
way
and
have
somebody
who's
going
to
see
it
through
and
so
forth,
and
so
it
might
be
that
that
also
involves
changes
to
the
design.
B
B
A
B
I
just
wanted
to
mention
before
we
moved
on
there's
a
quick
note
about
the
whole
like
enums
are
regularly
talked
about
the
other
facet
of
this
that
keeps
getting
talked
about,
and
I
I
feel
like
there
is
definitely
a
we
should
talk
about
this
as
a
problem
before
seeing
solutions.
Kind
of
thing
going
on,
there's
been
like
three
variants
of
a
discussion
on
internals
about
anonymous
enums,
which
basically
amounts
to.
B
If
we
want
to
do
this
or
if
there's
another
solution
for
the
same
problem,
I
just
bring
it
up
because
there's
a
lot
of
internals
discussion
and
I
feel
like
there
hasn't
been
any
serious
lane
team
discussion
of
it.
It's
true
and
I
don't
want
to
end
up
in
another.
One
of
those
situations
of
somebody
does
a
ton
of
work
before
there
is
any
blank
team
feedback.
D
It
does
seem
like
that
sort
of
area
where
there's
sort
of
a
really
wide
solution
space
and
we're
not
even
sure
we
want
to
explore
the
we
might
want
to
explore
the
solution
space.
But
we
don't
know
if
we
want
to
identify
solutions
and
implement
them,
is
sort
of
the
exact
intent
behind
project
groups.
Exactly.
B
A
A
So,
a
long
time
back,
we
were
like
one
of
the
first
rc's
was
to
out
of
something
we
called
virtual
struct
at
the
time
which
was
not
popular,
and
then
it
was
kind
of
an
attempt
to
get
make
it
make
you
able
to
model
like
the
dom
essentially
more
efficiently
in
rust,
which
is
still
a
problem,
still
an
unsolved
problem,
and
so
there
was
because
it
was
so
popular.
We
pulled
it
back,
but
then
we
sort
of
solicited
rfcs
and
there
were
four
or
five
competing
rfcs,
aiming
at
the
same
design
space.
A
A
A
B
I
think
we
need
one
coherent
project
proposal
here
and
we
can
let
the
project
group
evaluate
things
like
you
know.
What
are
the
trade-offs
between
having
a
new
opt-in,
built-in
trade
versus
having
a
separate
trait
versus
all
sorts
of
other
ways
this
could
be
handled.
I
know
we
had
a
half
dozen
different
discussions
on
this,
so
I
would
say.
A
A
A
Maybe
we
want
to
have
a
list
of
like
open
problems
like
that's
more,
this
lengthy
page
I
keep
talking
about.
I
think
part
of
the
reason
I
would
like
it
is
that,
when
we're
thinking
about
what
to
do
next,
we
should
consult
it
and
be
like
here
were
some
ideas
and
some
of
the
summaries
which
of
these
do,
we
think
are
any
of
these
like
something
that
seems
like.
The
time
is
right.
A
B
A
B
Like
I
see
people
on
chat,
for
example,
writing
this
as
a
quick
note
and
then
realizing.
Oh
right,
that
doesn't
actually
work
and
I
think
because
people
are
used
to
things
like
config
things
where
it
does
tend
to
work
or
derive.
Actually
is
a
really
good
case
where
you
can
write,
derive
trait
1,
trait
2,
trait
3,
trait
4,
and
this
is
the
kind
of
thing
where
the
same
kind
of
thing
at
the
top
level
feels
like
it
ought
to
work.
But
it
doesn't.
A
B
It
doesn't
so
it
doesn't
exactly
need
design
work.
The
one
thing
that
has
to
happen
before
this
could
be
merged
is
somebody
needs
to
very
carefully
review
the
token
stream
specification
for
how
does
this
interact
with
like
attribute
proc
macro
other
attributes?
What
does
it
expand
to
and
what
tokens
does
each
one
get.
A
B
A
Yeah,
I
think
that's
like
I
feel
like
if
we
open
the
project
proposal,
that's
sort
of
what
I
would
argue
for
is
I
don't
expect
procedural
macros
in
particular
are
an
area
where
I
feel
like
we're
under
we
have.
We
are
right
under
strong
strength
and
it
we
need
to
move
carefully,
and
this
doesn't
seem
worth
it.
B
B
B
I
think
this
part
of
the
proposal
is
theoretically
syntactic
in
that,
like
we're
not
specifying.
Yet
what
the
semantics
of
what
these
things
are,
we're
saying
that
you
can
parse
them
and
then
that
would
allow
a
proc
macro
to
deal
with
them
and
then
separately
we
could
spec.
Some
of
those
out
like
this
opens
the
door
to
being
able
to
say
that
a
function
pointer
has
a
wrapper,
or
some
you
know
attribute
in
a
some
parameter
in
a
closure,
has
a
wrapper
or
something
along
those
lines.
A
A
A
B
A
A
B
B
I
think
my
inclination
would
be
similar
to
the
previous
one,
which
is
concept,
seems
okay.
There
are
some
practical
considerations
in
this
case:
ambiguity,
issues
in
the
grammar
and
because
of
that,
we
would
want
to
see
this
come
through
as
a
project
proposal
with
somebody
who
is
prepared
to
put
a
great
deal
of
grammar
work
in,
but
not
opposed
kind
of
mildly
in
favor.
But
we
want
to
postpone
anyway,
because
complications.
B
A
B
2633
ff5
returns
twice
for
specking
functions
like
long
jump
and
sorry
set
jump.
We
now
have
an
ffi
unwind
working
group
that
is
currently
working
on
the
concept
of
plain
old
frames,
and
when
can
you
use
set
jump?
I
think
it's
really
clear
that
the
correct
disposition
for
ffi
returns
twice
rfc
is:
please
work
this
through
the
ffi
unwind
working
group,
which
is
actively
discussing,
set,
jump,
long,
jump
and
unwinding
right
now,
yeah.