Problem with exhaustiveness check for tagged unions

[dhcmrlchtdj]

TypeScript Version: 2.7.0-dev.20171202

Code

interface Square {
    kind: "square";
    size: number;
}

interface Circle {
    kind: "circle";
    radius: number;
}

type Shape = Square | Circle;

function withDefault(s1: Shape, s2: Shape): string {
    switch (s1.kind) {
        case "square":
            return "1";
        case "circle":
            switch (s2.kind) {
                case "square":
                    return "2";
                case "circle":
                    return "3";
                default:
                    return "never";
            }
    }
}

function withoutDefault(s1: Shape, s2: Shape): string {
    switch (s1.kind) {
        case "square":
            return "1";
        case "circle":
            switch (s2.kind) {
                case "square":
                    return "2";
                case "circle":
                    return "3";
            }
    }
}

run with tsc --strict

Expected behavior:
Shape has two kinds only, there is no error with withoutDefault.

Actual behavior:
error TS2366: Function lacks ending return statement and return type does not include 'undefined'.

[mhegazy]

This is a design limitation for the current implementation. the control flow graph is setup at an earlier stage of compilation, where types are not known; so a switch statement is considered exhaustive iff it has a default label and none of the next statement is not reachable for any of the labels (e.g. all have a return statement). When types are known later on, the checker chooses not to show the error for some switch statements if it can assert that they handle all possible types in the union. this is a rather limited set, e.g. single switch at the end of the function, but does not work with more complicated control flow graphs. this is why the error is not reported on the top one but on the nested one.

[dhcmrlchtdj]

Thanks for you reply.

[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.