Repository navigation
Uninitialized variables work around strictNullChecks #13884
Description
Activity
Ping! This still feels broken to me.
I've been bitten by this too, this seems broken that
let foo: Foo;can be an allowed statement with--strictNullChecks.It's not even that TS is unaware that it's potentially undefined as the below snippet does error.
interface Foo { name: () => string; } let foo: Foo; foo.name(); // foo.ts(6,1): error TS2454: Variable 'foo' is used before being assigned.Have you tried
const?Using
consterrors withfoo.ts(5,7): error TS1155: 'const' declarations must be initializedwhich is nice, but in a case where a variable may or may not be set later (necessitatinglet), I would like the type checker to prevent me from assuming it's certainly defined later.You can add
| undefinedto such variables. I agree that it's a shortcomming of the compiler that it's unable to track whether a variable is initialized inside closures, but that's because you can't know whether the closure is immediately invoked or stored for later use.Ah, my example was a bit unclear. I'm fine with TS being unable to know when a variable has been initialized in a closure. I'm advocating for the same expected behavior as the OP, no error at line 6 but an error at line 5
Type 'undefined' is not assignable to type 'Foo'which does not require tracking of initialization beyond the variables declaration statement.Well, that's kind of unpractical for deferred initializations such as in
if/else.Sure, but I'm not enabling
--strictNullChecksand using TypeScript for the practicality and free-wheeling spirit of initializing variables however I please 😉 . When I've declared a variable to be of a particular type, I've explicitly expressed the desire forundefinedto not be considered a member of that type, and I assignundefinedto that variable somewhere in my program (regardless of if I potentially re-assign to a valid type elsewhere, such as in yourif/elseexample), I expect a reasonable compiler to provide me with an error.I'm sure there are cases where this necessitates additional
!operators throughout the code, but that's to be expected if indeed a particular Object "is possibly 'undefined'".Reacted by alex1001xela and ヽ◕◡◕✿ノWell, that's kind of unpractical for deferred initializations such as in if/else.
Coming from a CoffeeScript background, this seems like a non-sequitur to me. I consider deferred initialization to be a bit of a code smell and tend to rely on immediately invoked function expressions for complicated initialization:
var x = (function() { // can even use complicated control flow switch (y) { case 1: return 'foo'; case 2: return 'bar'; default: return 'unknown'; } })();CoffeeScript has syntax sugar for IIFE's with
donotation that makes this even more idiomatic.The point is, instead of forcing the compiler to reason about variable initialization (which isn't complete because it can't deal with closures), just do complicated initialization via IIFE's. Syntax sugar is nice but it's workable without.
Ronuk Raval (@rraval) But then, how do you express self referential initializations?
let self = { x: 4, doSomething: () => self.x + self.x }
It can be made a special case, however I think the current situation strikes a good compromise:
constvariables are always initialized. As a bonus they are assigned just once, which is a good thing- you can have a convention to always initialize
letvariables or add| undefinedto the lazily inited ones and enforce it by a lint rule
Marin Marinov (@gcnew) I'm not sure I follow. The following code seems perfectly reasonable to me:
let self = { x: 4, doSomething: () => self.x + self.x };
selfwould have type{x: Number, doSomething: () => Number}, which the() => self.x + self.xexpression captures and everything should typecheck cleanly.Here's a thornier example that currently breaks even with
const:function indirection(func: () => Number): Number { return func(); } const foo: {a: Number, b: Number} = { a: 1, b: indirection(() => foo.a), };
This results in a runtime
TypeErrorbecausefooisundefinedwhen the callback forbis invoked.Here's how I would expect things to work. I might've gotten things horribly wrong so please correct me if so:
- In
strictNullChecks, given a declarationlet x: Torconst x: Twhereundefined ∉ T,xmust be immediately initialized. - In the initializer for
x, function definitions that capturexare split into 2 types:- Simple definitions where the function cannot be passed to anything else will have
x: Tin their body. This means that thedoSomething: () => self.x + self.xfrom your example hasself: {x: Number, doSomething: () => Number}. - If the function //can// be passed to something else, the compiler can no longer reason about when the function gets called. Thus, for the body of the function,
x: T | undefined. For my example,b: indirection(() => foo.a), inside the functionfoo: {a: Number, b: Number} | undefined, at which point the compiler can complain aboutfoo.abecause it no longer typechecks.
- Simple definitions where the function cannot be passed to anything else will have
Point 1 can be made palatable with sugar for IIFE's for complicated initialization.
Point 2.1 should capture the bulk of self referencing function definitions and things just work. This is because the compiler knows that those functions cannot be invoked until after the variable has been initialized.
Point 2.2 is necessary to ensure correctness. The current version of the compiler breaks with a runtime
TypeError, which seems to fly in the face of TypeScript's primary goal.Reacted by Patrick Hulce- In
Ping!
We might as well close this issue if it's just going to languish like this.
Marin Marinov (@gcnew) 's comments already addressed why this is the intended behavior. See #10641, #9382, #10815
let num_or_undefined:number function runtimeerror() { num_or_undefined.toString() } runtimeerror()
How is this not a compile error in strict mode? How can i make it error?
let num_or_undefined:number|undefinedworks as intended, but i have to remember to put |undefined everywhere.I feel like maybe line 1 should be an error?
Something likeType 'undefined' is not assignable to type 'number'.
(it would be better if it could just be automatically considered 'possibly undefined' though)(typescript's not making me feel very type safe)
Reacted by Patrick HulceBrian Terlson (@bterlson) we discussed this at Edge summit way back in September, any chance you followed up? :)
Ryan Cavanaugh (@RyanCavanaugh) Why was this closed? Those fixes don't cover this particular issue.
I think it's especially important to revisit this issue now that
--strictPropertyInitializationis available. With--strictPropertyInitialization, this code correctly emits a compile error:class Foo { private x: number; // Compile-time error! foo() { // `x` isn't initialized! // But it's OK, compile-time error above. return this.x.toString(); } }
But this code compiles successfully:
function fooFactory() { let x: number; return { foo() { // `x` isn't initialized! // Run-time error! return x.toString(); } }; }
Shouldn't there be a
--strictLocalInitializationmode to catch errors like this? I imagine it would work similarly to--strictPropertyInitialization: if a local variable is not synchronously initialized before it's used, a compile error would be emitted. To resolve it, one would need to:A) Initialize the variable in a way that the TypeScript compiler understands (e.g. immediately, or before referencing it in a function somewhere).
-OR-
B) Use a definite assignment assertion. (It seems that this issue would come up naturally when discussing definition assignment assertions for local variables.)
-OR-
C) Explicitly mark the variable as potentially
undefined.
Expanding upon option (B), this code was given as an example in the linked-to blog:
let x!: number[]; initialize(); x.push(4); function initialize() { x = [0, 1, 2, 3]; }
I think that this is a misleading example. That code - in an ideal world where the compiler performs flow analysis - should not need the definite assignment assertion.
However, this code should (and currently does not):
let x: number[]; // Doesn't require definite assignment assertion. function foo() { x.toString(); } foo(); // No compile-time error, but throws an exception.
Thoughts?
Reacted by Olivier Chafik and Patrick HulceAgop Shirinian (@agopshi) you can log a new suggestion for that
- locked and limited conversation to collaborators
on Jul 25, 2018
TypeScript Version: 2.2.0
--strictNullChecksmust be used.Code
Expected behavior:
Error at
let foo: Fooline since the compiler is implicitly doinglet foo: Foo = undefined;.If I were to write the
= undefinedinitializer myself, the compiler properly errors with:Actual behavior:
The code compiles and errors at runtime: