RFC: Support __proto__ literal in object initializers
This is a new issue to specifically propose and elaborate on a feature I raised [in this comment](https://github.com/microsoft/TypeScript/issues/30587#issuecomment-614855795) on #30587. ## Search Terms - \_\_proto__ - prototype - object literal - object spread - object initializer ## Suggestion While accessing or mutating an _existing_ object via the `Object.protptype.__proto__` getter/setter is deprecated, to the best of my knowledge defining the prototype of a _new_ object via the object initializer `__proto__` literal is very much encouraged. The rules for specifying the prototype of a new object via these semantics are very well-specified and safe. [See the relevant section of the spec here.](https://www.ecma-international.org/ecma-262/6.0/index.html#sec-__proto__-property-names-in-object-initializers) ### Basic support Given the following: ```ts const foo = { __proto__: { a: "a" }, b: "b" }; ``` Typescript currently thinks that `foo` is the following shape: ```ts type foo = { ["__proto__"]: { a: string }; b: string; }; ``` when in reality, it is: ```ts type foo = { a: string; b: string; }; ``` TypeScript should be able to correctly detect the type of this object initialization. ### Strict validity checks Additionally, TypeScript should prevent invalid `__proto__` assignments that are "ignored" by the spec, and require all values to be `null` or an object. This should fail validation: ```ts const invalid = { __proto__: "hello" } ``` ### Correct han
Posted by mike-marcacci on May 7, 2020, 4:43 AM
Tags
Related issues
- [BUG] Cowork (Windows): all Plan9 shares fail with "Plan9 mount failed: invalid argument" after Windows update KB5124008 (26200.9445) — uninstalling the KB fixe
- Feature Request: Auto-resume CLI session when usage limit resets
- Please deobfuscate the Python
- [Bug] MLX version of Gemma 4 26B fails to load: "Model type gemma4 not supported" (macOS)
- # 233 Developers Discussed Abandoning the Office Add-in Platform — An Open Letter on the Office.js Stability, Security & Trust Crisis
- [FEATURE] Allow users to configure which shell the Bash tool uses or inherit initial shell
Raise real-world problems, find people facing the same issue, and discuss solutions.3,500 issues0 comments
reliability (Software)
[BUG] Cowork (Windows): all Plan9 shares fail with "Plan9 mount failed: invalid argument" after Windows update KB5124008 (26200.9445) — uninstalling the KB fixe
Feature Request: Auto-resume CLI session when usage limit resets
Please deobfuscate the Python
[Bug] MLX version of Gemma 4 26B fails to load: "Model type gemma4 not supported" (macOS)
# 233 Developers Discussed Abandoning the Office Add-in Platform — An Open Letter on the Office.js Stability, Security & Trust Crisis
[FEATURE] Allow users to configure which shell the Bash tool uses or inherit initial shell
Admin Materials and Surfaces
AMD Support
RFC: Support __proto__ literal in object initializers
This is a new issue to specifically propose and elaborate on a feature I raised [in this comment](https://github.com/microsoft/TypeScript/issues/30587#issuecomment-614855795) on #30587. ## Search Terms - \_\_proto__ - prototype - object literal - object spread - object initializer ## Suggestion While accessing or mutating an _existing_ object via the `Object.protptype.__proto__` getter/setter is deprecated, to the best of my knowledge defining the prototype of a _new_ object via the object initializer `__proto__` literal is very much encouraged. The rules for specifying the prototype of a new object via these semantics are very well-specified and safe. [See the relevant section of the spec here.](https://www.ecma-international.org/ecma-262/6.0/index.html#sec-__proto__-property-names-in-object-initializers) ### Basic support Given the following: ```ts const foo = { __proto__: { a: "a" }, b: "b" }; ``` Typescript currently thinks that `foo` is the following shape: ```ts type foo = { ["__proto__"]: { a: string }; b: string; }; ``` when in reality, it is: ```ts type foo = { a: string; b: string; }; ``` TypeScript should be able to correctly detect the type of this object initialization. ### Strict validity checks Additionally, TypeScript should prevent invalid `__proto__` assignments that are "ignored" by the spec, and require all values to be `null` or an object. This should fail validation: ```ts const invalid = { __proto__: "hello" } ``` ### Correct han
Comments (0)
No comments yet. Start the discussion.