[Jack Works (Jack-Works)]

related #38385
close #13933

Related:

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

tc39/ecma262#2125

Re-open of PR #42359

[TypeScript Bot (typescript-bot)]

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

[Daniel Rosenwasser (DanielRosenwasser)]

To be honest, I don't think we want the complexity of ever thinking about __proto__ in TypeScript. The corresponding issue received 2 votes over 5 years, so I don't think it would make sense to bring this change in.

[Kevin Gibbons (bakkot)]

#39882 has another 11, from a mostly different set of people.

Anyway, while I think it's fair to not want to think about prototypes, it seems a shame to say that let x = { __proto__: null }; is forever going to be typed as an object with a __proto__ property of null, meaning that __proto__ is suggested in autocompletes and so on.

[Joshua Chen (Josh-Cena)]

It's standard ECMAScript syntax, so even if we don't bring in the whole prototypical semantics, it should at least be special-cased to not mess with valid things like const map: Record<string, string> = { __proto__: null }

[Jack Works (Jack-Works)]

This PR doesn't bring "prototype" into the type system. It will treat { __proto__: x, ...rest } as type typeof { ...x, ...rest }.

[Nathan Shively-Sanders (sandersn)]

Kevin Gibbons (@bakkot) Joshua Chen (@Josh-Cena) Jack Works (@Jack-Works) can you make your case on an issue instead of on a PR? Changes to checker.ts, especially, bit-rot quickly and technical concerns get confused with semantics.

[Nathan Shively-Sanders (sandersn)]

To help with PR housekeeping, I'm going to close this PR while it's still waiting on its bug to be accepted. We can open again once that happens.