Only the last overload of a function is considered while inferring

[AFatNiBBa]

🔎 Search Terms

overloads parameters union returntype

🕗 Version & Regression Information

I tried v3.3.3333, v5.9.3 and nightly (Currently v6.0.0-dev.20260114), the problem occurred

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=5.9.3#code/LAKALgngDgpgBAewEYCsCMcC8cDecCGAXLnEsRgL5wA+JZcATHFRQNyiiSxwwAesAYzAwAJhmwZaDVnAD0suAAoA8gGsAlJ2jwATjADOAVwA2YcYlRoA2gCJ8NgLq2kj9iHlxPAPQD8HcNoWKEzYeABmigB2xDaRhgC2SDA6NurEcYnJADRwEfox+mA6AJaRAOapxIUl5cxuWtx8gsIiIXAZSTo0cNWlZW5cugYmYG0ASjBghjqRACraADzIwbZhjgB8bh7efiAN8E0wQqIAzFhwVtFwsQmdjt1W+de95a77cHpGpmfYAAr4Onw8UmyX0S1QDFWGy2Ch2-kGPH4RxaABZzh1kt0Xv13p8RmjsMtITY1g5EcJIiJ9EoAHR0gFlJ74SIQKwOdRYdZwUphTEAVTgPjgAvSMAAbskYZ44L4gA

💻 Code

type obj1 = { a: { b: 1 } | { b: 2 } };

type expected1 = 1 | 2; // (Ok)
type result1 = obj1["a"]["b"];
//   ^? type result1 = 1 | 2

type obj2 = { f(n: "number"): number, f(s: "string"): string };

type expected2 = number | string;
type result2 = ReturnType<obj2["f"]>;
//   ^? type result2 = string

type expected3 = [n: "number"] | [s: "string"];
type result3 = Parameters<obj2["f"]>;
//   ^? type result3 = [s: "string"]

type expected4 = number | string;
type result4 = obj2["f"] extends (...args: any[]) => infer U ? U : never;
//   ^? type result4 = string

🙁 Actual behavior

When inferring the parameters or the return type of a callable type with more than one signature, only the last overload is taken into account

🙂 Expected behavior

Every overload should be taken into account, and the inferred value should be the union of all the possible ones

Additional information about the issue

Could be somewhat related to #14107

[MartinJohns]

This is working as intended and mentioned in the documentation.

https://www.typescriptlang.org/docs/handbook/2/conditional-types.html#inferring-within-conditional-types

When inferring from a type with multiple call signatures (such as the type of an overloaded function), inferences are made from the last signature (which, presumably, is the most permissive catch-all case). It is not possible to perform overload resolution based on a list of argument types.

[AFatNiBBa]

Is there any chance of it getting fixed anyway?
Or is it like this because it is actually impossible to fix?

[MartinJohns]

This has been a long known issue and has to do with how overload resolution works. It would definitely require new syntax, just taking a union wouldn't work.

Final word is with the team of course, but I wouldn't get my hopes up for a solution anytime soon (aka next years).

[jcalz]

duplicate of #29732, #56430, #56829, and others.