Enumerate iterator shape somewhat ambiguous?

[bterlson]

9.1.1 says only that the object must be an iterator and that it must inherit from %IteratorPrototype%. Leaves me wondering:

1. Can the next property be a prototype property of the returned object?
2. Can the iterator object inherit indirectly from %IteratorPrototype%?

I would hope the answers to these are no and no. In either case, the spec text could probably be improved to clarify.

[allenwb]

Nope, the intent is yes and yes. For example, if the informative generator definition was used in the [[Enumerate]] definition, the iterator returned would be a generator object and you would have the yes, yes condition.

Basically, 9.1.11 means exactly and only what it says. The object must inherit from %IteratorPrototype% but not necessarily directly and it must implement the Iterator interface but not necessarily using own properties.

Note that ordinary object property enumeration has always been very implementation dependent and, at least for ES6, TC39 was brave enough to try to precisely specify it.

[allenwb]

Nope, the intent is yes and yes. For example, if the informative generator definition was used in the [[Enumerate]] definition, the iterator returned would be a generator object and you would have the yes, yes condition.

Basically, 9.1.11 means exactly and only what it says. The object must inherit from %IteratorPrototype% but not necessarily directly and it must implement the Iterator interface but not necessarily using own properties.

Note that ordinary object property enumeration has always been very implementation dependent and, at least for ES6, TC39 was brave enough to try to precisely specify it.

[bterlson]

Yes good point about how this API would look if implemented as a generator. Maybe spec should actually say that instead? It seems strange to not be precise about the shape of the object returned here. I don't see how object property enumeration being historically implementation dependent is relevant - this is about the shape of the iterator we return for the Enumerate internal op (and as returned by Reflect.enumerate(obj)) which seems orthogonal to previous enumeration order concerns. Can you clarify?

[bterlson]

Yes good point about how this API would look if implemented as a generator. Maybe spec should actually say that instead? It seems strange to not be precise about the shape of the object returned here. I don't see how object property enumeration being historically implementation dependent is relevant - this is about the shape of the iterator we return for the Enumerate internal op (and as returned by Reflect.enumerate(obj)) which seems orthogonal to previous enumeration order concerns. Can you clarify?

[bterlson]

I guess I'm the only one uncomfortable with this, so closing for now.

Although I do note that FF and Edge are going to agree on Empty object, Object with .next property, %IteratorPrototype%, %ObjectPrototype%.

[bterlson]

I guess I'm the only one uncomfortable with this, so closing for now.

Although I do note that FF and Edge are going to agree on Empty object, Object with .next property, %IteratorPrototype%, %ObjectPrototype%.

[ljharb]

Wait, doesn't the spec require that %IteratorPrototype%.next exists tho?

[ljharb]

Wait, doesn't the spec require that %IteratorPrototype%.next exists tho?

[bterlson]

No. %IteratorPrototype% only has a Symbol.iterator property. The spec requires that a next property exists somewhere in the prototype chain but says nothing about where.

[bterlson]

No. %IteratorPrototype% only has a Symbol.iterator property. The spec requires that a next property exists somewhere in the prototype chain but says nothing about where.