Repository navigation
feat: support __proto__ in object literal (type-check only) - #42359
Jack Works (Jack-Works) wants to merge 1 commit into
Conversation
3e9ef62 to
6f3ef5d
Compare
|
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. |
|
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
| var x6 = { __proto__: __proto__ }; | ||
| var x7 = { __proto__: function () { } }; |
There was a problem hiding this comment.
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 });There was a problem hiding this comment.
Does ES5 support { ['__proto__']: val}?
There was a problem hiding this comment.
Oops, not lucky
| (function (e) { | ||
| e[e["__proto__"] = 1] = "__proto__"; | ||
| })(e || (e = {})); |
There was a problem hiding this comment.
This is incorrect because of the legacy __proto__ accessor, so it has to use Object.defineProperty.
| { | ||
| var __proto__1 = (_b = {}, _b['__proto__'] = 1, _b).__proto__; | ||
| } |
There was a problem hiding this comment.
Same here for the definition of _b.
| var z1 = __assign(__assign({}, ({ a: '' })), { __proto__: o }); | ||
| var z2 = __assign({ __proto__: o }, ({ a: '' })); |
There was a problem hiding this comment.
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.
| __proto__: 0 | ||
| __proto__: {} | ||
| }; | ||
| var b1 = o1["__proto__"]; |
There was a problem hiding this comment.
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__"]: ... }.
There was a problem hiding this comment.
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; }'.
|
Now I only change the type checker around |
|
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 As long as |
|
Nathan Shively-Sanders (@sandersn) This PR is about the proto literal syntax which is not normative optional. |
|
Nathan Shively-Sanders (@sandersn) re:
If Typescript is intended to be used for authoring code that targets the web, then Annex B support is required:
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" |
|
The object literal form of The |
|
👀 This PR has been 13 months, is there any progression? |
|
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. |
related #38385
close #13933
Related:
https://tc39.es/ecma262/#sec-__proto__-property-names-in-object-initializers
tc39/ecma262#2125