►
From YouTube: 2020-09-02 Backlog Bonanza
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
Yeah,
so
right
so
we
would
go
through
and
if,
if
it
seems
like
it's
a
good
idea,
but
the
rfc
isn't
quite
there
or
we're
not
sure
if
it's
there,
then
we
might
suggest
people
to
make
a
project
proposal.
If
we
think
we
want
to
do
the
rfc,
we
should
just
try
to
merge
it.
That's
another
outcome
that
would
be
for
something
where
we
think
it's.
A
We
can
do
it
and
we
think
we
have
people
and
resources,
and
another
thing:
we've
come
across
a
few
times
is
that
something
is
listed
as
lang
team,
but
we
kind
of
feel
like
it's
more
of
a
implementation
team.
It's
really
more
something
for
the
compiler
team
and
should
just
direct
people
over
that
way,
and
I
guess
that
could
apply
to
libs
or
other
teams,
too
makes
sense.
A
D
C
A
C
C
A
A
A
Some
problem,
I'm
trying
to
think
if
there
would
be
some
issues
around
resolution.
How
many
guests
know
I
was
imagining?
Well,
maybe
now
it
was
useful
to
know
that
the
output
of
the
procedural
macro
was
containing
the
full
list
of
items
and
didn't
need
any
recursive
work.
But
I
kind
of
doubt
that,
to
be
honest,
I'm
a
little
surprised.
It
doesn't
just
work
already.
So
I
guess
we
have
to
reach
out
to
patrician
cove.
C
A
I'm
much
more
skeptical
of
eager
macro
expansion
than
I
would
be
of
this,
but.
C
D
D
C
A
C
A
A
D
A
C
A
A
A
A
C
A
C
C
C
It's
not
just
that.
It
also
has
the
concept
of
just
implementing
const
functions
that
involve
traits
or
involve
generic
parameters.
But
yes,
it
does
also
touch
on
how
to
have
a
an
implementation
of
something
on
a
trade
when
you
might
need
const
involved.
A
I
think
my
preference
would
be
that
we
just
merged
this
rfc
right
thumbs
up
thumbs
up
here.
Like
basically,
you
know
just.
A
Yeah
I
mean
we
could,
I
think
it
would
probably
make
sense
to
like
cancel
the
fcp
and
start
a
fresh
one
or
something,
and
maybe
it'd
be
good
to
have
even
a
design
meeting
to
I
would
like
it.
I
think
it
could
be
good
for
the
community
to
do
a
design
meeting
that
has
somebody
lay
out
the
plan
and
lets
us
ask
questions
but
basically
like
if
we're
already
implementing,
I
feel
like
we
should
merge
this
and
call
it
in
the
implementation
stage
and
the
fact
that
it's
not
merged
is
actually
kind
of
unusual.
C
So
a
kind
of
a
point
of
clarification
here,
it's
in
fcp
right
now,
or
rather
it's
in
proposed
fcp
right
now.
It
has
enough
sign
offs
from
lang
team
members
across
the
board.
It's
more.
There
are
two
registered
concerns
on
it.
I'm
that
doesn't
seem
like
the
appropriate
disposition
would
be.
Let's
you
know
close
and
reopen
the
fcp.
It
seems
like
we
should
figure
out
if
those
concerns
still.
C
Apply
it
looks
like
both
of
those
concerns
were
raised
by
boats,
who
is
also
the
only
person
who
hasn't
signed
off
on
this
rfc,
so
I
really
don't
think
it
would
be
appropriate
to
close
and
reopen
which
would
disregard
those
concerns.
I
think
we
need
to
actually
address
those,
so
it
would
yeah.
Github
also
is
terrible
with
respect
to
that
kind
of
thing.
C
I
think
that
it
would
be
appropriate
to
either
set
up
a
design
meeting
conversation
that
includes
boats,
together
with
the
pr
the
proposer
of
the
rfc
or,
alternatively,
set
up
an
asynchronous
discussion
on
zulu
to
the
same
effect
and
try
to
sort
it
out.
That
way,
does
that
seem
appropriate.
A
I
think
that's
the
right
thing
to
do.
I
would
favor
a
design
meeting.
Personally
I
mean
I
want
to
make
time
to
have
these
conversations.
C
A
C
So
well,
I
think
the
next
available
design
meeting
slot
is.
Is
it
one
or
two
weeks
out.
C
A
Right
we're
no
particular
hurry
right
so
like
if
it
needs
to
be
right.
I'm
going
to
open
a
quick
zoolop
discussion
right
now,
just
to
get
that
kicking.
A
A
D
It
looks
like
this
is
either
done
or
probably
doesn't
need
movement
until
the
existing
thing
is
more
used
in
the
ecosystem.
It's
basically
the
raw
rf
macros
that
we
added
except
more
pervasive.
A
A
C
Think
this
was
when
we
still
weren't
quite
sent
quite
sure
what
the
syntax
for
raw
references
would
be.
C
But
yeah
there's
a
desire
to
get
at
a
a
stable
way
to
handle
pointer
to
field.
A
Right
so
this
aims
to
bring
kind
of
parody
to
raw
pointers
and
safe
references
in
terms
of
their
integration
into
patterns.
Basically,.
A
C
Yeah
this
one
is
mine,
and
rather
than
taking
time
to
go
through
it,
this
is
on
my
to-do
list
to
formally
withdraw
this
and
close
it
so
I'll
take
care
of
that
long
story
short.
There
was
a
I'm
still
enthusiastic
about
this,
but
I
don't
have
the
bandwidth
and
there
was
a
massive
amount
of
pushback
on
this.
B
C
Yeah,
would
it
actually
be
reasonable
to
say
that
variatic
gener,
I
mean
those
seem
sufficiently
closely
related,
variatic
generics
and
generalized
tuples
that
we
would
almost
want
to
charter
a
project
group
to
do
both
not
right
now,
because
it's
not
necessarily
a
good
road
map
fit
right.
Now,
I'm
saying
when
we
do.
I
wonder
if
we
should
charter
them
to
handle
both.
A
C
Checklist
yeah,
it's
not
like
people
would.
I
don't
think
I
have
ever
seen.
Somebody
lodge
a
concern
with
an
fcp
bot,
close
sorry
rfc
about
close.
C
Yeah,
I
I
think,
having
rfc
bot
capable
of
doing
something
similar
to
the
mcp
model
of
a
second
and
no
objections
within
x.
Amount
of
time
would
be
nice
and
also
combining
pfcp
with
fcp.
A
A
A
A
Name
dimple
tree
yeah,
the
status
is
that
we
are
likely
to.
I
mean
it's
implemented.
There
are
some
problems
with
how
it
works
with
inference
in
the
more
advanced
cases
I
was
trying
to
get.
A
I
sat
down
with
ali
matthew,
jasper
and
santiago
some
time
back
and
we
carved
out
what
we
thought
was
a
really
useful
like
mvp
and
santiago
was
going
to
try
and
pursue
it
that
didn't
quite
come
together.
Yet
we
should
probably
we
should
probably
like
file
an
issue
or
something
and
see
if
we
can
find
someone.
I
think
there
is
like
an
mvp
that
works
that
allows
you
to
do
a
lot
of
the
useful
use.
A
Cases
like
returning
futures
in
particular,
but
the
most
general
form
of
the
features
still
needs
some
more
complicated
work
in
the
compiler.
C
Yeah,
it
is
as
related
in
so
far
as
historically,
we
do
not
have
a
way
of
getting
the
type
of
an
arbitrary
expression
and
having
a
type
of
mechanism
would
allow
you
to
get
at
the
type
of
an
otherwise
unnamed
type.
So
it
certainly
interacts.
A
Yeah,
I
agree
with
that
and
yet.
C
A
Not
only
that
it's
that
I
think
it's
the
worst
way
to
do
that
thing.
That's
a
too
strong
statement.
What
I
really
mean
is
there
are
some
use
cases,
I'm
I
guess
I'm
specifically
I
don't
want
to.
I
don't
want
to
see
like
where
claus
is,
where
the
way
to
say
that
the
future
returned
by
this
function
is
send.
A
This
involves
writing
out
pseudo
code,
where
you
pretend
to
call
it
with
pretend
arguments
and
stuff
like
that.
I
can
see
that
it's
useful
within
a
function
body
or
something
here
and
there
does
that
make
sense.
B
A
A
A
A
C
I
think
this
is
very
much
the
c
plus
style
pointer
to
member
mechanism
of
how
do
you
get
at
a
field
in
a
general
sense,
a
way
of
getting
to
a
like?
How
do
you
abstract,
over
which
field
you're
accessing
to
something.
B
B
A
He's
got
something
that
they
that
would
be
useful
to
be
able
to
do.
I
wouldn't
want
to
it
seems
pretty
out
of
scope
for
us
right
now,
sort
of
making
traits
for
fields
for
field
access
kind
of,
but
more
like
generalizing
over
the
setter
fields.
D
Sounds
similar
to
the
fields
in
like
type
parameters
and
methods
for
traits
proposals
as
well.
A
D
D
A
B
Yeah,
I'm
sort
of
staring
at
this
thinking
that
if
you
write
a
macro
that
takes
a
field
a
type
and
a
field
name,
you
could
do
some
sort
of
library
type
that
has
the
offset,
invites
from
a
pointer
and
carries
its
type
and
pass
these
around
and
dereference.
C
A
To
do
finish,
read
me:
well,
it's
a
little
hard
to
tell,
but
I'm
guessing
that's
what
they
were
going
for
anyway.
I
I
would
prefer
to
see
it.
Experimentation
done
it
like.
I
agree
with
josh
that
long
term.
This
would
be
a
useful
feature
and
I'm
not
sure
that
macros
are
where
it
should
live,
but
in
the
near
term
I
think
that's
where
it
should
live.
C
That's
actually
another
good
point
is
it
would
be
reasonable
to
ask
someone
to
much
like
what
safe
transmute
did
figure
out
the
smallest
change
to
the
language
that
enables
this
in
a
way
that
is
substantially
better
than
doing
it
as
a
pure
library,
because
the
in
this
context
it's
a
kind
of
a
generic
rfc
that
says
here's
the
net
effect
of
what
we
want
to
achieve
and
in
general
we
do
want
people
talking
in
terms
of
what
problem
they're
solving,
but
I
think
that
this
needs
to
drill
down
to
the
point
of
what
do
you
actually
want
us
to
change
in
the
language?
A
Yeah,
I
agree
this
seems
a
little
bit
like
the
safe
transmute,
like
the
initial
goal
was:
let's
do
that
and
that's
going
to
require
clearly
going
to
require
lang
integration,
but
then
someone
ran
off
and
did
a
bet
experimented
on
the
interesting
parts
and
did
not
like
figure
it
out
with
leaving
the
less
hard-coding
the
relationships
as
needed
right
who
wants
to
write
the
comment.
A
C
So
this
one
was
very
long
and
as
far
as
I
can
tell
very
bike
shedded,
I
remember
some
of
the
details
of
this
and
the
biggest
issue
is:
how
do
you
overload
something
that
is
a
short-circuiting
operator
and
I
don't
recall
exactly
where
it
landed.
One
possibility
was
people
wanting
to
use
a
closure
for
the
right-hand
side,
for
example,
there
are
other
possible
implementations
that
could
work.
C
I
personally
would
like
to
see
this
happen.
Somebody
would
need
to
go
back
and
dig
through
and
figure
out.
Where
did
this
land
and
what's
the
concrete
proposal,
I
recall
there
was
at
least
one
proposal
which
I
hope
isn't
where
it
landed.
That
involved
a
two-phase
thing
of
call.
This
function,
this
trait
function
and
then
that
trait
function
passing
the
result
of
one
to
the
other.
I
think
that's
less
ideal
than
just
passing
a
closure,
but
in
any
case
I
think,
there's
value
in
this.
C
I
think
it's
also
very
self-contained
in
that
I'm
trying
to
think
of
how
to
describe
this.
I
don't
see
how
this
would
touch
substantial
other
fractions
of
the
language.
In
order
to
do
it
would
require
a
localized
change
in
the
handling
of
and
expansion
of
operators,
but
it
doesn't
seem
like
it
would
touch
parts
of
the
language
compiler
outside
that
it's
just.
How
do
we
expand
an
operator.
B
There
was
one
one
thing
that
central
mentioned
in
here.
I
recall
that
was
interesting,
that
overloading
these
things
gets
a
little
weird
when
one
of
the
sides
of
the
overload
can
be
the
let
in
an
if
left
chain.
B
C
B
C
You're
not
going
to
be
able
to
overwrite
it
for
yeah
you're
not
going
to
be
able
to
overwrite
it
for
bool,
and
we
have
not
yet
implemented
let
chaining
when
we
do.
Theoretically,
you
could
have
your
own
operator
for
say
bool
or
my
type
or
bool
and
my
type,
but
I
don't
see
any
reason
why
it
would
be
an
issue
to
say:
let
chaining
doesn't
support
operator
overloads
yet
or
doesn't
support
non-built-in
types
yet
or
something
because
at
the
end
of
the
day
the
type
has
to
be
bool
for.
B
C
A
C
I
think
it
would
be
fine
to
say
for
now
that
let
chaining
doesn't
exist
yet,
but
when
it
does,
then
we
don't
have
to
on
day
one
handle
operator
overloading
for
this,
because
it
can
just
only
handle
bools.
B
C
C
It
is
an
orthogonality
issue
in
that
you
can
overload
everything
else,
but
you
can't
overload
these
and
I
think
there'd
be
value
in
improving
that,
but
that
does
not
mean
that
it
has
to
be
done
in
the
near-term
future.
It
would
be
useful,
but
I'm
also
not
seeing
anybody
clamoring
for
this,
for
a
concrete
reason
that's
needed
in
the
short
term.
It's
just.
It
would
be
desirable.
A
A
A
B
A
C
C
It
seems
like
a
big
part
of
what
we're
trying
to
do
both
here
and
with
the
project
groups
proposal
is
to
stop
needing,
like
laying
team
time
proportional
to
the
complexity
of
a
particular
proposal
and
instead
push
that
time.
A
I
I
think
it
comes
to
the
question
of
how
localized
this
really
is
and
it's
hit
it
might
be,
but
it's
sort
of
triggering
some
kind
of
punch
on
my
part
that
it
will
not.
It
will
not
be
localized,
it
will
encounter
a
lot
of
what
do
you
call
it
there'll
be
a
lot
of
bike
shed
that
we'll
have
to
wade
into
and
our
opinion
and
settle
it
and.
B
A
Yeah
I
have
to
run.
I
have
a
call,
so
I
don't
know
we
can
leave
this
and
reopen
it.
If
we
want,
we
open
the
discussion.
A
I
think
I
would
feel
better
about
this
if
we
had
made
more
progress
in
the
like,
like
if
we
had
really
felt
like
we
had
the
project
groups
working,
and
we
had
enough
experience
to
know
how
much
this
can
be
done
on
the
side,
but
we
kind
of
don't.
I
don't
feel
like
it's
a
good
test
run.
I
think
that's
what
it
comes
down
to.
A
A
I
will
note
that
when
we
initially
added
overloading,
we
very
explicitly
left
those
out
because
it
was
deemed
undesirable
to
make
control
flow
subject
to
overloading.
I'm
not
sure
if
I
agree
with
that
call,
but
there
is
a
there
is
a
case
to
be
made
around
it.