is an iterator allowed to reuse the same "state" object?

Allen Wirfs-Brock allen at
Tue Apr 28 23:28:20 UTC 2015

On Apr 28, 2015, at 4:21 PM, John Lenz wrote:

> You would hope that the engines might be able to create these objects on the stack but I don't think anyone does that yet and the result is a flood of eden objects.
> I would like to know I'm wrong about this.
did you see 

A really good optimizing jit should be able to inline the 'next' call, recognize that the IterationResult object doesn't escape (it knows this for for-of loops) and not do an allocation at all.


> On Apr 27, 2015 4:59 PM, "Allen Wirfs-Brock" <allen at> wrote:
> On Apr 27, 2015, at 3:29 PM, Tab Atkins Jr. wrote:
>> On Mon, Apr 27, 2015 at 3:11 PM, John Lenz <concavelenz at> wrote:
>>> By which I mean the object that returns the current value and "done" state?
>> IIRC, it's not supposed to.  The built-in iterators will return fresh
>> objects each time, so there's no mutation hazard.  Userland iterators
>> can of course violate this, but at their peril.
> Well, that's not exactly what the ES2015 spec. says.  The specification of the Iterator interface ( ) does not require that the `next` method return a fresh object each time it it called.  So a userland iterator would not be violating anything by reusing a result object.  
> However,  the specifications for all ES2015  built-in iterators require that they return fresh objects.
> None of the built-in consumers of the Iterator interface (for-of, Array.from, etc.) retain references to IteratorResult objects after testing for `done` and accessing the `value`, so semantically they don't care whether the ResultObject is reused. However, such reuse might preclude some otherwise plausible engine level optimizations.  
> Allen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list