Create flag strictVariableInitialization

Inizia esaminando il comportamento proposto di strictVariableInitialization e i relativi esempi di Closure motivanti, quindi confrontalo con strictPropertyInitialization. Definisci come devono essere gestiti i percorsi di codice raggiungibili e i tipi che includono undefined; il lavoro è concluso quando la proposta ha un design definito e un comportamento corrispondente del compilatore senza modificare il JavaScript emesso.

🔍 Search Terms

uninitialized variable, undefined, closure, strict property initialization,

✅ 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

I would like to see a check that ensures that no variable whose type is not permitted to be undefined may remain uninitialized at the end of its scope.

📃 Motivating Example

TypeScript allows unsafety that can and does catch users by surprise when using variables in a closure. Normally, TS won't let you access an uninitialized variable:

function doSomething() {
   let foo: string;
   foo.toLowerCase(); // TS ERROR: Variable 'foo' is used before being assigned 
}

However, TypeScript optimistically assumes that variables are initialized when used in closures.

let foo: string;

function printFoo() {
    console.log(foo.toLowerCase());
}

printFoo(); // Uncaught TypeError: Cannot read properties of undefined (reading 'toLowerCase')

That's for good reason, but sometimes, as in the above case, this is provably unsafe, since foo is guaranteed not to be initialized.

The new flag "strictVariableInitialization" ensures that a variable must be initialized by the end of all reachable codepaths in its scope.

let foo: string; // (proposed) TS ERROR: `foo` is not initialized in all reachable codepaths 

function printFoo() {
    console.log(foo.toLowerCase());
}

printFoo()

Of course, variables whose type includes undefined are still permitted to be uninitialized.

let foo: string | undefined;

function printFoo() {
    console.log(foo?.toLowerCase());
}

printFoo();

This check is highly analogous to strictPropertyInitialization for classes.

💻 Use Cases

See https://github.com/typescript-eslint/typescript-eslint/issues/9565 for a somewhat-wordier proposal in typescript-eslint, and https://github.com/typescript-eslint/typescript-eslint/issues/4513 and https://github.com/typescript-eslint/typescript-eslint/issues/10055#issuecomment-2374797860 for cases where this has caused confusion in the wild.

In short, people who have written code that does check for initialization of non-nullable variables become confused by the linter informing them that the check is unnecessary according to the types, even though they can see that it is necessary at runtime:

let foo: Something

function useFoo() {
   if (foo != null) { // linter flags this condition as unnecessary since foo cannot be nullish
      foo.bar();
   }
}

The code should be rewritten as

let foo: Something | undefined

function useFoo() {
   if (foo != null) {
      foo.bar();
   }
}