Brendan Eich wrote:
Axel Rauschmayer wrote:
It’d be great if all iterables were indeed the same in this regard.
I didn't reply to this last sentence. I don't agree that all iterables
(we don't control the universe of such things, so perhaps you mean all
standardized or built-in iterables)
Axel Rauschmayer wrote:
The way that `return()` is handled in generators (via try-catch) means
that the clean-up action is called in both cases: generator exhaustion
and generator closure. If you don’t use a generator then a clean-up
action in `return()` is only called if the iterator is
We want `return` (Python 2.5+ close) to be optional, though. So an iterator
whether implemented by a generator function or otherwise sees no difference
-- provided in the generator function implementation you do not yield in a
try with a finally. Forcing return from a not-exhausted
It’d be great if all iterables were indeed the same in this regard.
What do you suggest, that array iterators should not be continuable? So we'd
have `.return()` methods on ArrayIterators, StringIterators, MapIterators,
and SetIterators, which sets the respective [[Iterated*]] internal
Axel Rauschmayer wrote:
a difference between iterators that you have to be aware of and that needs to
be documented per iterable.
Alternatively, just test `if (typeof iterator.return == function)` :-)
But yes, awareness is required. Maybe we should dub closeable
iterators as a subtype of the
But: you need to guard against other ways of reaching `finally`.
Why? I intended to always reach finally, and always close the iterator. Also,
simplicity ftw :-)
That’s not what all the other constructs in ES6 do: they only call
`return()` if iteration stops abruptly.
Only because
-discuss list
Subject: Re: Forwarding `return()` in generators
Right, it doesn’t look like one needs to know the returned value when
forwarding `return()`.
But: you need to guard against other ways of reaching `finally`. Maybe like
this:
```js
function* take(n, iterable) {
let
Right. Always closing is much simpler. Otherwise, you’d have to check
whether everything was exhausted or not.
This is by design, FWIW.
Which is OK, I’m more worried about generators behaving differently in reaction
to `return()` than, e.g., array iterators. With the latter, you can
Axel Rauschmayer wrote:
Right. Always closing is much simpler. Otherwise, you’d have to check
whether everything was exhausted or not.
This is by design, FWIW.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Axel Rauschmayer schrieb:
Right, it doesn’t look like one needs to know the returned value when
forwarding `return()`.
Yeah, to support the iterator protocol as yield* does it one would need
to forward that value. That might be another good use case for a meta
property. However, I haven't
, 2015 2:28 PM
To: Bergi
Cc: es-discuss list
Subject: Re: Forwarding `return()` in generators
Right, it doesn’t look like one needs to know the returned value when
forwarding `return()`.
But: you need to guard against other ways of reaching `finally`. Maybe like
this:
```js
function* take(n
Right, it doesn’t look like one needs to know the returned value when
forwarding `return()`.
But: you need to guard against other ways of reaching `finally`. Maybe like
this:
```js
function* take(n, iterable) {
let iterator = iterable[Symbol.iterator]();
n = +n; // make sure it's a
AFAICT, `return()` throwing an exception (versus performing a `return`) is
necessary if you want to forward it like in the following code:
```js
function* take(n, iterable) {
let iterator = iterable[Symbol.iterator]();
try {
while (n 0) {
let item = iterator.next();
Axel Rauschmayer wrote:
AFAICT, `return()` throwing an exception (versus performing a `return`) is
necessary
It's not necessary, it just might be a bit more complicated:
function* take(n, iterable) {
let iterator = iterable[Symbol.iterator]();
n = +n; // make sure it's a
14 matches
Mail list logo
