Control flow analysis should "work" in unreachable code

[RyanCavanaugh]

TypeScript Version: master

Search Terms: unreachable throw return narrowing

Code

function fn() {
    // TODO: Finish writing this function!
    return;

    const h = Math.random() > 0.5 ? 'h' : undefined;

    if (h) {
        // Error, wat
        const a: string = h;
    }
}

Expected behavior: No error

Actual behavior: Error - h is possibly undefined

We get "bug" reports like this every once in a while, and it's hard to understand why the narrowing just stops working because the code isn't reachable. This also makes it difficult to insert debugging throws/returns earlier in the function.

e.g. https://twitter.com/aendrew/status/1037301561062514688

Playground Link: http://www.typescriptlang.org/play/#src=function%20fn()%20%7B%0A%20%20%20%20%2F%2F%20Not%20done%20yet%0A%20%20%20%20return%3B%0A%0A%20%20%20%20const%20h%20%3D%20Math.random()%20%3E%200.5%20%3F%20'h'%20%3A%20undefined%3B%0A%20%20%20%20const%20d%20%3D%20(arg%3A%20string)%20%3D%3E%20arg%3B%0A%0A%20%20%20%20if%20(h)%20%7B%0A%20%20%20%20%20%20%20%20const%20a%20%3D%20d(h)%3B%0A%20%20%20%20%7D%0A%7D%0A

Related Issues: Believe there's one out there somewhere

[RyanCavanaugh]

See also #11821

[atg]

Just encountered this also, trying to disable a loop with a break; at the top.

Couldn't type errors be suppressed in unreachable code? If the code is provably unreachable then all type errors are false positives...

[matt-tingen]

@atg while that is strictly true, having the checks is helpful while debugging. If there is unreachable code, it seems likely that it will either be removed momentarily or that the function is being actively worked on or debugged. In the former case, the behavior of TS is largely inconsequential. However, in the latter case, having TS provide checking as usual can be quite helpful.