> ## Revisiting: Generator Issues > (Jafar Husain) > > [...] > > JH: The crucial problem: the iterator claims to be an iterable and it's not. > ...If async generators return Iterables, not Iterators. > > WH: How > > JH: If I accept an iterable and invoke `@@iterator`, I would expect to get a > fresh iterator from each call > > MM: everythime you for-of you expect to see "the stuff" > > JH: Iterators are claiming to Iterables, which is a lie.
I argued this very point in the past (after a discussion with Dmitry), but wasn't very successful: https://mail.mozilla.org/pipermail/es-discuss/2013-March/029004.html I agree with you on this point, and still think that the current iterator/iterable model is rather incoherent and the iterable concept thus not really useful -- you cannot reliably write abstractions based on it. > Proposal: > > - for...of always assume generator creation > - for...of alwayss terminates generator function > > Lost in cross talk... > > NM: If you know that iterable creates a fresh iterator, it's very reasonable > to close it every time. If you don't know that, then Andy's argument holds. > > JH: The value proposition of for-of is that you don't need to work with > iterators > > AWB: We _could_ add a `return()` method. > ... It's a bigger change, but we could make for-of invoke `return()` on exit > or completion This would be a _significant_ cost. One reason we got rid of the StopIteration protocol was the performance cost incurred by having to wrap all loops into implicit try-statements, which are costly. This proposal asks for re-introducing the same cost. I'm strongly opposed, as it would likely put for-of at a measurable performance disadvantage against for-in, which we'd like to deprecate. > YK: doubt we can come to a conclusion on this > > AWB: We _must_ come to a tentative conclusion > > JH: Confirm, let's try. > > MM: Agree with Allen > > > #### Plausible Solution: > > MM: > - continue to have iterators have an @@iterator, classified as iterables > - continue to have generators return an iterator+ > - continue to for-of on an iterator > - we change: > - generator instances have a `return` that when invoked, caused the yield > point to take the return path, returning the argument that was provided to > the return method. [AWB: actually, needs to return a IteratorResult object: > {done: true, value: returnMethodArgument} ] > - the for-of behaviour is extended with an equivalent of a finally cause > that feature tests for presence of return, if present, call it on any > abnormal exit from the loop, normal or abnormal. [AWB:no change is necessary > for normal loop complextion because the return from the generator body that > sets the completion object to {done: true} will run any finally code in the > generator body] And given that everything in JavaScript is mutable under your feet, when would the check for the presence of this method occur? As a programmer, I'd expect it to happen at the exit point, but then you can almost never optimise away the cost of the try-wrapper. Similar issues apply to yield*, btw. /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
