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
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 numb
alf Of Axel
Rauschmayer
Sent: Tuesday, March 24, 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 `final
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 re
"function") {
> iterator.return();
> }
> }
> }
> ```
>
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org
> <mailto:es-discuss-boun...@mozilla.org>] On Behalf Of Axel Rauschmayer
> Sent: Tuesday, March 24, 2015 2:28 PM
> To: Ber
>> 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.
>
> On
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
https://mail.mozilla.org/listinfo/e
>> 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 c
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 closed
> 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 gener
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
>> 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*]] interna
> On Mar 26, 2015, at 10:50 PM, Axel Rauschmayer wrote:
>
> `return()` being optional is true for arrays:
>
> ...
>
> But it is not true for generators:
but it is...
>
> ```js
> function* elements() {
> yield 'a';
> yield 'b';
> yield 'c';
> }
```js
elements.prototype.return
Axel Rauschmayer wrote:
That is a difference between iterators that you have to be aware of
and that needs to be documented per iterable. It’d be great if all
iterables were indeed the same in this regard.
You're right, of course -- my point was too narrow, I was addressing
only the "can impl
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) ve
16 matches
Mail list logo