Code reachability contains False Positive in simple "always true" return condition about typescript HOT 8 CLOSED

Quote from the other issue, emphasis mine:

Background: The control flow graph creator can't resolve the types of expressions (doing so would create a circular dependency between passes of the compiler), but does have some logic for detecting if (true) {. Basically, TS thinks if (value === null) { might not always execute, because during the construction of the control flow graph, it is not yet known that __TRUE__ is true.

That's a pretty fundamental design constraint, and I highly doubt anything has changed in that regard.

Then again, TS can do control flow for asserts T and never returns as long as there's an explicit type annotation on the function, so who knows...

from typescript.

@kungfooman I'm only a passerby so I can't tell. You have to wait for a TS team member to answer it.

from typescript.

The lint rule has a lot of false positives, e.g.

const n = [1, 2];
if (n[4] !== undefined) { // <- thinks this is always true
  
}

from typescript.

Duplicate of #29323.

from typescript.

Thank you @whzx5byb, that issue is from 2019, is it still a design limitation? I want to use some advanced type programming which figures out true/false values and have unreachability detection of it.

from typescript.

Everything is of course in-principle solvable, but there aren't a lot of cases where people intentionally write if (expr) where expr is a complex expression which statically provable to be true (and then need the corresponding code to change color).

from typescript.

@RyanCavanaugh I investigated type checks on ranges a bit through type programming doing arithmetic, e.g. a function could return a random number from 20 to 100. If later there is an condition which checks that this number is bigger than... lets say 200, it can only be false (and ideally be pointed out through dead-code detection).

You already planned range based type flow in another PR and I just wanted to see if it's possible already without any extra PR's. But this issue makes range based type checks not too helpful as-is.

OTOH it seems to already exist, but with an extra linting step: https://typescript-eslint.io/rules/no-unnecessary-condition/

from typescript.

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

from typescript.