Ecma262: Consider adding a non‑Annex B equivalent to the `__proto__` property initializer (e.g.: `#proto`)

[ExE-Boss]

The __proto__ property initializer mirrors the Object.prototype.__proto__ accessor, but as it’s an Annex B feature, non‑web environments aren’t required to implement it.

For backwards compatibility, the __proto__ property initializer also acts as a normal property initializer for non‑null and non‑object values.

---

A #proto property in object initializers wouldn’t have the same backwards compatibility constraints, and would be free to throw a TypeError for invalid prototype values.

I chose #proto to mirror class private fields, but unlike classes, where the prototype is determined by the extends clause, object initializers don’t have a non-Annex B way to specify the prototype.

This also wouldn’t conflict with class fields, as a #proto private class property would be treated as a normal private class property.

See also:

• https://github.com/engine262/engine262/issues/56
• https://github.com/engine262/engine262/pull/109

[ljharb]

It seems like a Symbol.prototype would probably be a better choice than some new kind of thing (private fields are lexically accessible, not accessible solely via the object, so i'm not sure how that syntax choice would work).

That said, this repo isn't the place for feature requests. Please see https://github.com/tc39/ecma262/blob/master/CONTRIBUTING.md#creating-a-new-proposal for the best places to do that.

[ExE-Boss]

Symbol.prototype is already taken by the Symbol Prototype Object.

[ljharb]

True enough :-) some well-known Symbol, then.

[bakkot]

We have consensus to move the parts of Annex B which do not add ambiguity to the grammar into the main spec anyway, so I don't think there's much motivation for this: __proto__ suffices despite its awkwardness and flaws.