TypeScript: Uninitialized variables work around strictNullChecks (follow-up to #13884)

Accepting PRs. The rule here is that any variable that is read but never written to is an error if the variable doesn’t have undefined in its type.

Implementation note - this needs to be done not as a separate pass. Re-use the existing logic that finds unused locals and refactor it to provide read/write information instead of just read.

No new flag since this should only ever catch true errors – this will be the default behavior for all strictNullChecks compilations.

I would actually rather have the simpler --strictLocalInitialization option that flags any uninitialized declaration which does not have undefined as an allowable type, than a control-flow based feature that allows a subset of such constructs where assignment before use can be proven. And even more so if the control-flow based feature is going to permit some constructs where there is an assignment but it can’t be proven to occur before use – I think the majority of bugs people hope to catch with strictness like this would fall in this category.

It seems a bit weird to ask users to use separate program (tslint) to avoid shortcoming in compiler. I believe there should be an option which forces let to be initialized to a proper type in typescript compiler.

So instead of let x: Foo; you would have to write let x: Foo | undefined; or let x: Foo = undefined as Foo;

I’m not following why this continuously was shot down.

I’m not following why this continuously was shot down. It seems clear that this should be handled by a compiler, not by a lint rule. The language sets uninitialized lets to undefined yet the compiler does not recognize it as such. Why?

@agopshi sure in my example, I don’t really care about the error; it was a trivial example.

It’s just that previous attempts have been shot down because the generic problem is undecidable, and I recognize that fact. It’d be nice to have a surefire way to express that let foo: Foo; is indeed a lie. At the moment that statement compiles just fine, I’ve declared that foo is of type Foo yet it is undefined. I’d like a mode that prevents this contradiction from happening ever rather than silently allowing in the cases where flow analysis fails.

While I appreciate the MS Paint work, I find it tough to have followed 3 different conversation on this topic and even just within this thread seen it flip to suggesting this is better as a lint rule. If there is not fundamental agreement that an uninitialized let is undefined per the language, any work to enforce that via the compiler would be wasted. The path forward needs to be clear for this to be worked on no?

@RyanCavanaugh the TSLint rule is actually the opposite 😃 it seems I will lose this debate yet again and perhaps I’d be better off adding a PR for a rule option to tslint instead, but I still hold that this seems like a fundamental responsibility of a type system.

If I understood his suggestion and call for PRs correctly, the following code would compile fine

let foo: Foo
foo = new Foo()
foo.bar()

But with strictLocalInitialization, it should fail on line 1 with Type 'undefined' is not assignable to type 'Foo'. It’s a much stricter and simpler assertion. Never allow a typedef of let myVar: T if the variable is not immediately initialized

@RyanCavanaugh Right - in your example, since it cannot be proven that assign() is called before use(), I would expect x to be widened to number|undefined in use(). (Or the declaration itself would have to be rewritten as number|undefined or with the definite assignment assertion).

Totally understood that this is impossible with the current control flow analysis architecture. Just discussing ideals. In the meantime, what you proposed would certainly be a welcome addition.

Really excited about the progress here and openness from the team about addressing this thank you! ❤️

As we’ve established, the usage before initialization is an undecidable problem and doing any sort of flow analysis will have its limits. Is there opposition from the typescript team to also adding the proposed strictLocalInitialization option as one step of type safety further? It’s a simple rule (No uninitialized declarations that do not have undefined as an allowable type) and is a surefire way to ensure these issues are handled.

Inlining the effects and requirements of every function call is out of scope in terms of our current flow control analysis architecture.

Nothing we can do will get us 100%, e.g.

// Does what it says
declare function callInRandomOrder(fn1: () => void, fn2: () => void);

let x: number;
function use() {
  x.toString();  // Usage, therefore needs an assignment at some point.
}
function assign() {
  x = 5;  // Assignment, so all is well.
}
callInRandomOrder(use, assign);

The addition of strictPropertyInitialization really makes this quite in line with the other strict* flags and is sorely needed. There aren’t other well-established, automated ways of catching this; ironically, the only lint rule that TSLint offers is the exact opposite of what we want here no-unnecessary-initializer.