Ecma262: Is ascending chronological order of property creation always defined?

[ByteEater-pl]

The current draft mentions the term "ascending chronological order of property creation" 6 times. It seems (and if so, I suggest it's worth mentioning, e.g. in a note) that in some cases this may be undefined. Is Array.prototype.concat before, after or unrelated to Array.prototype.slice? Same with properties of host objects. Also value and done of iterator results.

[ljharb]

The order you'd read them in the specification is chronological; I'd expect if X appears above Y, X was created "first".

[bakkot]

The order you'd read them in the specification is chronological; I'd expect if X appears above Y, X was created "first".

This is not something the spec requires (or which is consistent between engines).

[ljharb]

TIL. Is that something worth making consistent? or is it better to leave it arbitrary?

[bakkot]

I don't think engines are going to be inclined to make the order of properties on built-ins consistent, and I don't think people are likely to rely on a particular order, so I think it makes sense to leave it as arbitrary.

As the OP points out, it's probably worth noting this.

[erights]

Ohhh. This seems like a completely unnecessary non-determinism of the spec. All con and no pro that I see. Why not canonicalize? Spec order seems like a fine basis.

[anba]

I don't think engines are going to be inclined to make the order of properties on built-ins consistent, [...]

Agreed. This will likely cause headache for implementers for various reasons. For example certain properties on the global object are lazily initialised in most engines for performance reasons (the global object contains _many_ properties in browsers). And even when ignoring the global object, properties on built-ins may be added in a different order for _interesting_ reasons like for example https://phabricator.services.mozilla.com/D77673.