Incorporating exhaustiveness analysis into the control flow of if statements.

🔍 Search Terms

"initialization", "variable", "inference", "assignment", "assigned", "automatic detection"

✅ 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

One's code may implicitely involve that all cases have been processed in an if-else structure. TS does detect it with switch statements, however it does not detect it with if-else clauses.

Consider the following example:

type Dinosaur = "triceratops" | "brachiosaurus"

const myCollectionOfDinosaurs: Dinosaur[] = ["triceratops", "brachiosaurus"]

const randomKey = Math.floor(Math.random() * myCollectionOfDinosaurs.length)
const randomlyChosenDinosaur: Dinosaur = myCollectionOfDinosaurs[randomKey]

let dinosaurGreeting: string

if (randomlyChosenDinosaur === "triceratops") dinosaurGreeting = "Hello triceratops!"
else if (randomlyChosenDinosaur === "brachiosaurus") dinosaurGreeting = "Hello brachiosaurus!"

console.log(dinosaurGreeting)

TS complains on the last line because it says dinosaurGreeting is used before being assigned.

Replacing the if-else clause with a switch statement fixes the problem. However it would be great if TS did support this feature for if-else clauses too.

📃 Motivating Example

I'd use the dinosaurs example above, and assert that this feature would remove unnecessary constraints in the language.

💻 Use Cases

1. What do you want to use this for?
   Writing some meaningful code with less constraints, shaping it more precisely and remaining safe from type-related problems.
2. What shortcomings exist with current approaches?
   Most current approaches involve working around the way you intend your code to work. For example I can use !: when typing the variable, or initialize the variable with a default variable, or define it anywhere it is initialized, but all these solutions would imply thinking the code differently, in a way that is less compatible with my need.
   The best approach is using a switch statement instead of an if-else clause, which doesn't impact the logic of the code.
3. What workarounds are you using in the meantime?
   Replacing the if-else clause with a switch statement.

Start by reproducing the dinosaur example from the issue and compare its definite-assignment behavior with the equivalent switch statement. Trace the compiler's control-flow and exhaustiveness analysis to determine where if-else branches are handled; done means exhaustive branches no longer produce the used-before-assigned error without changing emitted JavaScript.