为什么 nullish 合并运算符不能用作打字稿中的类型保护？

Question

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 参数上向您发出警报，例如：

我进一步进行了实验，发现这不仅是一个与空值合并运算符无关的问题，而且当 typescript 能够使用某些东西作为类型保护时和不能够使用某些东西时，我无法改变自己的想法（下面你可以找到一些示例）

最后两行最让我困惑。在我看来，分配给 x7 和 x8 的两个表达式是完全等效的，但是在分配给 x8 的表达式中，类型保护起作用，但对于 x7 表达式中的 typescript 来说似乎不行：

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，什么时候不可以呢？或者这可能是一个错误？或者还有其他原因导致我无法编译这些示例吗？

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

Answer 1

我花了很长时间试图写出机械解释，解释为什么特定的表达式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：支持连续类型保护，其中同时对多个相关变量执行缩小。它的关闭过于复杂，因为为了避免指数时间算法，您需要将其硬编码为一些少量的检查，这通常不会很有用。语言维护者的建议：使用更惯用的检查。

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