unreachable code detection for switch cases out of range of string literal types

[zpdDG4gta8XKpMCd]

type foo = 'hey' | 'nay';

switch (<foo>undefined) {
    case 'boom': console.log('never the case'); break; // expected unreachable code, actual no problem
}

[RyanCavanaugh]

This is somewhat surprising -- we should be issuing an error that boom isn't assignable to 'hey'|'nay'. @DanielRosenwasser what's your take?

[DanielRosenwasser]

"boom" is a string, and "hey" | "nay" are assignable to strings, so you can check against the two.

We could contextually type case expressions, but how exactly is this different from (<foo>undefined) === "boom"? I'd love to fix this, but it's not clear how. This needs a proposal first.

[zpdDG4gta8XKpMCd]

In this case "boom" isn't just a string (expression), but a string literal which we can immediately match against known cases, don't we?

[DanielRosenwasser]

Check out #6196 which will make this do exactly what you want.

[zpdDG4gta8XKpMCd]

I will, thanks a lot!

[zpdDG4gta8XKpMCd]

it works!

let baz : 'foo' | 'bar';
switch (baz) {
   case 'baz': console.log('hey!');break;
}

gives

test.ts(3,9): error TS2322: Type '"baz"' is not assignable to type '"foo" | "bar"'.
  Type '"baz"' is not assignable to type '"bar"'.

looking to see it merged in

[pocesar]

1.8 isn't complaining about a declared type of the following:

// in a node_module with a typings field
export declare type OrderStatus = 'CREATED' | 'WAITING' | 'PAID' | 'NOT_PAID' | 'REVERTED';

                scope['status'] = (item: IModelTransaction) => {
                    switch (item.status) {  // where > item.status: OrderStatus;
                        case 'CRATED': // not complaining and compiling
                            return 'Criado';
                        case 'PAID':
                            return 'Pago';
                        case 'WAITING':
                            return 'Aguardando';
                        case 'REVERTED':
                            return 'Estornado';
                        case 'NOT_PAID':
                            return 'Não pago';
                    }
                };

[DanielRosenwasser]

Yes, the issue won't be fixed in 1.8

[RyanCavanaugh]

@DanielRosenwasser are the labels on this issue correct?