Repository navigation
Enum with computed values, causes weird bug in union type exhaustion #18393
Description
TypeScript Version: 2.5.2
Working:
enum E {
A = 2,
B = 1 // <- constant value
}
function assertNever(obj: never, msg?: string): never {
throw new Error(msg || `Unsupported option: ${obj}`);
}
function resolve(o: E) {
switch (o) {
case E.A: return 1;
case E.B: return 2;
default:
assertNever(o);
}
}Not working:
enum E {
A = 2,
B = 2 << 1 // <- computed value
}
function assertNever(obj: never, msg?: string): never {
throw new Error(msg || `Unsupported option: ${obj}`);
}
function resolve(o: E) {
switch (o) {
case E.A: return 1;
case E.B: return 2;
default:
assertNever(o); // Argument of type 'E' is not assignable to parameter of type 'never'.
}
}Expected behavior:
The compiler should recognize that the types of o has been exhausted,
even though the enum has a bit shifted value.
Actual behavior:
Compile error:
Argument of type 'E' is not assignable to parameter of type 'never'.
Activity
DanielRosenwasser commentedon Sep 11, 2017
Simpler case:
I think the problem may be that TypeScript is not diving into computed enum. For example, the following enum also triggers this:
[-]Enum with bit-shifted values, causes weird bug in union type exhaustion[/-][+]Enum with computed values, causes weird bug in union type exhaustion[/+]thetrompf commentedon Sep 11, 2017
Nice catch, I updated the issue description to basically use your case.
mhegazy commentedon Sep 12, 2017
Under the covered there are really two kinds of enums, computed and union. This is needed to allow narrowing for enums/ treat them as unions, without breaking flag enums. having any expression in an enum initializer makes the enum behave as a flag enum (i.e. an open subset of the number domain) rather than a union enum (a collection of unit types)
mhegazy commentedon Sep 26, 2017
Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.