tc39 / proposal-for-in-order Goto Github PK

See tc39/ecma262#1524

This achieved Stage 2 in June 2019.

Also, should be nice to report a tracking issue for Stage 3 requesting the sign off from the reviewers. From the notes:

• POK & NLT are reviewing together as Stripe
• looking to ask WH and potentially other for the required additional reviewers

This proposal achieved stage 3 at the October 2019 meeting. This is a tracking issue for getting stage 4 per the TC39 process.

• committee consensus
• open PR to the spec
• all editors have approved the spec PR
• test262 tests
  • written
  • merged
• two compliant implementations
  • SpiderMonkey
  • v8
  • ChakraCore
  • JSC
• significant in-the-field experience

By my reading of the spec for Object.keys(), plus this spec, this seems to make Object.keys() behave similarly to Reflect.ownKeys(), except for taking enumerability into account. In particular it delegates to [[OwnPropertyKeys]], and thus (for ordinary objects) follows the array-indices, chronological string properties, chronological symbol properties order.

This is a bit hard to make out because the spec in this repo contains a lot of machinery to deal with the prototype chain and mutations during iteration, but for Object.keys() where none of those things are a problem, I think it just ends up as [[OwnPropertyKeys]].

Assuming this is intended, I think it could be a bit more explicit:

• Update the README to mention the impact on Object.keys().
• Make sure test262 tests also test Object.keys().
• Potentially consider simplifying the spec for Object.keys(), which after this proposal will go through a lot of indirections, but I think in the end you just want to delete the final re-ordering step of EnumerableOwnPropertyNames.

Since this proposal advanced to Stage 1 in September 2018, could you transfer ownership to TC39-transfer so we can get it into the TC39 org? (Additionally, you should add that it reached stage 1 in 09/2018 in the README somewhere! Here's the notes link)

Since for-in is getting looked at I thought I'd ask what'd people's opinion be on having a version of for-in that only looks at own properties instead of traversing the entire prototype chain.

Someone has already attempted to talk about this with @littledan, but as you can see the discussion ended quickly.

I have also tested object property iteration performance in V8 and as can be seen for-in outperforms the alternative by a huge margin in cases where the prototype chain lacks any enumerable properties.

Historically, people had to resort to a more imperative style of iterating over object keys like so:

const _has = Object.prototype.hasOwnProperty;

for (const key in obj) {
  if (_has.call(obj, key)) continue;
  // ...
}

// or

for (const key in obj) {
  if (Object.prototype.hasOwnProperty.call(obj, key)) continue;
  // ...
}

Of course this misses the "fast path" in V8 and most likely other engines if there is a single enumerable property in the prototype chain, but Object.{keys,values,entries} can also not be made faster than they already are due to having to manifest an array of the keys instead of lazily enumerating them like for-in.

Writing the above example this way:

for own (const ownKey in obj) {
  // ...
}

Having an alternative syntax that is more declarative and enables better optimizations would be delightful.

Current proposed spec text says

the iterator must behave [...] until either O or an object in its prototype chain has its [[SetPrototypeOf]], [[DefineOwnProperty]], or [[Delete]] internal method invoked

Unfortunately, [[DefineOwnProperty]] is invoked even if you're just doing an ordinary write to an existing enumerable data property. I'd like to put that in the deterministic case. One idea: say

its [[SetPrototypeOf]], [[Delete]], or [[DefineOwnProperty]] internal method invoked, except if [[DefineOwnProperty]] was invoked as step 3.d.iv of OrdinarySetWithOwnDescriptor

That could be expanded to include the case where an property is added to the object being iterated (but not a property added to its prototype) by saying

its [[SetPrototypeOf]], [[Delete]], or [[DefineOwnProperty]] internal method invoked, except if [[DefineOwnProperty]] was invoked in step 3.d.iv of OrdinarySetWithOwnDescriptor or if [[DefineOwnProperty]] was invoked with receiver O in step 3.e.ii of OrdinarySetWithOwnDescriptor

but that's getting really ugly.

Current spec text says

the iterator must behave as if it were the iterator given by CreateForInIterator ( O ) until either O or an object in its prototype chain has its [[SetPrototypeOf]], [[DefineOwnProperty]], or [[Delete]] internal method invoked

Unfortunately, the [[DefineOwnProperty]] method is triggered during OrdinarySet, both when updating an existing own property and when setting a new property. That means the spec text, as written, allows engines to do whatever they want as soon as sets or updates a property on the object or its prototype. And that means that one of the real constraints is not captured, namely, "properties which are added to the base object being iterated after iteration begins are not returned".

I (or someone) should figure out how to avoid this. Maybe it is possible to say something like "[[DefineOwnProperty]], except when called via OrdinarySet on O"?

This proposal achieved stage 2 at the June 2019 meeting. This is a tracking issue for getting stage 3 per the process.

• Complete spec text
• Designated reviewers sign-off:
  • Pieter Ouwerkerk and Noah Tye from Stripe
  • someone else TBD
• Editor sign-off
  • @ljharb
  • @zenparsing
• Basic test262 tests in a PR (may or may not be a requirement, but I want to do this before going for stage 3)
• Committee consensus