feat: support __proto__ in object literal (type-check only)

[Jack-Works]

related #38385
close #13933

Related:

https://tc39.es/ecma262/#sec-__proto__-property-names-in-object-initializers

tc39/ecma262#2125

[typescript-bot]

The TypeScript team hasn't accepted the linked issue #38385. If you can get it accepted, this PR will have a better chance of being reviewed.

[typescript-bot]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

[ExE-Boss]

These two have to be transpiled as:

var x6 = {};
Object.defineProperty(x6, "__proto__", { value: __proto__, configurable: true, enumerable: true, writable: true });
var x7 = {};
Object.defineProperty(x7, "__proto__", { value: function () { }, configurable: true, enumerable: true, writable: true });

[Jack-Works]

Does ES5 support { ['__proto__']: val}?

[ExE-Boss]

Unfortunately, it doesn’t.

[Jack-Works]

Oops, not lucky

[ExE-Boss]

This is incorrect because of the legacy __proto__ accessor, so it has to use Object.defineProperty.

[ExE-Boss]

Same here for the definition of _b.

[ExE-Boss]

The __proto__ property initialiser is supposed to set the [[Prototype]] of the first object, so this has to be:

var z1 = Object.setPrototypeOf(__assign({}, ({ a: '' })), o);
var z2 = __assign({ __proto__: o }, ({ a: '' }));

---

Although engines most likely do something like:

var z1 = __assign({ __proto__: o }, ({ a: '' }));
var z2 = __assign({ __proto__: o }, ({ a: '' }));

for both.

[ExE-Boss]

Accessing the __proto__ property like this should be a compile error, unless __proto__ is defined on the global Object interface or the __proto__ property is declared using { ["__proto__"]: ... }.

[Jack-Works]

Yes, as you can see some of my changes reflected that:

tests/cases/conformance/es6/modules/m2.ts(2,21): error TS2339: Property '__proto__' does not exist on type '{ __esmodule: boolean; }'.

[Jack-Works]

Now I only change the type checker around __proto__ I'll revisit @ExE-Boss's review on emitting __proto__ later, maybe some suggestion from the TypeScript team members

[sandersn]

I don't understand the spec process for moving things out of Appendix B. Is there a Stage 1,2,3,4 process? Or does it just need an ad-hoc OK from the committee? Has the __proto__ syntax move finished the process yet?

As long as __proto__ is in appendix B with all the other "icky" stuff, I don't think it's worthwhile supporting it in Typescript.

[Jack-Works]

@sandersn This PR is about the proto literal syntax which is not normative optional.
The optional one is Object.prototype.__proto__ and they're different

[rwaldron]

@sandersn re:

As long as proto is in appendix B with all the other "icky" stuff, I don't think it's worthwhile supporting it in Typescript.

If Typescript is intended to be used for authoring code that targets the web, then Annex B support is required:

The ECMAScript language syntax and semantics defined in this annex are required when the ECMAScript host is a web browser. The content of this annex is normative but optional if the ECMAScript host is not a web browser.

One could argue that the either of those sentences is true, but also that they are false. I think it's reasonable to err on the side of flexibility and go with "Typescript should either act like, or make it possible to configure as, the web"

[Jamesernator]

The object literal form of __proto__ moved out of Annex B in July, so this syntax is canonical and required by the spec. The behaviour of __proto__ is now just a regular part of the definition of parsing object literals.

The Object.prototype.__proto__ accessor remains normative optional, and I don't believe there's any interest of changing that.

[Jack-Works]

👀 This PR has been 13 months, is there any progression?

[Jack-Works]

I changed the branch name of this PR from "master" to "proto-literal-type-checking" and GitHub closes this PR. I opened a new PR, please follow #48816.