TypeScript _does_ detect some such impossible conditions (like `x === 1`), so this omission is intentional.

I think this is partly necessitated by one particularly large soundness hole in TypeScript, which is that expressions are typed as though dictionary and array subscripts are always in bounds:

    function foo(arr: number[]) {
        const m: number = arr[3]; // typechecks
        if (m === undefined) {
            // this IS reachable
            console.log("arr does not contain key `[3]`");
        }
    }

The alternative would be forcing all array and record accesses to have type `whatever | undefined`, despite the fact that almost all such accesses are clearly in bounds.

This is in fact now a part of TypeScript behind a flag since 4.1: https://devblogs.microsoft.com/typescript/announcing-typescr...

Adding a compile-time bounds-checker to TypeScript to find cases where the `| undefined` is unnecessary would definitely be helpful and interesting, but would do nothing to help TypeScript's reputation of being difficult to wield and slow to compile.

It's also not an easy problem to solve, due to the semantics of JavaScript arrays:

    let a = [];
    a[5] = "five";
    console.log(a.length); // 6
    console.log(a[4]); // undefined (!)

you're right about the dictionary lookup possibly being undefined (and the compiler flag there). Some people (including me) would really appreciate a `--hindley-milner-type-inference` compiler flag.

That example looks like a strawman to me. In practice, x would probably originate from outside the function, as a parameter or class member, and there is a good chance it could hold the value null or undefined. Seems like way too much additional work with little to no benefit to make the compiler track things like that through the whole application. Worse, the variable state could intentionally be hardcoded to try things and it would be weird if the compiler would error because the variable is never set to undefined, when I might be hardcoding it to undefined later on.