【问题标题】:Why are missing type parameters inferred as unknown in TypeScript?为什么在 TypeScript 中缺少类型参数被推断为未知?
【发布时间】:2020-06-04 04:28:21
【问题描述】:

如果省略,为什么调用中的泛型类型参数会被推断为unknown 类型(或约束类型)。康德,

function doStuff<T>(): T {
  return {} as any as T;
}

const result = doStuff();

我希望doStuff 的调用是一个错误,因为缺少类型参数。相反,它推断unknown,所以result 的类型是unknown。为什么?如果 T 有约束,那么result 的类型就是约束类型。

我可以理解默认值很有用,但 TypeScript 有一个用于泛型参数的默认机制。这是历史性的挂断还是什么想法?

我使用的是 TypeScript 3.9。

这是与this 类似的问题,但我问的是为什么(不是假设它不正确),这个例子更简单。

【问题讨论】:

  • 我不知道如何回答这个问题;这当然是预期的行为,记录在(越来越过时的)TypeScript 规范中。 Here 它说“如果候选参数类型的集合为空,则 T 的推断类型参数是 T 的约束。”我不确定是否有一个规范的答案来解释为什么会这样,所以我不确定如何用除了意见之外的其他东西来回答这个问题。

标签: typescript generics


【解决方案1】:

在(越来越过时的)TypeScript Spec here 中记录了“如果候选参数类型集为空,则 T 的推断类型参数是 T 的约束。”所以这是有意的,但您想知道为什么。我假设您不希望我的意见关于为什么不发出错误可能是有用的行为,所以我能做的最好的事情就是看看 TS 团队是否有任何记录在案的讨论。

次要问题:在 TypeScript 3.5 中,泛型类型参数的隐式约束是 changed from {} to unknown。这只是我能找到的唯一问题的一些背景:

microsoft/TypeScript#360,要求在类型推断产生{} 时发出错误。问题描述主要讨论存在多个非重叠类型推断候选者并且编译器一直扩大到类似顶部的类型以找到“最佳通用超类型”的情况。这不是你的问题,并且这个问题已经在 TypeScript 中通过使用联合并在类型不相关时防止联合推断来解决。

但是在this comment 中,讨论切换到当没有 候选人时该怎么办。应该是错误吗? Aaand,这就是我在那个问题中所能找到的。该问题得到解决,没有在一组空的候选人上出错,并且该建议被关闭为“拒绝”。

还有microsoft/TypeScript#2511 再次要求这个。它在this comment 中作为选项 2 提到:“在推断 {} 时给出错误,因为没有推理候选者。我们之前已经讨论过这个选项,它从未真正获得太多关注,但我们可以重新审视。”也许甚至在now-deleted branch called downWithDreadedCurlyCurly 中完成了一些工作。但是这个问题最终会被关闭,因为一个切向相关的问题修复了部分问题(使用上下文类型从返回类型中添加候选者)。

最后还有microsoft/TypeScript#5254,又问这个,来来回回讨论,没有结果。

所以,就是这样。这是有意的;有些人不久前认为它应该有所不同;这个想法没有得到太多的关注;它被遗弃了。这些都没有真正说明为什么当前的行为是首选的;答案很可能是惯性;它对人们来说效果很好,那些有问题的人可以通过其他方式解决他们的问题。

如果有人能找到更规范的答案,我很想看看。祝你好运!

【讨论】:

    猜你喜欢
    • 2023-03-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-03-06
    • 2023-02-20
    • 1970-01-01
    相关资源
    最近更新 更多