Performance of iterator .next() as specified

Brendan Eich brendan at mozilla.org
Sat Jul 11 14:39:30 UTC 2015


Generators (in similar manner and for similar reasons as in PEP-380) can 
return a value via a `return` statement. This requires a pair {value, 
done}, you cannot do it with a sentinel such as your item (3).

BTW at ECOOP in Prague this past week, I heard from folks (I forget 
whether it was Till Schneiderheit or Andy Wingo) that the 
object-per-iteration cost avoidance optimizations are about to land in 
one of the top engines.

/be

David Bonnet wrote:
> Sorry for bringing this up again, especially now that the specification has been finalised. However, I can’t really understand the rationale behind the design of `Iterator.next()`.
>
> There are at least three possible options for the behaviour of `Iterator.next()`:
> 1. Returning a value and throwing `StopIteration` when done.
> 2. Returning {value, done} object with `done = true` when done.
> 3. Returning a value and returning `Symbol.iterationDone` when done.
>
> I understand that option 1 would require trapping the exception.
>
> Option 2 would require creating an object at each call, which as discussed in this thread, would require non-trivial optimisations.
>
> Option 3, however, seems IMHO to have no caveats, and would require adding another symbol (`Symbol.iterationDone`) along with `Symbol.iterator`.
>
> So why was option 2 chosen? Why not option 3? All I could find is a discussion that still refers option 1:
> http://wiki.ecmascript.org/doku.php?id=harmony:iterators
>
> Cheers,
> David


More information about the es-discuss mailing list