Generics in union should be inferred as `never` when possible

[zeng-y-l]

🔎 Search Terms

generics, inference, union, never

🕗 Version & Regression Information

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

⏯ Playground Link

https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAZjAvDAPAFQDQD4AUAPALhjRgB8ZoAnASzAHMMYBPIk8sAVwFsAjAU0oBKJFmYAoODgDkAQymMAjMIgyo1CHGp8IMTrwEwA9IeIx1MAEQyLukAHcxY0JFh0kqEnzxQ+YACY6HP58mmB8friEpuzc-EIiMHhidDhKFKrqmtq6sQbGpuZBfiG04bZ2QA

💻 Code

const f = <T,>(x: T | string, y: T | number) => y
f('a', 1) satisfies number // T is "a" now

const g = <T extends undefined>(x: T | number) => x
g(1) satisfies number // T is undefined now

🙁 Actual behavior

T is not never.

🙂 Expected behavior

T should be inferred as never, because it can be anything.

Additional information about the issue

This may be related to #42491.

[RyanCavanaugh]

This seems potentially quite breaky and I'm not sure that there's a strong intuition out there for whether T | number should be treated as an inference site for T when the expression is a number. Certainly falling back to never when there are zero candidates is going to be quite disruptive in unintentional ways.

You could imagine code like this existing:

function makeChecker<T extends string>(arg: T | number) {
    function f(other: T | number) {
        return arg === other;
    }
    return f;
}
// Current behavior, OK
const p1 = makeChecker(32);
p1("hello");

// Proposed behavior, error
const p2 = makeChecker<never>(32);
p2("hello");

where it's not really clear how you'd get back to the current behavior.

[zeng-y-l]

You're right. It's difficult to decide whether a generic type should be inferred as never or not.