►
From YouTube: 2021-05-12 Generator 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
So
we're
gonna
start
by
reading
the
duck.
Welcome
to
this
recording
meeting
on
generators.
There
you
go
I'll
set
your.
A
A
A
A
B
C
Nah,
that's
fine,
especially.
It
helps
with
the.
D
D
D
A
C
A
D
D
B
I
think
I
don't
know
if
nico
or
esteban
is
the
one
putting
in
the
the
bits
about
four
right
at
the
bottom.
But
I
I
would
like
to
discuss
that
at
some
point.
A
Yeah,
that's
why
I
only
wrote
trying
not
to
put
long
answers
just
no
interest
anyway,
we're
two
minutes
in.
Is
there
more
time
for
reading
desire,
josh,
felix
or
others.
A
All
right
so
pulling
from
the
queue
I
don't
know
if
we
want
to
order
in
any
particular
way,
but
I
think
the
first
question.
C
Well,
before
we
dive
into
the
queue,
do
we
want
to
give
esteban
a
chance
to
give
us
a
tour,
and
then
we
can
dive
into
questions
or
do
we
want
to
dive
directly
into
questions.
A
A
Questions
like
clarifying
questions
that
might
be
a
good
place
to
start,
but.
E
I
think
to
me
the
thing
I
might
like
to
see
at
the
outset
is:
I
wrote
comments
in
line
for
things
that
just
were
unclear
in
the
doc
itself.
Just
a
quick
like
skim
over
the
I
didn't
want
to
put
them
as
questions
at
the
end
because
they
didn't
seem
worthy
of
that,
but
even
if
you
just
skim
over
them
and
say
yes,
no,
like
for
the.
F
I
I've
gone
the
two
main
things
that
are
lacking
on
this
proposal.
Compared
to
the
current
nightly.
Only
generator
feature
is
being
able
to
return
values
through
a
yield
point
back
into
the
generator
so
that
you
can
affect
its
behavior
and
the
return
type
and
the
those
are
depending
on
how
we
actually
implement
this
may
be
problematic,
but
nothing
here
would
preclude
us
from
grafting
on
both
of
those
features.
F
After
the
fact
on
this
proposed
implementation,
the
biggest
problem
I
could
see
would
be
on
the
scene,
surface,
syntax,
and
that
is
not
something
that
should
be
too
problematic
and
because
this
feature
would
be
returning
an
infiltrate
and
we
could
expose
different
ways
of
consuming
the
generators
where
you
have
a
simplified
version
where
you
can
only
cons,
consume
new
elements
and
a
more
elaborate
syntax
where
you
can
actually
affect
the
behavior
of
the
generator.
E
Right
no,
it
sounds
like
the
quick
summary
then
is,
since
this
document
isn't
actually
trying
to
it
gave
us
syntax,
but
it
wasn't
committing
to
it.
It
sounds
like
right
dues
here
with
generalized
code.
Routines
are
more
about,
sounds
like
the
syntax
you'd
use
for
them,
and
thus
we
don't
need
to
it's
not
really.
This
document
is
not
a
one-way
door.
In
that
sense,.
F
E
Okay,
that's
all
I
wanted
to
hear
for
that.
You
might
be
faster,
maybe
if
we
there's
a
link
at
the
top.
That
says
that
says
four
comments.
If
you
scroll
up
niko,
if
this
is
niko's
screen,
I
don't
know
who
screen
this
is
nico's.
I
think
it's!
No!
I
don't
see
it
in
here.
It's
weird,
there's
a
oh
there.
It
is
yeah.
If
you
click
that,
then
you
can
just
sort
of
go
down
and
see
all
of
them.
I
just
want
to
clarify
yeah.
F
F
There
is
an
argument
that
can
be
made
that
this
is
a
niche
feature
that
isn't
actually
used,
and
that
is
only
a
concern
for
libraries,
writers
and
from
my
searches.
I've
seen
what
you
would
consider
an
end
user
application,
a
service
that
actually
needs
to
operate
on
streams
and
create
their
own
stream.
A
stream
is
not
the
only
thing
that
they
have
to
implement.
In
many
cases
they
also
have
to
implement
async
read,
and
I
think
right.
E
Oh,
I
guess
I
guess
mostly.
I
was
curious
about
the
when
I
my
first
interpretation
of
this.
When
I
saw
subset
applications,
I
thought
it
was
saying
substitute
application
of
streams,
and
then
you
wonder
about
whether
you're
making
some
distinction
there
about
how
you
might
implement
stream
in
general
versus
what
you
can
express
with
the
syntax
theory,
with
the
the
semantics
and
syntax
you're
providing
here.
If
there's
certain
things
you'd
be
able
to
express
by
manual
stream
implementation
that
you
wouldn't
be
able
to
express
with
this
system.
E
Okay,
so
let's
let's
move
along
this
was
a
detail
about
the
python
code.
I
think
in
terms
of
I
didn't
understand,
why
join
in
inverse
is
there
and
I
didn't
see
it
referenced
anywhere,
but
I
think
it's
because
there's
a
typo
in
the
line.
The
very
last
line-
oh
yeah,.
F
F
Difference
so
yes,
the
thing
with
eater
from
fn
is
that
you,
you
are
limited
it
either
from
a
fan,
works
great
when
you
need
to
create
an
endless
stream,
for
example,
or
some
sequence,
but
it
doesn't
compose
very
well
when
you
need
to
affect
that
behavior,
based
on
a
set
of
initial
constraints
that
are
affected.
F
B
That,
like
iterator
or
stream
from
fn,
is
like
a
worse
thing
than
error
from
because
of
semantics
about
how
borrowing
works
for
async,
like
our
missing
async
closures,
feature,
which
is
another
thing,
that
sort
of
come
comes
up
in
in
passing
in
the
stock
and
gets
mentioned
lower
down.
G
Yeah,
that's
what
I
was
about
to
say.
My
point
here
was:
I
don't
think
it's
particularly
relevant
that
you
have
to
define
a
type
compared
to
manually
state
machining.
The
flow
right.
B
G
A
Okay,
so
why
don't
we
go?
I
thought
taylor's
question
is
sort
of,
like
probably
the
most
important
in
the
sense
of
like
how
I
understood
it
was
kind
of
why
now
why?
Why
do
this
at
all?
It's
sort
of
the
motivation
question
right
and
I
guess
esteban.
You
started
talking
speaking
to
it
already
a
little
bit,
but
maybe
you
wanna.
F
Yeah,
so
from
interactions
with
people
in
the
community
on
different
on
social
media.
Through
what
I've
been
seeing
on
the
assign
a
sync
vision
document
exercise,
there
is
a
common
pain
point
of
people.
First
of
all,
pin
is
probably
the
the
one
of
the
biggest
pain
points
that
people
have
when
learning
a
single
weight.
F
That
is
both
because
the
semantics
are
subtle
and
somewhat
counterintuitive
to
what
a
person
may
think
is
in
the
first
place
and
when
first
encountering
it
so
and
one
of
the
common
cases
where
people
have
to
interact
with
pen
is
when
writing
a
new
stream.
F
The
other
thing
is,
I
we've
seen
cases
of
people
misimplementing
streams
or
in
such
a
way
that
it
doesn't
cause
a
compilation
issue.
It
doesn't
cause
an
actual
incorrect
incorrect,
observable
behavior,
but
what
it
does
cause
is
a
very
slow
stream
consumption.
If
you
there
is
a
link,
I
think
earlier
in
the
document
that
talks
about
one
of
those
cases.
F
So
I
what
I
posted
is
that
this
is
a
common
enough
thing.
May
it
may
be
niche
in
the
larger
ecosystem,
but
it's
a
common
thing
that
any
micro
service
that
has
to
deal
with
different
connections
will
need.
It's
not
just
libraries
that
need
to
implement
stream
and
the
ex
there
are.
There
is
a
problem
with
discoverability
on
one,
these,
these
potential
food
guns
and
two
how
to
actually
implement
these
things.
F
If
you,
there
are
blog
posts
explaining
how
to
write
your
own
stream
from
scratch,
there
are
a
a
handful
of
different
crates
that
let
you
actually
implement
this
in
or
or
just
sidestep
the
issue
and
give
you
what
the
language
feature
would
give
you.
But
again
you
have
the
discoverability
issue
and
when
you
have
multiple
alternative
implementations,
you
have
the
problem
of
okay,
which
one
do
I
choose
and
on
the
cons.
F
This
is
a
part
that
I
I
don't
know
if
we
actually
want
to
tackle
on
this
meeting,
which
is
this
document
is
heavily
focused
on
the
producing
side,
but
you
also
have
to
keep
in
mind
the
consumer
side
and
whether
we
would
have
something
I
came
to
408
and
I
I
know
that
there
is
some
contentious
contentiousness
there
for
how
that
would
behave,
but
having
some
expression
to
ex
to
express,
if
you
forget
my
the
redundancy
there
to
express
that
concept.
F
That
would
let
us
hide
things
like
having
to
pin
the
the
stream
before
being
able
to
iterate.
I.
B
I
think
that
this
is
answering
a
different
question
than
the
one
I
was
asking,
I'm
not
trying
to
figure
out
like
why
people
want
to
not
write
streams
by
hand.
I'm
trying
to
understand
like
what
specific
like
what
is
the
specific
sort
of
like
user
story
where
they're
not
being
served
today
and
and
how
like?
How
can
we
meet
those
needs
if
that
makes
sense.
B
So
in
my
mind,
a
lot
of
the
people
writing
streams
today
manually
aren't
people
who
would
be
served
by
this
feature,
because
they
will
continue
to
need
to
write
streams
manually
for
either
performance
reasons
or
details
of
of
the
implementation
like,
for
example,
you
know
the
stream
I
wrote
above
like
has
a
future
baked
into
it,
and
it
has
something
where
it
like.
It
doesn't
pull
the
stream
unless
the.
A
B
Oh
sorry,
the
appendix
oh.
D
B
It
like
on
stable
without
macros
or
anything
you
can
already
write
and
sort
of
like
impulse
stream.
If
you
don't
mind
the
the
resulting
thing
has
these
sort
of
restrictions
about
you
know
being
not
conveniently
nameable
and
you
can't
add
methods
to
it
and
sort
of
all
these
other
things
that
we
have
other
sort
of
systems
in
the
works
trying
to
solve
like
the
type
alias
infiltrate
system.
B
So
I'm
trying
to
figure
out
like
what
specifically
like
what
specific
audience
of
people
we're
trying
to
target
with
a
by
providing
this
sort
of
mvp
feature
who
aren't
already
being
served
by
things
like
this
or
by
the
macro
libraries,
or
some
reason
why,
those
like
the
macro
libraries
or
this
you
know
this
proposal.
The
my
code
example
like
isn't
good
enough
for
those
users.
If
that
makes
sense,.
F
That
is
an
issue
once
you're
told
how
to
do
it,
it's
easy
enough
to
go
about
modifying
the
example
and
getting
what
you
wanted
to
do,
but
this
is
the
same
kind
of
ergonomic
distance
that
you
would
have
if
we
didn't
have
a
closure.
If
you
tried
to,
if
you
had
to
implement
every
closure
as
your
own
struct
with
its
own,
like,
if
you
had
to
implement
a
strike
for
every
closure
that
you
wanted
to
use,
then
there
is
a
certain
level
of
friction
there.
B
C
B
Right
I
at
least
it's
been
my
experience
that
when
I'm
writing
those
things
I'm,
I
also
want
to
offer,
for
example
like
a
debug
impule
or
something
that
prints
sort
of
the
current
state
of
that
iterator,
and
I
also
want
it
to
be.
You
know
copy
your
clone,
or
I
want
it
to
have
some
other
method
to
extract
the
intermediate
value
or
or
something
else
or-
and
I
want
it
to
be
nameable
to
my
users,
like
things.
C
Well,
two
things
one
is:
I
haven't
tended
to
run
into
much
other
than
yes
most
things
should
be
debug,
but
the
other
is.
I
don't
think
I
think
what
you're
capturing
is
a
requirement
for
this
syntax
of
maybe
there
should
be
a
way
to
name
the
type
that's
being
produced
and
to
then
further
extend
that
type.
By
saying,
I
also
want
that
type
to
support
debug.
I
also
want
to
add
another
method
to
that
type.
F
A
So
I
want
to
say
two
things.
First
of
all,
I
often
find
myself
writing
small
iterators.
I
don't
know.
Often
I
sometimes
find
myself
writing
small
iterators
using
it
or
from
function
or
other
things
which
works
okay
for
like
just
anything
where
I
don't.
You
know
doing
a
depth
first
search
over
some
structure,
some
graph
or
something
like
that
effectively,
not
necessarily
an
actual
graph
but
like
in
the
compiler,
for
example.
We
might
be
for
walking
through
a
list
of
predicates,
and
I
want
to
evaluate
them
one
by
one.
A
B
A
B
A
Want
to
speak
to
that
point
specifically,
which
is
just
to
say
that
I
have
pretty
much
not
had
any
com
like
pretty
much
every
conversation
I've
had
with.
I
was
going
to
say
customer
conversations
I'll
just
say
that
with
people
about
async,
they
all
bring
up
writing
streams
and
nobody's
using
those
tools.
A
A
It
is
that
that's
partly
discoverability
as
esteban
said,
and
maybe
we
can
make
them
more
discoverable,
but
I
think
it's
also
yeah
feeling
first
class
and
other
more
subtle
things
like
it's.
Definitely
something
that
is
hitting
people
a
lot
and
one
way
to
address
it.
I
think,
would
be
to
offer
them
nice
syntax.
A
F
So
one
thing
that
they
want
to
say
is
taylor
has
a
point.
It's
it's
very
possible
that
the
people
that
currently
that
are
currently
served
with
the
with
the
implement
implementing
a
new
iterator
or
a
new
stream
may
not
make
the
switch
because
one
they
already
used
to
it.
Two.
They
may
want
to
support
all
their
rasi
versions.
Three.
F
They
may
have
very
specific
needs,
but
what
the
new
feature
would
do
is
allow
a
lot
of
people
that
aren't
currently
writing
neither
iterators
or
streams
which
would
like
to
or
but
don't
have
as
high
a
necessity
and
are
put
off
by
the
current
difficulty
in
writing
them.
It
was
just
in
I.
I've
lost
the
the
the
sentence
structure
there,
but
it
wouldn't
enable
all
of
those
people
so
because
the
fact
that
there
are
people
that
currently
aren't
using
it
doesn't
mean
that
they
wouldn't
use
them
in
the
future.
B
I
think
that
the
discovery
ability
argument
is
good
and
it's
probably
the
best
one
and,
in
addition
to
the
sort
of
feeling
first
class
point,
I
think
that
I
feel
like
providing
these
tools
via
like
clear
standard
crates,
and
I,
which
is
just
impossible
right
now,
because
there's
at
least
three
different
definitions
of
the
stream
trait
floating
around
in
the
wild,
and
so
you
can't
write
a
smoke
canonical
library
for
all
of
this,
like
I
don't
know,
I
feel
like
as
an
ecosystem,
we're
like
in
a
mess
right
now
and
and
discoverability
is
incredibly
hard
and
understanding
documentation
like
there's
no
centralized
documentation,
because
you
have
to
figure
out
which
of
five
different
libraries.
B
You're
writing
your
documentation
for
is,
is
like
not
gonna,
be
like
this,
isn't
a
primary
step
in
the
solution
of
solving
that
problem
and
the
reason
that
these,
like
there
are
other
things
that
we
can
do
that
are
low
at
lower
effort
than
introducing
native
generator
syntax.
That
would
have
a
lot
more
payoff.
I
think.
A
I
think
there's
a
bit
of
a.
I
don't
disagree
with
that.
In
fact
I
agree.
However,
I
also
think
there's
like
assumption
that
we
can't
walk
and
chew
gum
right
that
we
can't
do
some
of
those
things
and
push
on.
B
Yeah
I
mean
if
we
think
it's
not
going
to
use
up
a
whole
bunch
of
lang
team
bandwidth
to
argue
about
whether
it's
async,
gen,
fn
or
async
it
or
fn
or
async
fn
star
or
whether
yield
can
like
what
it
returns
and
what
happens
when
you
use
question
mark
in
the
body
and
whether,
like
what
the
return
type
syntax
looks
like
like,
if
we
think
that
those
things
aren't
gonna
like
eat
all
of
our
time,
so
that
we
can't
focus
on
other
things,
then
I
mean
go
for
it.
B
C
So
I'd
like
to
interject
for
just
a
second
here,
I
think
it's
a
valid
point
and
I
also
think
we
may
not
want
to
spend
the
entirety
of
the
meeting
talking
about
whether
I
think
that
the
point
of
whether
should
we
should
do
this
or
not
has
been
made,
and
we
should
seriously
consider
that
and
in
the
meantime
we
may
want
to
take
the
rest
of
the
meeting
talking
over
okay
conditional
on
if
we
decide
to
do
this.
Let's
talk
through
some
of
the
other
potential
issues.
A
A
G
G
That
usually
being
able
to
use
yield
return
in
c
sharp
for
iterators
means
that
basically,
no
one
ever
writes
a
manual
iterator
implementation.
Because
there's
no
point.
A
F
F
So
if
we,
if
we
were
to
return
a
specific
input,
iterator,
then
that's
all
that
we
could
even
ever
do.
I
don't
know
if
that
is
actually
what
we
want
to
do.
It
may
be
the
moral
equivalent
to
that,
because
it
would
be
useful,
as
you
mentioned
earlier,
it
would
be
useful
to
have
to
be
able
to
extend
and
potentially
name
that
type
we
if
we
were
to
return
something
close
to
what
a
closure
is
or
some
other
name-able
type.
F
You
could
actually
extend
it
and
have
not
only
just
iteration,
but
it
adds
extra
methods
to
it
now
why
integerator,
instead
of
iterator,
just
flexibility
and
forward
being
able
to
change
it
after
the
fact,
that's
one
of
the
things
that
I
had
in
mind.
C
It
doesn't
seem
like
returning
impul
iterator
would
prevent
us
from
having
that
flexibility
in
that
you
could
always
potentially
have
a
name
for
that
type
elsewhere.
We
could
have
a
syntax
that
allows
you
to
name
the
type.
I
think
that
into
iterator
just
implies
you're
returning
a
thing
that
you
can
call
a
function
to
get
an
iterator
from,
but
you're
already
a
function,
that's
returning
an
iterator.
So
if
there
were
code
to
write,
you
could
write
it
there.
E
Are
there
cases
where
the
structure
that
you
get
from
like
for
iteration
is
different
from
the
structure
you
get
for
async
iteration,
where
you
really
would
want
that
level
of
that
level
to
be
extracted
so
that
you
don't
prematurely
commit
to
one
when
you
really
wanted
the
other.
You
can't
enter
convert.
A
E
Based
on
the
idea
that,
if
you
have
the
name
type,
I
guess
yeah,
like
whatever
the
type,
let's
say
you
have
the
name
type:
either
it's
going
to
implement
into
it
or
it's
going
to
implement
iterator
and
I'm
trying
to
stay
say
that
if
you
go
with
what
josh
is
saying,
I
think
of
saying
it's
an
iterator.
Does
that
mean
you've
now
committed
yourself
down
a
path
that
you
didn't
want
to
be
necessarily.
A
G
G
E
G
A
Right,
I
think
we
should
move
to
the
next
question,
I'm
mindful
of
the
time
and
I
think
there's
a
lot
of
good
details
like
it
seems
clear
that
this
is
a
choice
that
one
would
have
to
make.
It
may
not
be
correct.
G
A
Okay
cool,
so
this
was
about
adding
methods
like
size,
hint
and
so
forth,
and
I
think
that's
relevant
to
the
previous
questions.
Why?
Partly
why
I
wanna.
A
Yeah,
because
if
we
return
into
iterator,
even
if
you
had
a
syntax
for
naming
it,
that's
actually
not
you're,
not
naming
the
thing
you're
returning
is
not
the
one
that
will
add
these
methods
right,
so
you
couldn't
implement
them
by
hand,
or
at
least
it
would
be
a
little
trickier.
You'd
want
to
be
implementing
on
the
iterator
that
will
get
yielded
by
the
into
iterator.
A
B
A
Yeah
and
that's
when
I
say
this
is
totally
applicable
to
closures
right
like
we
have
the
same
problems
now,
I
think
yes,
and
it's
come
up-
that
we,
for
example,
implement
clone
automatically,
but
that's
not
always
a
good
thing
and
so
forth.
D
It
is
worth
noting
that
I
think
it
would
be
sort
of
pretty
sad
like
if
you
you
know
map
can
look
a
lot
nicer
as
a
generator.
I
think
in
many
cases,
just
from
like
a
looking
perspective
than
a
map
call,
but
you'll
get
you
know,
potentially
many
more
allocations
or
whatever
else,
if
you're
collecting
that
iterator
or
stream,
because
you've
just
lost
your
site
by
default,
and
I
struggle
to
imagine
that
we
can
do
anything
in
the
compiler
to
to
avoid
that.
B
Things
like
maps
specifically
like
you,
like
you,
want
to
optimize
the
layout
of
it,
because
it's
really
commonly
reused,
like
those
sorts
of
building
block
things,
are,
are
used
heavily
everywhere,
and
we
wind
up
with
like
accepting
prs
to
do
this
sort
of,
like
smallest,
smallest
micro
things,
to
reduce
a
branch
somewhere,
because
it
made
somebody's
thing
optimized
better
and
we
wouldn't
like
in
practice.
We
wouldn't
write
those
things
as
to.
D
A
I
don't
I
don't
totally
buy
that
point.
I
mean
I'm
looking
a
little
bit
ahead.
Let's
put
it
that
way
and
I
think
people
are
building
a
lot
of
stuff
anything,
some
of
which
is
building
black
summer,
which
isn't,
but
I
do
think
the
point
of
I
was.
This
actually
comes
to
the
rust
guiding
principles,
meaning
I
think
one
of
our
guiding
principles
of
our
design
has
always
been.
A
Efficiency
is
idiomatic
using
iterators,
not
just
because
they're
nice
to
use,
but
because
they
yield
better
code,
and
I
wouldn't
want
to
see
us
regress
on
that
point.
You
should
at
least
at
least
be
able
to
provide
those
sort
of
hints
so
that
using
the
nice
thing
doesn't
cut
you
off
from
it.
I
think
that's
definitely
a
design
requirement.
We
need
to
add.
D
Some
of
the
stuff
today
specializes,
so
it
bypasses
the
like
visible
barrier
in
some
sense.
Like
you
don't
know,
it's
an.
G
A
C
That
was
me.
I
don't
necessarily
know
that
I
have
a
precise
syntax
proposal
here
so
much
as
I
wanted
to
point
out
that
if
we
had
generators
returning
something
that
was
an
iterator
where
it
could
either
be
an
anonymous
iterator
with
impul
iterator
or
a
named
iterator
type,
then
we
would
have
the
option
of
subsequently
implementing
further
things
on
that
iterator
type,
so
that
you
could
add
things
like
size
hint.
After
writing.
Your
generator
function.
B
E
What
I,
what
I
was
imagining
was
some
way
to
say
under
there's
some
some
like
one
of
those
zen
cone
things
where
it's
like
you
know,
every
lambda
is
actually
an
object
and
every
object
is
a
lambda.
It's
just
a
matter
of
you
know
what
methods
you
attach
to
it.
I
always
imagine
something
where,
for
closures
you'd
be
able
to
throw
on
extra
method,
definitions
and
you
just
within
the
body
of
the
lambda
and
you'll
reference,
the
captured
variables
within
there
and
likewise
for
generators.
E
C
Right,
another
approach
by
the
way
would
be
if
we
inverted
the
flow
of
syntax
there,
where,
rather
than
having
a
top
level
generator
that
impulled
iterator,
you
could
have
an
impul
of
iterator
for
a
type
and
then
a
instead
of
having
to
hand
write
the
iteration
functions.
You
fill
it
in
using
generator
syntax
saying
this
is
how
I
want
to
implement
this.
G
D
B
A
It
doesn't
solve
the
size
and,
moreover,
in
a
way
it
makes
the
return
type
harder,
because
you
don't
have
to
write
it
so
like.
If
you
want
to
use
it
to
pick
things
you
can't,
I
don't
know
I,
I
don't
think
it
solves
the
interesting
problems.
Fundamentally,
no
it
just.
C
Well,
it's
not
just
that.
It
would
also
give
just
enough
language
support
to
let
you
write
the
actual
iterator
block
such
that
then
it
would
be
easy
to
invent
whatever
I
want
to
write
an
iterator.
C
C
True,
but
what
I'm
suggesting
is
that,
if
we
had
just
enough
syntax
support
to
do
iterator
blocks,
that
then
allows
for
a
lot
of
experimentation
in
the
ecosystem
for
the
next
round
of
what
should
the
top
level
syntax
look
like.
We
might
then
one
day
adopt
the
top
level
syntax,
but
we
might
be
solidifying
too
much
too
soon.
If
we
add
it
now,.
B
C
In
particular,
I
feel,
like
the
block
syntax,
solves
a
huge
fraction
of
the
problem
of
it's
painful
to
write
an
iterator
or
a
stream,
and
then
anything
beyond
that
is
additional
ergonomic
improvement
and
additional
expressiveness
improvement.
But
the
biggest
part
of
the
problem
that
people
are
complaining
about
seems
like
it
might
be
solved
by
a
block.
B
G
F
Regarding
size
hints
before
we
move
on
is
the
concern
only
for
cases
where
the
programmer
would
have
to
determine
what
the
the
size
the
size
bounds
actually
are,
or
is
it
also
about
propagating
a
consumed
iterator
that
is
being
yielded
and
propagating
that
size
hit
outwards?
Because
that
second
case
feels
to
me
like
we
could
support.
B
I'm
not
sure
how
you
would,
for
example,
if
you
iterate
over
two
streams
in
sequence,
right,
you
want
the
generator
to
give
a
size
hint
that
is
the
first
plus
the
length
the
size
into
the
first
plus
the
size
of
the
second
right
right
and
there's
no
way.
I
don't.
I
don't
know
of
how
we
would
infer.
F
Well,
you
you
have
an.
You
will
have
an
iteration
expression
on
both
of
those,
so
on
those
both
of
those
values,
you
would
have
an
iteration
expression
that
would
have
a
yield
in
its
block,
so
you
could
just
call
just
a
quote:
unquote,
all
of
all
of
the
iteration
expressions
that
have
yield
and
see
at
a
peak
at
the
time
to
get
the
value
of
the
size
hand.
F
A
F
A
Like
it
would
be
possible,
well,
I
guess
what
josh
is
writing
already.
You
can
imagine
some
cases
where
we
might
be
able
to
infer,
but
certainly
not
in
the
general
case.
I
think
we
kind
of
covered
this
question.
Maybe
we've
already
covered
all
the
main
big
questions.
Are
there
any
questions
that
people
feel
they
wrote
that
were
just
like
different
than
what
we've
talked.
B
B
A
B
Oh,
and
also
I'm
assuming
from
for
them
vp,
I
just
left
a
comment
here,
yielding
borrows
out
of
into
the
stream
state,
is
out
of
scope
for
this
right
since
we're
just
considering
async
iterator
and
not
async,
ref
iterator
or
whatever.
A
B
Right
we
would
really
like
for
that
to
be
easy
and
natural
that
one
thing
yields
you
know
owned
values
and
one
thing
yields
borrowed
values
like
because
I
think
the
thing
the
borrowed
value
thing
is
something
that
I
really
frequently
want
and
yeah.
I
would
love
I
would
love
for
that
to
be
supported.