这听起来像是 #57089 的重复问题。为什么要打开另一个问题？你可以直接编辑并打开你的另一个问题。 🤷‍♂️
const rab = ab0.foo(); // 实际字符串，期望字符串 | 数字
这仍然对我来说没有意义。你有一个总是返回 string 的函数，另一个总是返回一个 number 的函数。然后你说你们有它们的交集，这意味着返回类型也必须是交集，而不是联合。所以它应该是 string & number 而不是 string | number 。

老实说，我在这里看不到价值。提议的算法在显式编写的重载和由交集形成的重载之间引入了不一致性，并破坏了人们肯定编写的实际代码，其中较早的重载返回比它遮蔽的更具体的类型。我们得到了什么回报？这似乎像是用一个问题换取另一个问题。

MartinJohns

然后你说它们有交集，这意味着返回类型也必须是交集，而不是并集。为什么一定要这样呢？如果它是交集，那么

(()=>string) & (()=>number)

的返回类型将永远不会是交集。这似乎是通过矛盾证明返回类型不是交集。我不明白我们如何为这个特殊情况开一个例外，所以它必须适用于所有情况。

@RyanCavanaugh

提议的算法...破坏了人们编写的实际代码，其中较早的重载返回的类型比它所遮蔽的类型更具体。
例如：

interface A {
    f(x:911):"emergency";    
}
interface B {
    f(x:number):number;    
}
// current
declare const ab: A&B;
ab.f(911);  // "emergency"
declare const ba: B&A;
ba.f(911); // "emergency"

// under proposal
// declare const ab: A&B;
// ab.f(911);  // "emergency" | number
// declare const ba: B&A;
// ba.f(911); // "emergency" | number

说实话，我看不出这里的价值。提议的算法在显式编写的重载和由交集形成的重载之间引入了不一致性，并破坏了人们编写的实际代码，其中较早的重载返回的类型比它所遮蔽的类型更具体。我们得到了什么回报？这似乎像是用一个问题换取另一个问题。
在上面的例子中，提案将返回 "emergency" | number ,它更宽。
而当前的TypeScript对于 A&B 和 B&A 都返回 "emergency" ,但它只适用于 B&A ,因为TypeScript已经将 B&A 视为一个重载，并重新排序了重载的成员，这对复杂重载来说是有代价的 - 在计算时间和复杂性/维护逻辑方面都有代价。
然而，对于独立且无序的重载情况，当前算法选择了一个任意类型，这个类型必须太窄。太窄的类型比太宽的问题要严重得多。

为什么必须这样？
因为这是唯一合乎逻辑的做法。联合类型没有意义且不安全。(()=>string) & (()=>number) 可以分配给 (()=>string) ,因此调用者会期望一个 string 。它也可以分配给 (()=>number) ,因此调用者会期望一个 number 。在某些情况下返回一个 string ,在其他情况下当每个相应类型都说它总是一个 number (即联合类型)时，返回一个 string 或 number 是错误的。
是的，逻辑结果是返回类型最终变为 never ,因为 (()=>string) & (()=>number) 是一种无法在 JavaScript 中实现的类型。你不能有一个函数同时返回一个 string 和一个 number ,但这就是这种类型所说的。

@MartinJohns - 一个 & 函数表示一组重载序列的成员，但不表示它们的顺序，因此包括所有可能的顺序。无论选择哪种重载顺序，但在调用点(如果有多个匹配项，则为一个或多个)将匹配一个(或多个)重载函数，该重载函数的返回类型将作为输出。

interface Y<T> {
  g(f:()=>T):void
};
declare const yy:Y<string> | Y<number>;
yy.g; // (method) Y<T>.g(f: (() => string) & (() => number)): void

在这里，参数 f 到 g 必须是一个重载函数。f 的返回类型将是 string 或 number,具体取决于未知的重载顺序，因此类型必须是 string|number。

当然，这是一个非常奇怪的边缘情况，因为两个重载顺序都有不合理的阴影，所以它永远不会被实现为重载函数，而是作为单个函数。如果算法能处理这样的边缘情况，那么在使用这个建议的情况下就会发生这种情况。

最后，但同样重要的是，在原始帖子 示例1 中，当前的行为不是 never 而是 string。

const rab = ab0.foo(); // actual string, expecting string | number

它是 string,因为当参数 {()=>string;()=>number} 传递给 chooseOverload 时，第一个重载函数被返回。

以下是关于当前行为的至少一个证明：

interface A0 {
    foo(): string;
}

interface B0 {
    foo(): number;
}

declare const test2: (A0 & B0) | (B0 & A0);
const r2 = test2.foo();
//       ^? string | number

如果，正如你所Assert的那样，(A0 & B0)["foo"] 和 (B0 & A0)["foo"] 都返回了 never ,那么显然 test2.foo() 必须返回 never ,但它却返回了 string|number 。
我写这篇文章的目的是主张，对于 (A0 & B0)["foo"] 和 (B0 & A0)["foo"] 的每一种情况，都应该返回 string|number ,而它们实际上只分别返回了 string 和 number ,这是由于 TypeScript 目前将 & -intersection 错误地当作一个重载连接操作符。

老实说，我觉得这里没有什么价值。提议的算法在显式编写的重载和由交集形成的重载之间引入了不一致性，并破坏了人们编写的实际代码，其中较早的重载返回的类型比它遮蔽的类型更具体。我们能得到什么回报呢？这似乎像是用一个问题换来另一个问题。
这些已经不一致(#56951),除非交集以特定顺序排列，否则ReturnType将给出错误的结果：
用户本意应该做的是：

• 编写他们的重载
• 最后有一个“通配符”重载，代表函数在重载解析结果不明确时的行为的返回类型应该是所有其他签名返回类型的联合体

除非人们遵循这个规则，否则ReturnType无法以多种方式完成其工作，包括这个。对于像这样完全没有运行时对应物的东西，类型系统对它没有什么有意义的话可说。
我宁愿让交集具有一些与顺序无关的行为，特别是考虑到当前提供的顺序相关行为与函数重载不匹配。

我认为这个提案的写法是不可行的。正确返回类型应该是适用签名的返回类型的交集。
也就是说，type F = ((x:X1)=>Y1) & ((x:X2)=>Y2) 应该被推断为：

• 如果 x 满足 X1 和 X2,则为 Y1 & Y2。
• 如果 x 满足 X1 但不满足 X2,则为 Y1。
• 如果 x 满足 X2 但不满足 X1,则为 Y2。
• 如果 x 满足 X1 | X2,且两者都不是彼此的合适子类型，则为 Y1 | Y2。
• 否则，类型错误。

这意味着您仍然可以指定一个最通用的重载函数，但可以获得更具体重载函数的好处。
示例 1:ab0 和 ba0 都是 never
示例 2:ab1.bar(2) 和 ba1.bar(2) 都是 never
示例 3:rab21 和 rba21 都是 {a:string, b:string}