Specifying for-in enumeration order
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.
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
[[Delete]]methods called during iteration, except by
- No non-enumerable property shadows an enumerable one.
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.
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.