►
From YouTube: 2020-04-27 Design Meeting (more edition planning)
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
Okay,
I
created
this
you'd
have
a
project
thing
which
I
always
try
to
use
and
I
always
fail
to
find
a
lot
of
value
in,
but
I
was
thinking
that,
maybe
to
help
us
track
the
overall
like
and
overall
view
of
what's
going
on,
it
may
actually
not
be
the
worst
UI.
Obviously,
I
just
put
a
dummy
thing
in
here,
but.
A
We've
talked
a
lot
about
having
sort
of
a
place
where
people
can
go
and
get
an
overview.
What's
going
on,
I
think
it'd
be
helpful
for
us
to
to
be
able
to
say
like
here
are
the
projects
that
are
active
near
some
that
are
stalled
out,
or
you
know,
and
with
links
it's
kind
of
a
tracking
issue.
I
guess
so.
Maybe
it's
better
to
just
make
tracking
issues
named
today,
but
I
wanted
to
go
and
toss
it
out
there
for
thought.
A
I
think
we
should
be
able
to
would
make
it
if
we
kind
of
had
a
good
list
like
this.
Here's,
the
things
and
here's
the
ones
we're
focusing
on
and
here's
the
ones
we're
not
right
now
and
and
some
notes
on
why
I
think
we
sort
of
don't
at
the
moment
have
a
central
place
where
we
can
observe
that
information
I.
B
So
that
interface,
you
showed
the
project
you,
the
main
benefit
I
see
of
it
is
that
it
gives
you
a
sort
of
two
dimensional
view
of
the
status
of
many
things
at
once
in
terms
of
the
the
issues
themselves,
without
the
ability
to
encode
much
metadata
about,
like
you
know,
discussion
or
those
supporting
text
describing
the
status,
because
that
would
perhaps
defeat
the
purpose
is
that
accurate,
I
think.
A
A
A
A
Yeah,
we
definitely
got
through
medium
Linse
and
so
forth.
A
C
A
Let's
discuss
these
briefly
but
not
spend
too
much
time,
I'm
gonna,
put
a
say,
15
minutes
and
then
start
looking
at
the
new
or
other
aims.
So
I
did
look
a
little
bit
in
band
bindings
and
life
time.
The
elision-
I
refresh
my
memory
here
a
little
bit
so
the
in
band
bindings
their
own
doesn't
remember,
is
you
didn't
have
to
declare
a
lifetimes
explicitly,
we
kind
of
inferred
their
scope
from
where
they
were
used
and
there
were
various
details.
A
A
A
The
main
concern
here
was,
if
you
scroll
down,
there's
and
that
comment
summarizing
it
that
there's
a
sort
of
surprising
ish
interaction,
I
mean
elision
at
the
function
level,
where
this
return
type
refers
to
one
of
the
parameters
and
elision.
But
you
might,
you
might
expect
if
you
wrote
self
code
like.
Basically,
if
you
write
self
:
:
item,
you
get
this
type,
and
this
allusion
refers
to
that
lifetime
and
everything
works.
A
But
if
you
inline
the
definition,
then
this
ampersand
T
now
refers
to
here
and
not
to
here,
and
so
you
get
an
error
about
having
the
wrong
world
lifetimes
here
and
I
can
attest
that
we've
been
working.
Someone
I
know
like
Esteban,
has
been
working
on
trying
to
get
the
error
messages
in
the
compiler
better.
In
scenarios
like
this,
and
it's
really
hard
I
kind
of
explain
to
people
what's
happening
in
a
concise
way
and
I
guess
it
would
be
I,
don't
know
if
this
I
guess
I
wouldn't
make
that
harder
or
easier.
A
D
C
D
A
D
A
Yeah
I,
don't
think
it's
gonna,
really
I,
guess
I.
Don't
think
this
scenario
is
that
common
that
it's
gonna
really
dramatically
change
my
desire
for
a
lighter
wave
solution,
but
I
also
kind
of
feel
like
the
most
pressing
problems.
I,
don't
know.
I'm
not
trying
to
get
in
beyond,
doesn't
feel
like
it's
solving
the
most.
It's
neither
the
most
pressing
ergonomic
problem
nor
a
particular
enabler
to
my
mind,
I
guess:
that's
what
it
comes
down
to
so
and
then
claim
to
hold
off
a
little
bit.
Yeah.
D
A
A
That
I
feel
like
this
ergonomic
I,
guess
I'd
like
to
understand
better
what
we
think
around
borrowing
and
so
on.
The
most
pressing
economic
problems
are
to
address
and
it
would
be
nice
if
we
had
a
strategy
like
we
want
to
make
at
some
point.
I
did
have
a
a
I'm
like
I
want
to
make
it
so
that
writing
a
you
know
reader!
Well,
look
at
that!
A
E
A
D
A
B
A
A
One
thing
I
might
bring
up
it's
more
of
an
implementation
thing,
but
we
had
some
existing
RFC's
most
notably,
he
gets
to
two
to
nine
that
that
the
talks
about
capturing
of
actually
this
is
edition
related
like
enclosures.
A
C
C
So,
in
addition,
we
could
change
that
drop
order,
which
is
unlikely
to
be
readily
observed.
I
mean
you
could
tell,
but
code
is
unlikely
to
care.
It's
doing
something
like
this,
but
in
a
non
edition.
Technically
there
might
be
code
out
there,
especially
unsafe
code,
which
might
be
paying
close
attention
to
this.
Yes,.
A
I
mean
I
would
be
I
would
definitely
not
be
okay,
with
changing
the
visible
semantics
outside
of
an
edition.
Let's
say
inside
I
think
I'm.
Definitely,
okay
with
it,
but
I
do
have
not
not
entirely
sure
what
what
we
would
like.
We
probably
how
much
like
less
fix
to
war
that
or
something
yeah
they
could
go
upgrade
yeah
like
I,
might
want
that
when
you
upgrade
we
up,
we
change
your
code
to
something
like
this
and
actually
for
some
other
weird
constructs.
A
It
actually
preserves
the
semantics
by
like
kind
of
separating
out
the
path
so
that
you're
accessing
first
foo
and
then
buddhabar
I,
don't
know,
that's,
probably
not
what
we
would
actually
do.
It
probably
be
like
les
fous
equals
foo
or
something
right,
and
then
that
would
be.
That
would
preserve
the
actual
semantics,
but
any
new
code
you
wrote,
would
work
the
new
way,
and
maybe
you
can
go
back
after
and
clean
up
these
on
your
own.
A
B
A
C
B
A
A
C
A
C
Curious
is
there
value
in
considering
a
more
general
change
if
we're
thinking
of
doing
this
anyway,
something
along
the
lines
of
please
stop
caring
about
drop
order
already
is.
Would
there
be
value
if
we're
going
to
make
a
change
like
this
anyway,
in
just
gratuitously,
saying
you're
no
longer
allowed
to
care
what
order
things
get
dropped
in
if
you
care
call
drop.
A
That's
obviously
not
tenable,
like
that,
would
be
a
massive
change
to
the
language,
but
I
think
there
might
be
more
other
variants
that
we
could
consider
like.
You
could
have
a
opt-in
trait.
That
indicates
that
the
compiler
can
reorder
your
drops,
for
example,
that
makes
sense,
and
then
we
can
implement
that
for
all
our
standard
library
types
this
is
this
came
up
around
they
sink
because
we
were
having
the
problem
that
you
remember.
We
made
temporaries
lifetimes
in
a
sink
match,
temporary
look
times
everywhere,
and
then
that
started
introducing
some
cases
where
now
yeah.
C
B
C
A
Dearly
love
to
solve
that
problem,
I,
don't
like
why's
the
technique,
it's
a
different
problem
like
so
here.
What
we
plan
to
do
is
basically
change
how
closures
these
figure
themselves,
so
it
doesn't
really
change
the
borrowed
checker
in
some
sense
anyway,
whereas
the
method
problem
does
because
it
requires
to
barter,
doesn't
look
outside
of
a
single
function
right
now
and
you
could
have
to
think
about
how
does
that
here
in
the
function?
Signature
effective
are
technically.
C
Couldn't
it
be
a
B
sugar
as
well?
You
could
say
that
you
have
written
this,
takes
ampersand,
mute
self,
but
really
you're,
taking
these
two
things
and
you're
just
internally
changing
the
calling
convention
of
the
private
method
to
pass
a
couple
of
private
beautiful,
borrows
and
then
a
caller
just
has
to
know
that
and
say:
oh
I'm,
really
passing
ampersand
mute,
Southby
and
ampersand
mute
self
dot,
D
and
then
the
borrow
checker
will
just
do
the
right
thing
with
that
D
sugar,
I,
considered.
A
That
at
some
point,
I
think
it
could
be
potentially
done.
It's
tricky
because
of
recursive
functions
and
yes,
I
think
it
wouldn't
be
my
preferred
solution.
I
would,
rather,
that
we
try
to
solve
it
in
a
way
that
we
at
least
explore
what
it
wouldn't
look
like
to
solve
it.
You
know
a
first-class
way
where
the
user
could
explicitly
declare
it
without
overhauling
their
signatures,
but.
C
It
would
be
very
nice
to
solve,
if
you
think,
it's
too
different
from
capturing
enclosures,
that
we
won't
be
able
to
do
it
in
a
tissue
and
that's
another
question.
But
if
there's
any
chance,
we
could
do
that
by
this
addition,
because
then
it
be
a
coherent
story
of.
In
general,
we
made
the
borrow
checker
better.
A
Yeah,
which
were
basically
raises
a
point,
I
think
it's
it
sufficiently
different
that
it
should
be
thought
of
as
follow-up
work,
but
I
think
it's
an
interesting
point,
another
bit
of
work,
which
I
don't
really
want
to
go
much
into,
but
polonius
sort
of
NL
2.0.
So
to
speak,
it's
making
some
like
me.
A
lot
of
progress,
I
haven't
really
been
following.
A
I
mean
we've
been
kind
of
slow
moving
forward
and
I
haven't
been
as
involved,
but
it
does
fix
certain
problems
like
returning
mutable
references.
There's.
Definitely
like.
C
C
C
A
It
doesn't
have
any
we're
current
we're
currently
in
the
phase
of
trying
to
like
completely
we
implement
the
borrow
checker
that
this
approach
loads
to
bear,
but
it's
not
there.
So
we,
the
first
step,
was
get
all
those
stuff
working
and
the
next
step
was
going
to
be
optimized
I
think
it's
a
significant
amount
of
work
that
remains,
but
there
aren't
like
a
lot
of
I.
Don't
think,
there's
really
that
many
complex
sort
of
theoretical
questions,
it's
more
of
an
engineering.
A
All
right,
let's
skip
down
a
little
bit
type
privacy,
private
and
public
lands
actually
want
to
skip
over
this.
Although
unless
we
below
and
talk
about
it,
lunch
I
didn't
look
at
the
status
I
want
you
to
talk
a
little
bit
about
like
these.
Maybe
some
of
these
bigger
questions,
there's
a
variety
of
things,
we're
big
and
similar.
Nothing
we're
at
30
minutes.
C
A
So
there's
this
traditional
quirk
in
our
temporary
lifetime
rules
that
basically
the
gist
of
it,
is
that
in
general,
when
you
make
a
temporary,
it
gets
freed
within
the
statement
so
sort
of
by
the
next
semicolon.
Unless,
with
a
special
case,
that
somebody
is,
if
that
temporary
is
immediately
being
assigned.
A
To
a
variable,
then,
it
gets
extended
to
the
end
of
the
block
and
then
there's
one
other
interesting
quirk,
which
is
that
the
tail
expression
of
a
block
is
sort
of
considered
to
be
outside
the
block
for
the
purposes
of
where
the
temporary
goes
right.
So
the
next
semi,
in
other
words,
if
this
were
to
get
freed
by
the
next
semicolon.
That
would
be
here
after
the
variables
in
the
block
are
freed.
A
C
A
A
C
A
Yeah
I
actually
think
we.
This
could
continue
to
compile
depending
on
what
rules
we
did,
because
the
idea
is.
If
we
can
see
sort
of
by
the
structure
of
the
program
that
this
reference
is
going
to
end
up
in
the
variable
X,
we
will
extend
it
to
the
end
of
the
block
that
encloses
X
and
that's
exactly
why
it
works
today,
and
it's
probably
what
would
happen
there
was.
There
is
the
one
other
thing
that's
relevant,
which
is
RFC
number
66
point
of
the
oldest
completely
unimplemented
RC.
A
A
Something
like
that,
but
and
reason
for
that
this
doesn't
compile
today
is
because
you
make
a
temporary
here.
The
temporary
is
parameter
this
function,
so
it's
going
to
get
freed
at
the
semicolon,
which
means
that
it
can't
live
as
long
as
the
variable
X
get
a
lifetime
error.
But
what
this
RFC
said
was
if
you're
calling
a
function
like
trim
that
sort
of
returns
a
reference
and
that
reference
is
getting
assigned
to
X
and
the
reference
comes
from
a
parameter
and
we
look
for
the
parameter
it
comes
from
and
we
extend
that
temporary
as
well.
C
A
So
I
could
definitely
see
any
nice
effects
at
least
doing
rc6
degrade
these
maybe
investigating
this
other
change
and
seeing
what
its
impact
would
be.
I
think
I've
seen
over
66
as
far
as
I
know,
is
backwards.
Compatible
tweaking
temporary
lifetimes,
wouldn't
be
for
the
same
reasons.
You
know
the
effects
when
destructors
run
there.
C
A
C
Yeah
I
think
this
would
be
welcomed
if
we
managed
to
tell
one
big
coherent
story
with
it,
even
if
some
of
them
are
not
necessarily
tied
to.
In
addition,
if
we
use
the
addition
to
say
we
did,
you
know
eight
things
related
to
making
the
borrowed
checker
accept
more
correct
programs
bonus.
If
those
things
include
polonius
phrasing.
B
Though,
except
more
correct
programs
implies
that
we
aren't,
including
any
breaking
changes
which
some
of
these
things
were
so
I.
You
know
I
just
wanna
be
clear
upfront
about
whether
we
are
actually
like
it's
a
mystery.
Witness
end
is,
you
know,
we're
just
so
I
strike
something
more
correct
programs
then.
C
C
A
C
A
B
That's
a
good
question
it's
my
reading
of
this
is
that,
like
you,
can
have
inner
FN
items
and
they
can
appear
after
their
usage
points
and
I
thought
constants,
like
you
said,
not
flat
top
a
little
item,
but
it's
it
is
a
top
little
item
in
sense
of
it's
like
FM.
It
just
happens
to
appear
in
the
scope
of
it
out
or
FM
right.
B
C
C
C
B
D
C
A
Put
in
error
functions
after
because
usually
they're
like
helper
details
and
I'd
rather
have
them
or
at
the
end,
the
person's
up
front.
It's
kind
of
like
bottom-up,
but
I
also
tend
to
avoid
inner
functions
nowadays,
but
I
don't
know,
I
don't
have
a
lot
of
appetite,
but
I
I
would
be
more
I.
Guess
I'd
like
to
I.
C
C
Don't
think
that
was
me,
but
I
agree
with
that
statement.
There
might
be
value
in
reminding
people
hey.
Let
is
not
let
mute.
Perhaps
you
want
a
let
here
if
you're
going
to
try
to
redefine
it,
I
mean
at
the
minimum.
If
you
do
something
like
Const,
X
and
then
later
constant
X,
if
you
get
a
redefinition
error,
perhaps
they
can
say,
maybe
you
wanted
a
limp,
considering
you're
inside
a
function
if.
B
D
A
A
A
A
Could
I
was
gonna
mention
that
one
reason
to
limit
nested
items,
especially
impulse,
as
is
murder
here,
is
to
make
IDs
jobs
easier,
but
I
feel
like
I,
don't
know
the
most
we
would
do
is
probably
like.
This
is
an
easy
thing
to
implement
and
the
most
you
would
do
is
leant
against
it
right.
You
probably
wouldn't
go
straight
to
a
hard
error
or
something.
B
A
Mean
you
know,
the
hope
would
be
that
IDs
in
the
future
can
like.
We
can
migrate
this
enough.
That
ID
is
just
if
you
have
been
pulled
in
the
wrong
places
and
okay,
that's
going
like
autocomplete
and
stuff
doesn't
work,
and
you
probably
want
to
migrate
to
the
newer
edition
room.
Stop
doing
that.
But
that
may
or
may
not
be
a
viable
plan
and
immature
to
me,
but.
A
E
A
C
Side
of
this
is,
if
we
were
going
to
try
to
handle
this,
it
seems
like
it
would
be
a
special
case
of
a
more
general
problem
should
Impuls
have
scope
like.
Should
there
be
such
a
thing
as
a
pub
in
Pole
versus
a
non
pub
in
PO
versus
a
pub
pray
temple
inside
this
crate
you're
allowed
to
use
this
as
debug
or
display
or
I'm,
not
suggesting
you
should
be
able
to,
but
if
we
were
gonna
try
to
solve
this,
perhaps
it's
by
more
generally
making
hempel
and
scopes
incorrect
more
reasonably
sister.
How
about
Nico.
A
Think
we
could
do
I
think
like
private
impulse
as
long
as
you
still
respect
the
coherence
rules
without
great
undue
difficulty,
so
you
be
able
to
like
have
a
nimble
that
you
can
use,
but
others
can't,
but
you
want
to
avoid
this
situation,
where
two
people
can
implement
the
same
in
pull
and
write.
Definitely,
yes
and
intermix.
A
One
thing
I
would
add.
Is
that
really
I
think
also
someone
pointed
this
out
before,
but
that
this
problem
of
info
flew
inside
of
a
function
bar
is
not
nearly
as
bad
as
a
macro
use
that
expands
to
an
info
fool,
because
you
can
kind
of
see
where
the
impulse
for
foo
are
relatively
easily,
then
relatively
lightweight
fashion,
but
having
to
expand
all
the
macros
out
is
much
worse.
That.
A
I
mean
the
Chrome
analysers
doesn't
can't
handle
this
okay
I
mean
it
can
handle
it
just
had
just
to
go,
expand
Becker's,
which
is
very
time-consuming.
So
your
your
dog,
your
dog,
is
slow,
but
I.
Think
all
of
these
things
are
cases
of
like
this.
One
I,
especially
like
macros,
are
complicated
and
not
a
short
fix.
I
think
you
should
wait.
You
don't
have
any
clear.
A
C
Not
a
lung
interaction
so
much
as
the
cargo
team
wants
to
do
this,
and
if
there's
going
to
be
a
notable
2021
edition,
that
would
probably
be
a
good
time
to
tie
it
to
so
we'd
like
to
coordinate
it.
If
they're,
for
example,
isn't
going
to
be
a
2021
Edition
which,
at
the
time
this
was
added.
That
was
a
question.
Then
cargo
would
need
to
handle
this
itself
somehow.
What
does
it
mean
for
a
future.
E
D
E
A
A
But
I
wrote
here
about
into
impulse.
I
would
be
curious
to
sync
up
with
the
little
bit
but
like
there
are
a
certain
set
of
for
a
while.
It
was
pretty
standard,
I'm
sure
it's
still
true.
We
just
had
what
we
called
acceptable
breakage
from
adding
in
Bulls,
especially
as
working
tools,
and
they
came
from
basically
the
rust
tree,
resolver
kind
of
in
doing
extra
inference
being
a
little
too
smart.
So
people
would
write
things
like
I.
A
Don't
know
they
would
write
like
I
think
it
would
very
kind
of
a
example
but
partially
specified
types
with
as
ref
call,
and
it
would
be
unambiguous
that
we
would
figure
out
how
to
resolve
it.
So
do
they
let
x
equals
food
out
as
breath
or
something
I.
Don't
know,
that's
not
a
great
example
book
and
one
then,
when
you
add
a
new
as
riffing
bull
suddenly
there
would
be
two
choices
for
what
the
target
type
might
be
and
you
get
breakage
right
and
affixes
to
kind
of
manually
specify
the
type.
A
My
opinion
that
this
decision
to
do
aggressive
infants
here
hasn't
aged
that
well,
but
it's
not
a
highly
informed
opinion.
I,
don't
know,
but
it
feels
like
it's
bad
that
we
regularly
our
people
are
breaking
and
I
thought
we
could
consider
that
we
might
add
annotations
to
traits
like,
as
we
ran
into
to
limit
that
inference,
at
least
in
at
least
in
a
new
edition
right,
like
maybe
that
isn't
Asians
are
ignored
in
earlier
editions.
There.
C
Is
a
common
pattern
here
where
people
are
hesitant
to
make
something
more
general
because
they
will
get
inference
breakage
and
if
there
are
ways
we
could
help
with
that,
that
would
be
nice.
This
is
one
example:
changing
from
I
accept,
stir
to
I,
accept
it
as
wrath
or
similar
kinds
of
things,
switching
to
accepting
a
cow
into,
or
anything
similar.
D
C
Case
I've
run
into
a
poor
example.
We
have
I
want
to
accept
a
slice
of
strings
because
I
had
made
an
array
of
them
and
I
would
be
willing
to
accept
a
stir
or
a
path
or
a
path
buff
for
a
beast
or
any
number
of
other
things,
and
that
works
beautifully
every
single
time.
Unless
you
want
to
specify
an
empty
slice
which
turns
out
to
be
the
common
case,
in
which
case
what
kind
of
an
empty
slice
is
it
I
don't
care.
A
C
A
Worth
knowing
these
are
sort
of
different
problems,
they're
related
like
in
one
case,
I,
want
to
do
less
inference
and
in
the
other
case
you
want
to
do
more
right,
but
I
mean
the
fallback
I
guess
we've
been
around
and
around
this
I
I
think
that
the
most
general
version,
the
main
problem,
is
conflicting,
fall
backs.
A
So
that's
one
main
problem
and
the
there
are
some
variants
where
we
make
conflicting
fall
backs
kind
of
impossible.
Basically,
by
limiting
the
kinds
of
places
fall
back
can
be
added
so
that
you
can't
add
it
in
more
than
one
photos.
So
if
you
allow
that
you
can
have,
for
example,
this
reminds
me
so
we
have
defaults
in
structures.
A
That's
not
what
I
wanted
to
say.
What's
the
I
don't
know
if
you
I,
don't
remember
the
details,
but
I
remember
that
we
had
some
variants
where
we
would
kind
of
limit
the
fall
back
to
cases
where
its
value
was
implied
by
struct
defaults.
I
think
that
was
it
so
the
usual
example,
if,
like
a
box
a
they
have
a
allocator
type
standard
outlet
or
something-
and
you
want
to
say
you
want
to
make
a
function.
Generic
over
the
box.
A
But
you
want
this
to
fall
back
to
standard
outlet
in
the
event
that
it's
not
specified,
probably
because
it's
being
returned,
there
were
some
proposals
where
the
idea
was
to
guarantee
that
the
only
defaults
were
ones
that
were
already
coming
from
a
struct
definition
and
therefore
like
they
can't
disagree
is
no
matter
how
many
of
them
you
have
they'll
all
be
the
same
as
whatever
is
in
the
struct.
In
fact,
maybe
you
don't
even
have
to
write
it
for
that
reason
that
doesn't
really
solve
the
right.
A
I
would
say
some
study
needed.
I
would
be
not
terribly
keen
on
just
I'm
nervous
about
just
sort
of
most
general
forms
of
this,
because
it
really
reveals
details
of
how
the
type
inference
error
works.
That
would
make
it
harder
to
switch
to
new
implementations
and
those
details
are
already
revealed
in
ways
I
more
than
I
wish
they
were,
but
we'd
be
making
them
significantly
more
revealed,
but
maybe
forget
it
example,
I
think
having
some
examples,
and
these
are
the
exact
kinds
of
cases
we
want
to
enable
right.
C
D
A
A
A
What
do
we
think
is
rusts
is
the
biggest
problem
that
we're
trying.
What
are
the
big
themes
that
we're
trying
to
address
and
do
that
inform
our
prioritization
of
our
efforts,
like
you
know,
does
that
make
any
of
these
things
more
important
than
any
other
issue,
I.
Think
for
sure,
some
of
the
work
we've
been
doing
around.