4

Typescript 3.7 引入了nullish 合并运算符。对于像这样的情况,它似乎是完美的类型保护

const fs = (s: string) => s
const fn = (n: number) => n

let a: string | null | undefined
let b: number | null | undefined

const x = (a ?? null) && fs(a)
const y = (b ?? null) && fn(b)

但是,如果您将该代码放入typescript playground,它会提醒您传递给 fs / fn 函数的 a 和 b 参数,例如:

'string | 类型的参数  空 |  undefined' 不可分配给参数 fo type 'string' 我进行了进一步的实验,发现这不仅是一个孤立于无效合并运算符的问题,而且当 typescript 能够使用 soemthing 作为 typeguard 时,我无法改变主意(在下面你可以找到一些示例

最后两行最让我困惑。在我看来,分配给 x7 和 x8 的两个表达式都是完全等价的,但是在分配给 x8 的表达式中,类型保护工作,对于 x7 表达式中的打字稿来说似乎并不合适:

const fs = (str: string) => str
const create = (s: string) => s === 's' ? 'string' : s === 'n' ? null : undefined
const a: string | null | undefined = create('s')
const b: string | null | undefined = 's'
let x
if (a !== null && a !== undefined) {
    x = a
} else {
    x = fs(a)
}
const x1 = a !== null && a !== undefined && fs(a)
const x2 = a !== null && a !== void 0 && fs(a)
const x3 = (a ?? null) && fs(a)
const x4 = (b ?? null) && fs(b)
const x5 = a !== null && a !== undefined ? a : fs(a)
const something = a !== null && a !== undefined
const x6 = something ? a : fs(a)
const x7 = something && fs(a)
const x8 = (a !== null && a !== undefined) && fs(a)

我不确定,如果打字稿由于某种原因无法应用类型保护,或者它实际上是打字稿中的错误。那么,当 typescript 可以应用 typeguard 时,是否有规则手册?或者它可能是一个错误?还是有其他原因我没有编译这些示例?

顺便提一句。当使用用户定义的类型保护时,当然可以完美地工作,但最好不必添加一些运行时代码来使类型保护工作。

4

1 回答 1

4

我花了很长时间试图写出机械解释,解释为什么特定的表达式expr1 || expr2 && expr3在某些情况下充当类型保护而不在其他情况下充当类型保护。它最终变成了几页,但仍然没有考虑到您的示例中的所有情况。如果您关心,可以查看microsoft/TypeScript#7140中为表达式运算符实现的代码。


对为什么存在这种限制和类似限制的更高级的解释:当您作为人类看到联合类型的值时,您可以通过想象如果将值缩小到每个成员会发生什么来决定分析它该类型的,对于存在该值的整个范围。如果您的代码在每个此类案例分析中表现良好,那么它在完整联合中表现良好。这个决定可能是基于你对所讨论代码的行为的关心程度,或者我们不能希望编译器重现的其他认知过程。

对于遇到的每个可能的联合类型表达式,编译器可能一直都在进行这种分析我们可以称之为“自动分布式控制流分析”,它的好处是几乎总是产生你想要的类型保护行为。缺点是编译器需要的内存和时间比您愿意花费的更多,并且由于每个额外的联合类型表达式对所需的乘法效应会发生组合爆炸,因此可能比人类能够花费的更多资源。指数时间算法不适合好的编译器。

有时我希望能够向编译器暗示应该以这种方式分析特定范围内的特定联合类型值,我什至提出了这样的“选择加入分布式控制流分析”的请求,(请参阅microsoft/TypeScript#25051),但即使这样也需要大量的开发工作才能实现,并且会偏离启用 JS 设计模式的 TS 设计目标,而无需开发人员过多地考虑控制流分析。

所以最后,TypeScript 语言设计者所做的是实现启发式算法,在有限的范围内执行此类分析,从而启用传统惯用的JavaScript 编码模式。如果(a ?? null) && fs(a)对于语言设计者来说,类似的代码不被认为是惯用和传统的(这部分是主观的,部分取决于检查真实世界代码的语料库),并且如果实现它会导致编译器性能下降,那么我不会不期望语言支持它。

一些例子:

  • TS4.4 更新;以下是在microsoft/TypeScript#44370 microsoft/ TypeScript#12184 中修复的:支持将类型保护的结果“保存”为常量(如您的something示例)以供以后使用。这是一个公开的建议,被标记为“重新审视”,语言架构师发出不祥的声明,即很难以高性能的方式进行。这可能是惯用的,但可能难以有效实施。

  • microsoft/TypeScript#37258:支持连续类型保护,其中一次对多个相关变量执行缩小。它的关闭过于复杂,因为要避免指数时间算法,您需要将其硬编码为少量检查,这通常不会非常有益。语言维护者的建议:使用更多的惯用检查。


所以这是我能得到的最接近权威或官方答案的答案。希望能帮助到你; 祝你好运!

于 2020-04-15T15:51:13.670 回答