Definite assignment for exhaustive switch statements.

[antialize]

Consider the following code

function test4(value: 1 | 2) {
    let x: string;
    switch (value) {
    case 1: x = "one"; break;
    case 2: x = "two"; break;
    }
    return x; //There is no path through the switch so x is alwayes assigned here.
}

Expected behavior:
The code should type check under --strict

Actual behavior:
Definite assignment does not realize that the switch is exhaustive and that all paths assign to x, so we get an error.

Checked with 2143a3f

[DanielRosenwasser]

The problem is that definite assignment doesn't take types into account, it just works on the control flow graph. Adding a default: throw new Error("..."); should do the trick though.

[ghost]

Internally we use (simplified) default: throw assertNever(value); with

function assertNever(value: never): never {
    throw new Error("Illegal value: " + value);
}

[antialize]

I use that as well. Note however that

function test4(value: 1 | 2) {
    let x: string;
    switch (value) {
    case 1: x = "one"; break;
    case 2: x = "two"; break;
    default: assertNever(value); break;
    }
    return x; //There is no path through the switch so x is alwayes assigned here.
}

Will not work due to #20822

[ghost]

Yeah, that's why you have to write throw assertNever(value); to indicate to control flow that it never returns.

[Jessidhia]

not return assertNever(value)?

I do use a similar helper in my code, which I called unreachable.

[ghost]

The function's never going to finish evaluating either way, so it doesn't really matter whether you return or throw the result -- just a style preference.

[DanielRosenwasser]

Armchair perf speculation: return probably won't trigger a de-opt.

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

[methyl]

@andy-ms is this something you plan to tackle in the future?