Calling a function that returns never isn't treated as stopping control flow

[marijnh]

Code

function raise(msg: string): never { throw new Error(msg) }

let x = 1 as (string | number)

if (typeof x != "number") raise("Stop")

console.log(x * 2)

Expected behavior:

I would expect the control flow analysis to treat the console.log as only being reachable if the if branch wasn't taken, which means that x is a number, so the code is accepted. This does happen when you inline the throw.

Actual behavior:

The type of x isn't narrowed and an error is reported for x * 2.

Playground Link: here

[nattthebear]

Duplicate of #16546, more or less.

[marijnh]

Ah, didn't find that. But that one wasn't ever resolved and closed for housekeeping reasons. The return solution mostly works, but is awkward and adds extra typechecking-related cruft to the output JavaScript, so though I'm using it, but am not too happy with it.

Is there a technical reason for the way this currently works?

[jack-williams]

Duplicate of #8655.

Is there a technical reason for the way this currently works?

Read here.

[fatcerberus]

One thing that the above linked comment doesn’t mention is that the control flow graph is constructed before type information is available, so effectively this would require every single function call to be added to it. As you can imagine that would be prohibitively expensive to do.

[jack-williams]

It sorta does, just not in those words.

The control flow graph used to determine which expressions change the type of other expressions is constructed syntactically.

[fatcerberus]

That’s misleading though because if the return type is explicitly annotated then it’s part of the AST (and therefore still syntactical). TS just hasn’t constructed the necessary type information internally for that to matter.

[marijnh]

I, for one, would be perfectly satisfied with this only working for functions explicitly annotated to return never. Would that still run into the control flow graph performance issue you mentioned?

[dragomirtitian]

@marijnh yes it would still have the same performance issues.

At the time the control flow graph is created the compiler does not know the return type of a function, it just sees a call. So you either include all calls in the graph or no calls.

All you can use to decide if a node is to be included is the syntax.

[typescript-bot]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[acutmore]

EDIT: Apparently this happens as otherwise it would make CFA too expensive performance wise.

---

Now that we have #32695 - I wasn't expecting a different between the following two snippets:

function throws(): never {
  throw new Error();
}
throws();
console.log('here'); // ⚠ unreachable code detected

However:

function throws(): never {
  throw new Error();
}
let n: string = throws();
console.log(n); // considered reachable

Is there somewhere that details why this is? ( I understand why 'never' is assignable to 'string', more about why the code is considered reachable). EDIT: It is for performance reasons, to reduce the number of function calls that are also CFA nodes

https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABFAFgJzgdwM4AoCUAXImAKYBupaiA3gFCLLpYmmaICiaGaBA3HQC+dOgBtSUEogC8iAOQoqpOQLoB6NVNmoMOfog2JwEOAFtTpMJIvrNOrHnx8DmuNRt0TYbHHEA6UTgAc1wwfDogA