False positive for "Unreachable code detected" for code following `switch`/`case` with `allowUnreachableCode: false`

[dgollahon]

🔎 Search Terms

"false positive allowUnreachableCode"
"allowUnreachableCode case statement"
"Unreachable code detected case statement"

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about switch/case

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/C4TwDgpgBAYg9nKBeKAiARgQwE6qgHzSwC9UAoMgYzgDsBnYKAMxuSgAoA3TAGwFcIALlgIAlMJp8AtugjZkAPigBvMlHVQ6AdwCWwSgAsuvAaJVqNlypjrQMOVIIuWXUbBGB9srAIwBuZxdrWyJMUidXV3dPbygAJgDLAF8KS2ivVhtbbGAAOQhOOXZUGjhIAEJUUQCUqloGZho4tmN+IRE4cShJGTlFc0ttPUNW0wHI4LssXAjItI8MqH9AqxspsMcVyPTYhK31ABMIJkw+HmBZufUdzLpsvIKikrKISurAlNrqekYWAGYWtw2sJ4J0JNJZPIkEpVJYdExRtAkMjQrgzLDtgtYstklAIDwQvCOECBMgUfZSOj9m4saw9slAoEblAsnIHoVsMVShUqjUKEw+DRKMAdLQWXc2fkOewpBA7pgAOYQAD8wgY2B0NAVXRoj3kGOABmwcC03QgpoAothjZzZfKlVBlcq0AAVAw6OhQahHKBaGx4gAekGFEAOUGAiFkUEF7kwhkw6B4EAAdLyyLUWMUEGA6Hh-aDRGQWHEs2Vc+KOoX-qWc3nPQWyEA

💻 Code

type Foo = "bar" | "baz"

const fn = (value: Foo): number => {
    switch(value) {
        case "bar":
            return 1;
        case "baz":
            return 2;
    }

    return assertNever("nope!");
}

🙁 Actual behavior

return assertNever("nope!");

is highlighted as "Unreachable code detected". The docs, however, state:

This does not affect errors on the basis of code which appears to be unreachable due to type analysis.

🙂 Expected behavior

No error. This should be the same as the other case form, the if form, and various similar constructs where even though it's allegedly exhaustive, that's just based off of type information (I would like to have a runtime assertion in this case).

Additional information about the issue

Possibly related to: #18882

[RyanCavanaugh]

switch/case gets special treatment here so that you can write an exhaustive return more easily.

You can always write this form instead:

const fn = (value: Foo): number => {
    switch(value) {
        case "bar":
            return 1;
        case "baz":
            return 2;
        default:
            return assertNever("nope!");
    }
}

[dgollahon]

switch/case gets special treatment here so that you can write an exhaustive return more easily.

Can you elaborate on that? In this specific case it was harder for me to write an exhaustive return. I am not sure I understand the "optimization" of sorts?

You can always write this form instead:

I did eventually realize this but I was pretty confused by the error since it contradicts "This does not affect errors on the basis of code which appears to be unreachable due to type analysis.". Before I read the docs this made me think that allowUnreachableCode DOES consider unreachability due to type analysis (which I don't want because I want to be able to add assertions like this).

This seems somewhat clearly like a bug (especially given the explicit documentation) and it confused me when I found an analogous instance in my codebase and prevented me from turning the feature on that I would otherwise use. I don't understand what the constraints are here that causes this to happen so maybe you have more context.

In any case, it's a suboptimal UX, though it is helpful to understand there are workaround(s). If this is something that is potentially easily fixed I would consider trying to send a PR if you have any pointers on where to start.

---

unrelated aside: I really appreciate typescript and think it's one of the few tools I use that I consistently find improvements I like in every major version release. Here is something I sent to my team at work:

typescript 5.4 and typescript 5.5 have a ton of really nice improvements including much better type "narrowing" where if you do something like myarray.filter(foo => foo != = null) it will remove | null from the inferred return type if the elements were sometype | null. you could do this before but you had to specifically annotate a function as narrowing to a type but typescript now automagically infers this for anything and handles closures much better.

i started a draft to upgrade yesterday which is actually quite easy except it uncovered an actual bug in the dashboard. i asked the author to fix it and he said he'd try and get to it today but i think it's kind of cool when you update a tool and there are 0 false positives, a reduction in toil (due to better narrowing) and it finds a bug!

in short, thanks for a great tool!

[RyanCavanaugh]

This is one of those cases where we're going to have an inconsistency somewhere and it's just a question of where to park it, because three things are desired to be true at once but can't all be:

• You should be able to "implicitly return" from a function as long as there's an exhaustive switch in it (see code sample below)
• The rules about "implicitly returning" and "unreachable code" (going past the last statement of the body block) are the same
• default and post-switch statements behave the same

type Foo = "bar" | "baz"

const fn = (value: Foo): number => {
    switch(value) {
        case "bar":
            return 1;
        case "baz":
            return 2;
    }
    // <- no error here, which is quite nice
}

const fn3 = (value: Foo): number => {
    if(value === "bar") {
        return 1;
    } else if (value === "baz") {
        return 2;
    }
    // <- error here, which is actually undesirable!
}

People can and do complain about both of these when they don't work, e.g. #18419 and #21985. I think ideally we'd say fn3 doesn't implicitly return because value gets an observation of never, but this is a difficult thing to analyze and there are many alternate ways to write fn3 that accomplish the same effect. Because switch has much more tractable semantics in terms of analyzing if every possible inhabitant of the switchd expression gets handled, we do handle it "more correctly', obviously to some people's chagrin.

So it's just a matter of whose inconvenience is prioritized here, and given that this behavior goes back approximately 10 years, it doesn't seem like it's the one that should change.