Property ordering of [[Enumerate]] / getOwnPropertyNames()

Allen Wirfs-Brock allen at
Fri Aug 21 00:40:11 UTC 2015

On Aug 20, 2015, at 9:54 AM, Jesse McCarthy wrote:

> I just want to confirm some things about property enumeration order of plain Objects. I apologize that this has probably already been discussed before, but it's hard to locate a clear answer. Please note that I'm solely asking about ES2015 spec compliance, not what's in the wild.
> Given:
> ```js
> var y = Object.create(null);
> // Note that property names are all strings.
> = 1;
> y.two = 2;
> y.three = 3;
> ```
> This is my understanding of what's guaranteed (or not) about enumeration order (in the context of the example given):
> 1. No guarantee of order
> Anything that relies on or has property-order equivalence with `[[Enumerate]]` or `EnumerableOwnNames`
> 1b. for (x in y)
> 1c. Object.keys(y)
> This is based on the statement in 9.1.11 [[Enumerate]] () step 1:
>> The mechanics and order of enumerating the properties is not specified
> Although it says that...
>> [[Enumerate]] must obtain the own property keys of the target object as if by calling its [[OwnPropertyKeys]] internal method.
> ...and `[[OwnPropertyKeys]]` specifies ordering, my reading is that `[[Enumerate]]` doesn't guarantee that the iterator it returns will preserve the order returned by `[[OwnPropertyKeys]]`.

Correct.  Historically, the for-in order was not defined and there has been variation among browser implementations in the order they produce.(and other specifics).   ES5 added Object.keys and the requirement that  it should order the keys identically to for-in. During development of both ES5 and ES6 the possibility of defining a defining a specific for-in order was considered but not adopted because of  web legacy compatibility concerns and uncertainly about the willingness of browsers to make changes in the ordering they currently produce. 

If we decided to specify the for-in order it would be the order produced by the informative algorithm provided in 9.1.11.

As a step in that direction, we should consider for ES7 adding to 9.1.11 something like:

    If the target object's [[Prototype]] is null, then properties have the same relative ordering for both  [[Enumerate]] and [[OwnPropertyKeys]]

> 2. Guarantee of insertion order (['one', 'two', 'three'])
> Object.getOwnPropertyNames(y)

> Are those interpretations correct?
> Related:
> In this thread...
> ...Bergi asked these pertinent questions that no one answered:
>> But why was the default object [[enumerate]] algorithm not specced to match the [[OwnPropertyKeys]] order then?
>> ...
>> Shouldn't we add a guarantee to [[enumerate]] that the subset of enumerated own properties comes in insertion order as well?

legacy concerns, see above and numerous  historic es-discuss threads


> This is partly in reference to
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list