Treat `expr satisfies never;` similarly to a call to a never-returning function in CFA

DRANK

🔍 Search Terms Control flow analysys, CFA, satisfies, never, return, termination, assert ✅ 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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals ⭐ Suggestion In CFA, expr satisfies never; statements should be treated similarly to a call to a never-returning function, treating statements that follow as unreachable. I'm suggesting that TS enhance the expr satisfies never; pattern which is one of the ways to do the exhaustiveness check. It is a very popular technique used when dealing with discriminated union types. The ways often used are: // 1-a. assign to a never-typed variable and abort const _exhaustivenessCheck: never = option; throw new Error("unreachable"); // 1-b. return never instead of abort const _exhaustivenessCheck: never = option; return _exhaustivenessCheck; // 2. Call a function that accepts never assertNever(option); // 3-a. Use the satisfies syntax and abort option satisfies never; throw new Error("unreachable"); // 3-b. Use the satisfies syntax and return option satisfies never; return option; Currently, 1 and 3 requires either throwing or returning to terminate the current (unreachable) execution branch. On the other hand, 2 automatically terminates it (assuming that the return type of assertNever is never). My suggestion is that 3 (option satisfies never) also work as a termination point of the current execution branch, so that the following would be possible: // 3-c (suggested behavior). Use the satisfies syntax and that's it! option satisfies never; /* code here is considered unreachable */ I think expr satisfies never; has several advantages compared to others: Doesn't involve unused variables. Unused variables are annoying especially when using linters. Is completely no-op at runtime, which allows minifiers to optimize away more code. Also, notably, expr satisfies never; is explicit enough for the compiler to reason about as part of the CFA. In addition, I think this is also good from a theoretical perspective; never-returning functions are currently treated as a termination point of an execution branch because such functions can never return anything. Actually, this is not specific to functions. If you somehow have a value of type never, you have proven that this code isn't actually executed. expr satisfies never; feels like a good, sensible way to declare that you have a proof. 📃 Motivating Example type Option<T> = { tag: "Some"; value: T; } | { tag: "None"; } function optionToString(option: Option<unknown>): string { let value: string; switch (option.tag) { case "Some": { value = `Some(${option.value})`; break; } case "None": { value = "None"; break; } default: { option satisfies never; // ↑ should have the same effect as: // assertNever(option); } } // Current behavior: error because `value` may not have been assigned. // Suggested behavior: no error here. return `Option(${value})`; } function assertNever(value: never): never { throw new Error("unreachable"); } Playground 💻 Use Cases 1. What do you want to use this for? As shown above, for exhaustiveness checks. 2. What shortcomings exist with current approaches? Live with less optimal (from different aspects) ways. 3. What workarounds are you using in the meantime? assertNever(option);