Repository navigation
TS2454 after assigning a value from an exhaustive switch statement #18362
Description
TypeScript Version: 2.4.2
Code
enum Level {
One,
Two,
}
const doSomethingWithLevel = (level: Level) => {
let next: Level;
switch (level) {
case Level.One:
next = Level.Two;
break;
case Level.Two:
next = Level.One;
break;
}
return next; // <-- Error here
};Expected behavior:
Since the switch statement is exhaustive over the enum, the compiler should correctly infer that next is always set and this works without error.
Actual behavior:
(16,10): error TS2454: Variable 'next' is used before being assigned.
Note: replacing the variable assignment with inline returns (e.g. case Level.One: return Level.Two;) appears to negate the problem in this instance, but that isn't an option in the code that this example was derived from since there's additional code that uses the value of next.
Activity
ahejlsberg commentedon Sep 10, 2017
This would require the control flow analyzer to reason about dependencies between variables which is beyond its current capabilities. We're tracking a similar request in #12184. Effectively, definite assignment analysis is limited to conclusions based on the structure of the code.
mhegazy commentedon Sep 25, 2017
Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.
calebsander commentedon Mar 6, 2018
How does this require tracking dependencies between variables? It seems like the compiler should be able to reason that every code path assigns a value to
next.Here is an example of code that similarly fails to compile:
If you uncomment the
elseblock and hover overcharin it, you can see that it has typenever, so the compiler is correctly inferring that that block is unreachable. In other situations where every code path assigns a value to a variable, the compiler does realize that the variable must have been assigned a value:RyanCavanaugh commentedon Mar 6, 2018
Caleb Sander Mateos (@calebsander) there's a distinction between inference that can be done syntactically (the second example) that that which requires type analysis (the first kind).
This is all in principle possible but we don't currently support inference that requires multiple passes that combine syntactic flow and type information. Generalizing your first example to the broadest case implies an analysis that has either an unbounded number of passes, or a completely different inference strategy.