►
From YouTube: 2020-08-26 Design Meeting: Stream Trait
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
I
wanted
to
talk
about
the
queen
trait,
which
is
closely
proposed,
and
I
was
especially
interested
from
the
laying
team's
point
of
view
that
we
talk
about
some
of
the
things
that
the
design
commits
us
to
our
future
things
that
we
might
encounter
and
what
it
means.
For
that.
A
A
I
guess
this
is
wrong.
I
just
realized,
I
don't
know
now,
do
you
want
me
to
walk
through
it
or
do
you
want
to
walk
through.
A
I'll
add
this
in
here,
because
it's
relevant
something
like
this
so
yeah,
you
can
read
the
actual
draft
here,
but
the
core
point
is
to
add
this
trait
into
standard
library,
for
defining
streams,
with
the
goal
of
letting
people
write
interoperable
streams
and
it's
basically
it's
the
async
version
of
iterator,
so
instead
of
where
iterator
has
an
as
a
next
method,
ignore
this
next
method
for
a
second
I'll
talk
about
in
a
second,
the
next
method
from
iterator
becomes
poll.
A
Next
right-
and
it
has
a
this-
is
not
poll-
it
has
a
pinned.
Receiver
takes
in
some
context,
so
much
like
a
future.
I
guess
trailer
or
you
could
also
present
this,
but
anyway,
let
me
try
and
see
if
you
guys
can
correct
me
where
I
go
wrong,
but
you
have
a
pinned
receiver
in
the
context.
A
Maybe,
as
you
ask
the
screen
next
item
ready
and
either
there
is
an
item
and
you
get
it
or
they
get
the
end
of
stream
before
you
get
back
not
yet,
and
you
have
to
wait
and
the
rfc
proposes
not
a
very
minimal
sort
of
interface.
It
basically
consists
of
this
one
method,
plus
one
helper
method.
A
A
You
can
write,
you
know
you
can
say
reading.next.o8,
it's
debatable
if
we
want
to
include
that,
but
it
does
seem
like
pretty
much
everybody's
going
to
be.
A
To
allow
them
to
do
so,
there
could
be
other
helper
methods.
You
could
also
consider,
but
there's
some
whoever's,
somebody's
typing
in
this
level.
I.
B
Was
about
to
ask
yeah
it's
it's
a
little
hard
to
hear
nico.
A
Well,
I'm
going
to
mute
everyone,
but
you
can
unmute
yourselves
so
right.
The
idea
was
this:
is
the
minimal
helper
method
there
could
be
more.
There
are
reasons
not
to
include
all
of
them
because
things
like
closures
and
so
forth
there
are.
There
are
basically
language
features
that
get
intersected,
especially
ac
enclosures,
that
affect
a
lot
of
the
of
the
helpers
and
made
me
want
to
probably
want
to
hold
off
on
adding
them,
but
stop
here
and
say:
does
anyone
have
any
questions
on
that
so
far?
C
B
In
the
rfc,
we
do
address
that
as
a
future
thing
that
we
would
like
to
do
and
not
as
a
future
is
an
overloaded
term
in
this
rsi.
B
That's
something
we'd
like
to
do
in
the
future,
but
it's
not
explicitly
this
rfc
doesn't
advocate
for
implementing
it.
Just
yet.
F
E
G
E
G
C
I
think
it's
still
worth
it
for
context
even
like
boats.
Maybe
you
might
want
to
read
through
those
posts
and
decide
if
there's
anything
you'd
like
to
change
now
in
terms
of
making
a
new
post,
but
I
think
I
remember
thinking
that
whether
or
not
the
conclusion
was
correct.
The
analysis
of
options
was
really
helpful
in
terms
of
talking
about
the
implications
to
the
language.
C
G
C
They're,
so
part
of
the
reason
I
bring
this
up
now
is:
I
don't
think
we
need
to
gate
on
having
a
concrete
syntax
for
this.
I
do
think
there's
value
in
confirming,
at
least
with
a
straw
architecture,
of
some
kind
that
we
feel
like
this
syntax.
The
methods
that
we're
writing
are
enough
to
support
something
like
that.
I
suspect
the
answer
is
fairly.
C
Obviously
yes
that,
obviously,
if
we
can
write
for
while
let
some
equals
something.8,
then
we
can
have
a
sugar
for
that,
but
I
think
there's
value
in
confirming
that
whatever
magical
sugar,
we
might
end
up
with
here's
what
it
could
translate
to
and
we
feel
like
this
could
be
language
integrated
and
we're
not
opposed
to
doing
that.
A
It
seems
like
there
would
be-
I
don't
see
a
problem
with
the
sugar,
except
what
there's
one
like
tweak
about
next,
which
is
that
it
requires
that
the
stream,
the
un,
the
self
type,
the
unpin
and
yeah
means
that
if
you
maybe
we'll
talk
about
a
bit
with
generators
but
like
if
you
just
drop
in
like
a
if
we
had
an
async
generator
function
and
we
just
dropped
it
in
there,
there
might
be
an
explicit
pinning
step
required
to
really
use
next
or
there
would
be.
I
guess,
yeah.
I
would
be
surprised
by.
E
G
Whatever
else
it
needs
to
happen,
yes,
but
like
a
for
loop,
syntax
would
just
like
inherently
pin
it
right
because
it
takes
ownership,
so
it
doesn't
move
it
as
part
of
it
right.
G
G
A
E
Necessarily
rare,
but
I
think
it
should
be
a
very
conscious
decision,
like
I
think
that,
much
more
frequently,
you
actually
want
to
be
processing
stream
elements
concurrently,
but
obviously
I
think
that's
something
that
requires
like
taking
a
look
at
the
ways
people
are
using
stream
in
the
wild
today
and
like
what
what
patterns
we
want
to
encourage.
I
think
adding
built-in
syntax
for
a
pattern
that
we
might
want
to
discourage
would
be
bad,
so
we
should
decide
whether
that's
a
pattern.
We
want
to
push
people
away
from
or
not.
G
Right,
well,
I
mean
go
ahead,
just
like
the
concurrently
like
for
reason.
Currently,
the
problem
is
that
we
cannot
make
it.
You
can't
early
return
inside
of
that
right.
G
E
I
mean
well,
I
mean
like
you,
I
I'm
like,
maybe
jumping
ahead
here,
but
like
you,
you
could
imagine
something
that
did
like
some
kind
of
trampolining
step
right.
It's
similar
to
how
we,
how
we
use
the
like
try
methods
on
iterators
today
and
then
it
could
automatically
propagate.
You
know,
returns
and
tries.
B
A
I
think
let's
go,
let's
cut
this
off
a
little
bit
and
come
back
to
it,
but
it
does
seem
like
the
other
kind
of
these
are
all
specific
problems
with
syntax.
It
also
is
true
right
that
we
might
want
to
commit
really
from
inside
of
such
a
for
loop,
like
we
can
put
limits
on
what
you
can
do
inside
the
loop
also,
but
that's
kind
of
I
feel
like
we
can
discuss
that
when
we
discuss
like
it
doesn't
affect
the
streaming
trade,
the
design,
yeah.
A
So
one
one
of
the
things
I
thought
of
that
I
thought
wanted
to
talk
about.
One
of
the
very
simple
ones
is
when
we
add
a
minimal
trait
like
this,
we
have
a
bunch
of
helper
methods
in
the
futures
crate,
but
the
we
probably
will
want
to
eventually
move
them
over
to
the
main
trait,
or
at
least
some
of
them,
similar
to
how
we
sometimes
want
to
migrate
things
from
inner
tools
to
iterator
and
stuff.
A
Like
that,
and
we
have
no
good
way
to
know
like
that-
creates
ambiguities
which
then
cause
existing
crates
to
fail
to
compile,
which.
E
A
D
C
Right
and
presumably
we
would
need
specialization
to
be
able
to
say
you
get
a
default
impul.
That
is
a
blanket
impo
for
iterator.
Some
methods
might
only
be
for
iterator,
plus
some
additional
qualifications,
and
then
you
might
have
specialization
for
cases
where
you
want
to
override
a
given
iterator
method,
because
you
can
do
it
more
efficiently.
D
We
did
just
have
people
proposing
moving
yet
another
itertools
method
over
to
iterator
and
called
out
the
we
have
no
good
way
to
disambiguate
this
when
the
ambiguity
happens.
So
that's
making
me
want
that
feature
again
over
there
as
well.
H
Wouldn't
feature
detection
also
work
here,
say
the
extension
tray
that
futures
rs
provides
doesn't
implement
a
particular
method
if
it's
on
particular
rust
version.
So
then
through
semver,
if
people
like
just
upgrade,
oh.
C
G
It
would
still
break
people
who
have
a
lock
file
like
as
soon
as
they
upgrade
to
that
version.
They
would
not
because
we
would
add
a
new
version
of
futures
crate
that
contains
that
cfg.
As
soon
as
we
knew
there
was
a
version
that
this
was
going
to
be
added
in,
but
people
who
have
a
lock
file
that
doesn't
specify
that
new
version
would
still
be
broken
by
the
upgrade.
G
E
Definitely
point
out
that
the
ambiguity
won't
actually
exist
until
the
stream
trade
in
futures
core
forwards
to
the
one
in
like
upstream
scd
right,
because
by
default
they
wouldn't
be
the
same
trait
but
you're
going
to
do
that.
Stable
right
right
and
at
that
same
time,
so
that
anybody
who
had
that
update
would
also
have
the
update
to
remove
whatever
these
methods
are.
That
are.
G
A
Certainly
a
lo-fi
fix,
and
maybe
it's
good
if
we
can
only
do
it
or
like
maybe
it's
okay,
that
it's
only
it
requires
careful
coordination
to
work,
and
that
means
we
won't
do
it
willy-nilly.
But
we
shouldn't
do
this.
You
should
be
careful.
A
Yeah
I
was
wondering
about
that.
If
we
ever
make
tweaks,
as
we
add
things
to
the
sooner
library
then,
but
maybe
the
answer
is
well,
I
don't
know
yeah
the
other.
The
only
other
alternative
I
can
think
of
is
some
kind
of
priority
annotation
that
which
is
kind
of
a
could
work,
but
it's
also
one
of
those
features
where
you
I
don't
know
priority
things
then,
which
one
wins
well.
A
Yeah,
I
think
that's
what
you
would
mark
the
standard
library
as
sort
of
low
priority.
So
you
get
the
old
you
get
the
code
you
had
before,
but
that's,
as
you
say,
that's
good
for
existing
crates,
but
maybe
not
what
newer
crates
want.
D
Yeah
I
wish
we.
I
wish
we
had
a
way
to
disambiguate
method
names
off
trades,
that's
not
quite
as
far
as
a
jump
as
all
going
all
the
way
to
ufcs.
D
That
was
discussed
as
like
paths
in
method
names
before
or
something
like
that.
I
don't
know
if
that's
necessarily
the
best
way,
because
that
opened
up
the
whole
well,
can
you
just
call
functions
with
method,
syntax
conversation,
but
having
some
way
to
do
this
that
doesn't
require
it.
The
function,
syntax
instead
of
method,
syntax
and
doesn't
lose
draft,
and
all
that
sort
of
stuff
would
be
nice.
A
I
wonder
all
right:
I
think
we
should
move
to
the
next
topic,
but
I
I
do
want
to
I'll
just
say
one
last
thing,
and
then
people
can
have
one
last
round
of
comments
and
then
we'll
move,
but
is
that
it
may
also
be
something
that
winds
up
getting
tied
to
additions.
I
could
imagine
it,
but
that
will
be
a
possible
turning
point
where
you
can
like
introduce
new
things
and
migrate
people
over
when
they
move
the
edition.
I
don't
know.
D
E
A
Yes,
but
the
question
is
we
could
have.
We
could
say
that
you
can
add
members
like
methods
into
a
trait
that
do
not
participate
in
dot
dispatch
or
only
participate
in
dot
dispatch
based
on
the
addition
of
the
crate.
That
call
is
calling
them
and
then
that
would
allow
us
to
move
methods
later
from
futures
crate
into
standard
library,
but
over
some
addition,
boundary
such
that,
like
old
code
gets
rewritten
to
ufcs.
I
guess
I
don't
know
it.
We'd
have
to
work
it
out,
it's
kind
of
complicated
and
messy,
but
it
might
be
practical.
G
I
think
it's
possible
that
the
best
solution
to
this
would
just
be
to
like
only
do
this
once
and
just
accept
that
like
have
have
a
release,
ready,
prepare
everything
to
try
to
encourage
like
basically
to
a
flag
day,
but
only
do
it
once
around
these
methods,
rather
than
trying
to
make
it
never
break.
Anyone.
G
G
So
there
would
just
be
one
version
where
this
like:
we
are
allowed
to
make
this
breakage
right,
it's
like
in
our
stability
policy,
and
so,
if
we
do
it
with
a
lot
of
communication
and
a
lot
of
preparation
and
make
it
as
smooth
as
possible,
hopefully
it
we
cannot
afford
to
do
it
once
we
can't
afford
to
keep
adding
new
methods
like
every
release.
That,
I
think,
would
be
intentional.
G
G
G
C
G
A
E
C
A
A
Right,
so
these
are
the
other
examples
right,
so
stream
may
become
the
most
important
in
some
sense,
if
only
because
I
don't
know,
iterator
has
already
a
pretty
full
method
set
on
what
we
just
said.
A
Okay,
so
let's
talk
about
lending
traits,
which
is
my
new
term,
I'm
trying
to
get
everyone
to
use,
not
that's
the
final
one
I
actually
like,
but
I
think
the
idea
is.
A
We
have
all
long
wanted
this
idea
of
a
streaming
iterator
or
what
I
was
calling
attached,
the
idea
being
that
you
have
an
item
that
is
actually
borrowing
data
from
the
stream
or
the
iterator
itself,
and
we
were
looking
into
what
it
would
look
like
if
we
tried
to
add
a
trait
like
this,
I'm
calling
it
lending,
because
the
idea
is
that
the
stream
lends
the
data
to
you,
but
you
don't
get
to
own
it,
and
so
the
trait
might,
you
know,
look
actually
I'll
make
it.
A
Like
async
specific,
basically,
the
trait
looks
kind
of
like
this,
and
the
idea
was
well.
If
we
added
this,
we
probably
would
want
to
have
some
interconversion,
because
every
iterator
is
kind
of
a
lending
iterator,
because
is
that
right?
I
think
that's
right.
B
A
The
idea
being
that
when
you
use
the
lending
iterator,
you
can't
keep
things
alive
across
iterations,
because
you
have
to
kind
of
give
up
the
data
before
you
call
next
again,
and
you
can
also
do
that
if
you
own
the
data,
so
it's
it's
a
generalization.
However,
there
are
some
problems.
If
we
added
like
we.
If
we
add
this
input,
it
says
I'm
going
to
implement
lending
stream
for
all
schemes,
but
then
we
also
have
impulse
like
this
one.
That
says
every
box
of
t
is
a
stream.
A
If
t
is
a
stream
and
another
a
similar
one
for
lending
stream,
then
you
get
these
ambiguities
like
a
box
of
impulse
stream
can
become
a
lending
stream
in
multiple
paths.
You
can
either
turn
it
into
a
box
of
impul
lending
stream
and
then
turn
that
into
a
landing
stream,
or
you
can
turn
that
into
a
stream
and
international
language
game,
that's
kind
of
a
diagram
thing
and
intersection
impulse,
yeah,
maybe
right
so
there
we
kind
of
have
this
problem.
We
might
need
some
solutions,
I
guess
intersection
impulse
isn't.
Is
it
valid
one
too.
C
It's
kind
of
unfortunate
that
I
mean.
Let
me
say
this
a
different
way.
It
feels
like
it
would
be
nice
if
we
had
some
kind
of
higher
level
generic
here
where
we
could
say.
If
you
want
a
borrowed
value,
I
can
give
you
that
and
if
you
want
an
owned
value,
I
can
give
you
that
and
have
that
be
more
or
less
the
same
trait
with
a
generic
return
value.
A
Because
you
could
have
somewhere
clauses,
but
it's
really
they're
used
very
somewhat
differently.
I
don't
know
it's
true
that
this
would
be
the
more
general
version.
It's
also
true
that
we
don't
have
all
the
technology
we
need,
and
even
when
we
do
the
where
clauses
like
we
don't,
we
need
notation
that
makes
it
plausible
to
use
in
a
nice
way.
C
G
Should
it
be
for
where
fortig
a
t
conclude
item
of
ticket
is
static
where
for
every
lifetime,
the
value
is.
E
A
I
think
something
like
this
would
be
the
most
realistic
way
to
say
it
in
terms
of
like
I
don't
know
what
we
don't
even
have
this
notation
really
fully
defined,
but
if
we
did
right
where
you're
now,
just
by
the
way
that
the
scoping
works
like
this
t,
is
kind
of
outside
the
scope
of
this
underscore,
so
it
can't
possibly
name
that
lifetime.
So
you
know
it's
independent.
I
mean.
E
I
know
this
is
a
straw.
Man
like
proposal,
but
the
the
like
tick
underscore
has
an
existing
meaning
right.
So
you
need
something
new
there.
A
You
haven't
really
said
what
we'll
do
with
this,
but
yeah.
So
there's
another
question
of
like
what
does
this
even
mean?
I
don't
know
we
got
enough
stuff
to
work
out
here
that
this
is
partly
why
I
think,
like
we,
don't
really
want
to
block
streams
on
this
on
on
figuring
out
generic
associated
types.
So
I
think
this
is
one
of
those
cases
that
we
have
we're
going
to
move
forward,
but
we're
going
to
have
to
figure
this
out.
A
I
don't
know,
but
we
do
have
to
solve
this
interoperability
question
and
I
think
I
think
that
either
intersection
impulse
like
being
able
to
which
would
basically
mean
you
also
add
a
just
for
everyone
else-
who's
not
necessarily
know
what
business
they
remember,
but
having
some
way
to
say.
Okay,
these
two
impulse
overlap,
but
we
can
add
an
impul
that
is
more
specialized
just
for
that
overlap,
which
I
guess
would
be
like
lending
stream
or
box
of
tea,
where
tea
stream,
or
maybe
some
kind
of
creativity.
C
So
the
notion
here
would
be
that
you
have
the
diamond
pattern
in
possible
ambiguity
and
you
are
explicitly
carving
out
the
bit
where
they
overlap
and
saying
here's.
What
that
bit
of
the
venn
diagram
looks
like.
F
Yeah,
it
seems
like
what
you're
trying
to
express
here
is
almost
a
super
trait
relationship
and
like
if
you
could
express
that,
for
the
purposes
of
overlap
analysis,
you
might
be
able
to
get
away
with
like
a
default
dimple
on
one
leg
of
the
diamonds
pattern
and
a
non-default
simple
on
the
other,
like
landing
stream,
where
a
super
trade
of
stream.
Essentially
I
mean
that
interacts
with
like
dying
and
a
lot
of
other
things,
but.
A
Yeah,
I
don't
know
if
that
helps
you're
right,
that
it
is
a
super
trait,
and
I
remember
when
we
were
going
through
specialization.
That
seems
significant.
Sometimes
what
kind
of
issues
around
this
intersection
and
rules
like
in
part,
because
sometimes
the
intersections,
if
I
recall,
don't
really
exist
like
theoretical,
but
hard
to
write
an
impul
for
things
that
can't
really
exist.
A
A
What
I
was
going
to
say
is,
I
feel,
like
it
happens,
sometimes
that
we
have
dimples,
where
we
don't
care
what
order
like
like
in
this
case,
we
really
care
about
which
power
we
take
through
these
symbols.
You
know
in
similar
marker
traits
as
well.
I
wonder
if
there's
a
way
to
express
that,
or
basically
say
a
compiler
can
pick
it.
F
Okay,
yeah,
basically
what
I
was
suggesting.
I
don't
know
if
it
makes
sense.
If
you,
if
you
have
your
like
simple
lending
stream
for
box,
t
or
t,
is
lending
stream.
Could
you
make
that
all
default
temples
and
then
have
simple
stream
for
box
c
or
t
stream
would
be
non-defaulted?
And
could
you
basically
say
okay?
Well
now
the
streaming
apple
was
more
specific
in
every
way
than
the
lending
stream
apple.
E
I
wanted
to
quickly
interject
to
ask:
did
we
have
like
a
sort
of
goal
of
like
is
the
is
the
primary
point
of
this
meeting,
trying
to
decide
whether
we
can
move
forward
with
the
stream
rfc
is
written
because
it
seems
like
we're
all
sort
of
on
the
same
page
that,
like
we
need
a
solution
to
this
problem,
whatever
it
is
because
we
already
have
it
for
iterator
right.
G
C
Solve
it
the
same
way
right
yeah
that
seems
like
it
should
be.
The
order
of
the
day
here
is
which
of
these
items
are
actually
blocking
us
from
approving
the
rfc
as
written
as
opposed
to
potential
future
things
we
might
wish
to
do.
C
One
consideration
that
does
seem
worth
mentioning
if
we
implement
a
stream
trait
in
the
standard
library
and
we
don't
provide
common
combinators
for
that
stream.
Trait
things
like
map
or
all
the
various
iterator
functions
that
would
be
useful
in
the
context
of
a
stream
crates
will
pop
up
that
provide
those
helpers.
Atop
the
standard
library,
trait
and
people
will
start
using
those
which
means
that
there
will
be
more
breakage
in
the
future,
no
pun
intended.
C
E
E
E
C
H
Yeah
there
are
some
other
problems
or
like
difficulties
there
in
that
we're
missing
language
features,
specifically
async
closures,
which
we
need
for
things
like
stream
filter,
where
you
need
to
to
borrow
closure
and
then,
or
you
have
some
issues
or
even
for
each
right.
You
like.
G
H
And
then
the
other
feature
that
we're
missing
is
async
traits.
What
you
need
for
things
like,
I
believe,
either
from
stream
or
into
stream.
E
C
A
Yeah
anyway,
I
agree
to
dial
back
slightly
to
what
taylor
was
saying.
That
was
my
goal
with
this
section,
and
this
meeting
in
general
was
just
to
this
is
what
we're
doing
I
want
to
head
off.
I
wanted
to
know
what
I
think
the
implications
are
of
doing
it,
but
I
don't
think
we
have
to
go
too
much
further
into
the
lending
versus.
E
E
E
Well,
so
I'm
thinking
about
it,
I
guess
you
could
force
that
the
new
version
of
futures
util
depends
on
the
new
version
of
futures
core,
but
you
can't
force
that
people
don't
have
a
newer
version
of
futures
core
than
they
have
features.
Util.
A
I
also
think
config
accessible
is
implemented
by
the
side
notes,
but
okay,
I
was
assuming
it
could
be
moved
atomically.
I
hadn't
considered
that
I
mean.
E
A
Right
so
you're
saying,
if
futurescore
redirects
to
standard
libs
stream
goal
at
least
today
may
still
use
an
older
version
of
futures
util
and
hence
they
would
still
have
the
next
method.
E
I'd
also
point
out
that
it's
not
just
the
method,
the
the
like
actual
concrete
types
have
to
match
up,
which
means
that
you
know
it
has
to
have
all
the
same.
Like
you
know,
debug
and
whatever
the
heck
else
copy
clone,
you
mean
for
the
return
type
correct.
The
return
type
of
the
next
method
has
to
match
up.
C
E
Do
it
immediately
after
release
yeah,
I
would
say:
maybe
it
should
wait,
a
couple
cycles
or
something,
but
I
I
don't
like
I
kind
of
I
I'm
sort
of
in
the
like.
There's
no
rush
like
half.
Why
bother
camp
on
the
moving
to
stream
traits
is
stood
now,
but
I
know
other
people
feel
more
strongly
about
it
and
I
do
understand
like
reasons
why
we
want
something
that's
more
like
canonically
defined.
E
G
A
E
F
A
A
It
does
okay,
we
probably
do
want
to
do
it
as
a
non-breaking
change.
If
we
can
right
that
would
be
vastly.
A
Okay,
the
last
topic
I
had
on
the
list
was
generator
syntax
as
and
I
guess
408
syntax
kind
of
ties
into
that
of
not.
This
is
definitely
in
the
camp
of
like
it's
not
addressed
in
erc,
but
a
common
concern
is
sort
of.
Are
we
taking
a
step
that
would
make
generators
and
tax
impossible?
Have
we
coordinated
enough?
A
Be
all
secure
right,
and
there
were
a
few
things
that
I
hadn't
fully
understood
going
into
the
discussion
that
I
found
interesting
or
I
hadn't
fully
thought
about.
Let's
say
among
them
the
fact
that
we,
if
given
that
we
have
the
iterator
trait
and
it
does
not
have
a
pin
itself
if
we
want
to
have-
as
I
I
guess
I
can
sketch
out,
but
I
think,
like
general,
my
assumption
at
least
is
that
we
would
wind
up
with
some
syntax
such
that
you
can
both
write
an
iterator.
A
Or
a
stream
in
a
very
similar
fashion,
an
interesting
implication
of
this
is
that
iterators
like
either
there
has
to
be
an
explicit
pinning
step,
or
else
they
can't
allow
borrows
of
things
on
the
stack
over
a
yield
right.
G
Yeah
that's,
however,
I
have
a
theory
that
maybe
not
being
able
to
borrow
things
in
a
stack
for
iterators
is
something
that
doesn't
bother.
People
based
on
the
fact
that
not
being
able
to
borrow
on
like
it
immediately
was
apparent
with
people
using
features,
even
combinators
0.1
that
they
needed
to
borrow
things
on
the
stack
right,
because
they
ended
up
with
these
arcs
around
everything,
because
they
couldn't
do
that.
But
you
know
people
would.
E
G
That
problem
with
with
iterator
combinators,
it's
worth
exploring
whether
just
having
them
have
the
static
generator
semantics
for
iterator
for
generators,
not
async.
Generators
for
generators
would
be.
E
Well,
I
certainly
want
to
be
able
to
loop
over
do
do
like
a
for
loop
and
then
yield
from
the
inside
of
it,
which,
if
I'm
for
looping
over
something,
that's
borrowed.
That,
like.
G
C
Right,
so
I
wouldn't
necessarily
want
it
to
be
something.
Oh,
I
see
what
you're
saying
assuming
what's
coming
in
from
the
outside
might
be,
for
instance,
a
collection
you're
implementing
an
iterator
over
then
yeah.
That
might
be
true.
I
don't
need
to
borrow
from
a
local
in
the
function,
but
I
do
want
to
borrow
from
whatever
I'm
using
a
generator
to
not
have
to
hand
write
an
impul
iterator
for.
C
G
G
You
can't
borrow
across
yields
inside
of
them,
and
I
would
like
it's
probably
very
buggy,
because
I
wrote
it
in
like
a
day,
but
I
would
like
to
get
to
use
to
try
to
experiment
and
see
how
often
it's
a
pain
and
like
because
yeah
there
are
a
range
of
options
like
from
not
providing
the
feature
to
having
an
explicit
syntax
for
distinguishing
between
static
and
non-static
generators.
G
A
G
Yeah,
I
don't
have
the
hack
actually
open,
I'm
just
watching
on
your
screen,
so
I
can't
type
instead
of
trying
to
find
it
I'll,
just
narrate
yeah
that
it's
like
an
attribute
you
put
on
like
a
function
and
it
changes
the
function,
signature
to
return,
input,
iterator
and
it
expands
your
body
to
be
inside
of
a
generator
which
you
can
yield
from
and
it
uses
static
for.
G
Well,
it
has
both
async
and
non-async
versions,
depending
on,
if
the
function's
async
or
not,
and
for
the
non-async
version,
it
uses
the
static
generator
feature
which
we've
always
had,
which
don't
allow
borrows
across
yields,
and
so
it
doesn't,
it
does
implement
on
pin,
unlike
so
it
requires
nightly
yeah.
It's
just
a
thin
wrapper
over
the
experimental
feature,
with
the
the
set
of
like
options
that
I
think
we
should
consider
at
stabilizing.
B
E
A
So
that's
cool
about
the
crate.
We
have
five
minutes
left
in
the
meeting.
I
think
we
covered,
like
all
the
major
topics
which
is
good
and
we
found
at
least
one
thing
to
talk
about
in
the
rfc,
which
is
the
timeline
or
the
transition.
I
don't
know
where
it
is
in
this
document,
but
is
there,
and
I
think
there
was
generally
agreement
that,
like
it's,
a
none
of
these
problems
are
reasons
we
can't
go
forward
with
the
rfc
at
least
aren't
blocking
problems.
A
One
thing
we
didn't
spend
a
lot
of
time
on
is
the
motivation
for
why
now,
but
I
mean
I
don't
want
to
do
that
at
this
moment
in
the
last
five
minutes,
but
I
will
say
I
think
I
mean
the
main
reason
is
enabling
interoperability.
In
fact,
it's
highly
requested
by
like
pretty
much
everyone.
I
have
spoken
to
that's
been
my
main
reason.
I
don't.
A
Like
I
know
that
josh
could
speak
for
racing
stood,
but
I
I
know
for
tokyo
in
particular,
they
wanted
a
specific
thing
that
they
were
saying
they
really
like
to
have
a
stable
standard
library,
trait
that
they
can
reference
that
will
meet
their
or
else
some
kind
of
like
multi-year
stability
guarantee
on
the
part
of
the
future
is
great,
I
don't
know,
but
they're,
not
equally
good.
I
don't
think.