Unintuitive behaviour of exhaustive switch with widening literals

[crobi]

TypeScript Version: both 2.1.1 and nightly (2.2.0-dev.20161127)

Code

// --strictNullChecks

class A {
  readonly kind = "A"; // (property) A.kind: "A"
}

class B {
  readonly kind = "B"; // (property) B.kind: "B"
}

function f(value: A | B): number {
  switch(value.kind) {
    case "A": return 0;
    case "B": return 1;
  }
  value; // (parameter) value: never
}

Expected behavior:

Compiles without errors.

Actual behavior:

Does not compile with TS2366: Function lacks ending return statement and return type does not include 'undefined'.

Note: The VS Code mouse over tooltips (shown as comments in the code above) show that the compiler has determined the type of the kind properties as string literals ("A" and "B", respectively), and it has determined that the end of function f is unreachable (value has type never).

As far as I can see, this has to do with widening/non-widening literals, as explicitly annotating the kind properties (e.g, readonly kind: "A" = "A") makes the code compile. It is not intuitive why this would affect TS2366, especially since the control flow analysis seems to have determined that the switch statement is exhaustive.

[hmaurer]

I have encountered an similar error:

enum Enum1 {
    A,
    B
}

enum Enum2 {
    A
}


interface Foo {
    readonly kind: Enum1
}

interface Bar {
    readonly kind: Enum2
}

let f = (x: Foo): number => {
    switch (x.kind) {
        case Enum1.A:
            return 1;
        case Enum1.B:
            return 2;
    }
}

let g = (x: Bar): number => {
    switch (x.kind) {
        case Enum2.A:
            return 1;
    }
}

Expected behaviour (as far as I know):

Compiles without error

Actual behaviour:

Does not compile with TS2366: Function lacks ending return statement and return type does not include 'undefined'. if "strict null checks" are enabled.

Without strict null checks, it compiles without error.

[RyanCavanaugh]

@A3gis can you please log a separate bug? Thanks!

[hmaurer]

@RyanCavanaugh yes of course, #12771