Support opting-out of type narrowing on assignment

[fabiospampinato]

Suggestion

🔍 Search Terms

• assignment proxy
• assignment narrow
• narrow proxy

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

I think there should be some way to tell TS to not narrow the type of a property when a new value is assigned to that property, to better work with proxies.

📃 Motivating Example

There's currently an issue in how TS works with proxies, in that it's not able to recognize if something is a proxy or not (not even JS at runtime could do that really), so it treats property assignments always the same way.

The problem is that if I assign the value true to a property of a non-proxy object then it's reasonable to make the assumption that that's immediately the new value of that property, that's just how the language works (assuming no property descriptor property messing with that), but if that object is a Proxy anything at all could happen, and TS doesn't understand that.

💻 Use Cases

In Solid there's a type of proxied object called a "mutable store", and one detail about this object is that it will defer assignments to a later point in time if they happen inside a "batch" call, as not doing this would make the system "glitchy".

But TS just can't work with that, so mutable stores become unusable with TS, in the following example TS is certain that the if will never be entered, but as one can see from the console output it is in fact entered at runtime:

https://playground.solidjs.com/?hash=-1767694278&version=1.4.1

[edemaine]

In addition to Proxys, TS has similar issues with objects that have getters/setters. Playground example

One idea is to add a volatile keyword (similar to C's volatile) to the type system that views every property access to an object as a function call (as it really is in JS). This would let users opt-in to this more careful type checking. For example:

type Foo = {foo: number | string};
let obj: volatile Foo = ...; // proxy or object with getters/setters
obj.foo = 'hello';
if (obj.foo === 5) { ... } // no error here

It could also make sense to mark specific properties as volatile (similar to existing readonly annotations), when only some properties have getters/setters:

type Foo = {
  volatile foo: number | string;
  bar: boolean;
}
let obj: Foo = {
  get foo() { ... },
  set foo() { ... },
  bar: true,
};