Object union member functions that return never are incorrectly narrowed

[kalkronline]

🔎 Search Terms

"never", "class union", "narrowing unions", "never union"

🕗 Version & Regression Information

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

⏯ Playground Link

Playground Link

💻 Code

class Foo {
    defoo(): never {
        throw new Error("foo error")
    }
}

class Bar {
    defoo() { }
}

type Baz = Foo | Bar;

function defooer(baz: Baz) {
    baz.defoo() 
    // type = void
    // aka (never | void)

    return baz
    // type = Baz
    // should narrow to Bar
}

🙁 Actual behavior

baz doesn't get narrowed after calling .defoo(), even though it's impossible for any value after that point to be Foo. This seems to happen because the type of Baz["defoo"] is equal to Foo["defoo"] | Bar["defoo"] or () => never | void.

🙂 Expected behavior

baz should narrow to Bar after calling .defoo() because the return type of Foo.defoo is never.

Additional information about the issue

No response

[fatcerberus]

But without the catch to know where to pick up the flow, for all we the know the program is terminated anyway.

I think that was the point - the program will terminate if baz is a Foo, but not if it's a Bar, so TS should be able to narrow it to the latter. In fact, with the try-catch there, the function will not terminate (because the exception is caught inside it), and therefore baz could still be a Foo afterwards.

[andrewbranch]

Possibly related to #49771, but not sure that fully covers the use case here

[fatcerberus]

never has a very well-defined type theoretical meaning - it’s the bottom type. It is by definition an empty set, which means any code which claims to have a value of this type is unreachable. If it is not, you are dealing with an unsoundness.

A function which claims to return never is saying that it won’t ever return normally, because, by the definition of never, there’s no way it can.

I think maybe a throws [type] is needed as an available return type

That would be typed/checked exceptions which is #56365 (Ryan needs to update the description there, methinks).

[craigphicks]

@fatcerberus

Does flow need to track the try blocks or not?
In the case a return type throws [optional type], it is obvious that is does.
If it doesn't, lets not place that burden on the TypeScript flow processing.

E.g., a return type of never could mean "program terminated" or "this case won't happen, so it won't even throw". No need for the flow processing to track an exception in those cases. The latter could the return type of one of a set of overloads, for example.

[kalkronline]

@craigphicks

Narrowing in try blocks is applied only if the catch block terminates, this is how it works now:

// returns number | undefined
function destring(value: string | number) {
    try {
        if (typeof value == 'string') {
            throw new Error("string_error");
        }
        // value: number
    } catch {
        // value: string | number
        return undefined;
    }

    // value: number
    return value
}

It would work the same way here, whether an exception was thrown or not wouldn't matter.

// returns Bar | undefined
function try_defoo(baz: Baz) {
    try {
        baz.defoo();
        // baz: Bar
    } catch (e) {
        // baz: Baz
        return undefined;
    }

    // baz: Bar
    return baz;
}

[craigphicks]

Reflecting the never/throws return type back onto the flow of the base object is definitely a good idea.