我的问题是基于这个 question and answer

假设我们有下一个代码:

const myFn = <T,>(p: {
  a: (n: number) => T,
  b: (o: T) => void,
}) => {
  // ...
}


myFn({
  a: () => ({ n: 0 }), // Parameter of a is ignored
  b: o => { o.n }, // Works!
})


myFn({
  a: i => ({ n: 0 }), // Parameter i is used
  b: o => { o.n }, // Error at o: Object is of type 'unknown'.ts(2571)
})

我能够修复它。它适用于额外的通用:

const myFn = <T,>(p: {
  a: (n: number) => T,
  b: <U extends T /* EXTRA U generic */>(o: U) => void,
}) => {
  // ...
}

我凭直觉修复了它。我无法解释为什么会出现此错误，更无法解释为什么我的解决方案有帮助:)

我相信答案在协变/协变/不变/双变定义中。

能否请您解释一下为什么会出现此错误以及为什么我的解决方案有效？

谢谢

更新

似乎此行为已在 TypeScript 4.7 中修复/更新

最佳答案

使用术语

Contextual type : 类型，代码位置必须基于它分配给的周围类型。

Context-sensitive function : 带有无类型参数的函数表达式。参数类型派生自上下文类型。

例子

type Fn = (s: string) => number
const fn : Fn = s => s.length 
// `s => s.length` is context-sensitive function
// contextual type of `s` is `string`, obtained from `Fn`

类型推断的工作原理

编译器分两个阶段进行类型推断:

• 首先它会推断出所有非上下文相关的函数。

• 在第二阶段中，类型参数(如 T)的推理结果随后用于推断上下文相关的函数。

如果在阶段 1 中没有推理候选对象用于阶段 2，您可能会遇到类型问题 - 在有问题的情况下，T 获得类型 unknown。

转移到您的案例中

案例一:

myFn({
  a: () => ({ n: 0 }), 
  b: o => { o.n }
})

b 是上下文相关的，a 不是(无参数函数)。因此，在第一阶段我们可以分析a并推断T为{n: number}，然后可用于类型参数o in b 用于第 2 阶段。这里一切正常。

案例二:

myFn({
  a: i => ({ n: 0 }), // Parameter i is used
  b: o => { o.n }, // Error at o: Object is of type 'unknown'.ts(2571)
})

魔鬼来了。 a 和 b 都是上下文相关的，因此我们需要跳过阶段 1 - T 没有推理候选。这两个函数现在在阶段 2 中被独立分析。这是 b 中参数类型的问题，因为我们无法引用 a不再是什么推断类型 T 了。

唯一的方法是从基本约束中推断出 unknown - 更糟糕的是:T 的上下文类型被“固定”，因为第 2 阶段的内部 TypeScript 算法由于某些限制/优化，此时需要对 T 进行具体类型实例化。所以我们不可逆转地陷入 unknown for T。

案例三:

const myFn = <T,>(p: {
  a: (n: number) => T,
  b: <U extends T /* EXTRA U generic */>(o: U) => void,
}) => {
  // ...
}

有效，因为您引入了一个完整的新类型参数 U 并进行了新的推断，独立于 T。这是一个聪明的解决方法，但我还没有测试过这种方法是否有任何缺点。

替代方案

为了通过类型推断解决讨厌的边缘情况，只需确保至少一个带有类型参数的函数是不上下文敏感的，方法是显式键入函数参数。

例如，在a中输入n: number即可:

myFn({
  a: (n: number) => ({ n: 0 }),  // n explicitly typed
  b: o => { o.n }, // works again
})

Playground code

https://stackoverflow.com/questions/65550146/