Skip to content
No description, website, or topics provided.
Branch: master
Clone or download
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
exploration begin actual proposal (#4) May 25, 2019
README.md Fix readme to point to new location May 29, 2019
index.html spec for in iterator (#5) May 27, 2019
package-lock.json begin actual proposal (#4) May 25, 2019
package.json begin actual proposal (#4) May 25, 2019
spec.html spec for in iterator (#5) May 27, 2019

README.md

Specifying for-in enumeration order

(Partially.)

ECMA-262 leaves the order of for (a in b) ... almost totally unspecified, but real engines tend to be consistent in at least some cases. Furthermore, over the years implementations have observed that anyone who wants to run code on the web needs to follow some contraints not captured by the spec.

This is a stage 1 proposal to begin fixing that.

Background

Historical efforts to get consensus on a complete specification of the order of for-in have repeatedly failed, in part because all engines have their own idiosyncratic implementations which are the result of a great deal of work and which they don't really want to revisit.

See the exploration directory for background and test cases from before this was a concrete proposal.

A conservative underapproximation of interop semantics

From this list of interop semantics we can derive a conservative underapproximation of cases where engines already agree, which I believe covers the most common common cases. Specifically:

  • Neither the object being iterated nor anything in its prototype chain is exotic.
  • Neither the object being iterated nor anything in its prototype has their [[SetPrototypeOf]], [[DefineOwnProperty]], and [[Delete]] methods called during iteration, except by EnumerateObjectProperties itself.
  • No non-enumerable property shadows an enumerable one.

The first two are fairly easy to specify in prose; the third is somewhat harder. As far as I know JavaScriptCore is the only engine which will output anything in this case, because of this longstanding bug.

In addition, since the only case where calling [[Delete]] but not [[DefineOwnProperty]] leads to divergence in engine behavior is only divergent in ChakraCore and XS, I'm hoping it can be removed from the list in the second bullet point above.

Spec text

See candidate spec text. This does not yet capture the "no non-enumerable property shadows an enumerable one" constraint above, because I am having trouble figuring out how to say that.

You can’t perform that action at this time.