typescript - 为什么无效合并运算符不能作为 typescript 中的打字员工作？

Question

使用 Typescript 3.7 nullish coalescing operator被介绍了。对于像这样的情况，它似乎是完美的类型保护

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 能够使用 soemthing 作为打字机时，我无法改变主意(在下面找到 some examples )

最后两行最让我困惑。在我看来，分配给 x7 和 x8 的两个表达式是完全等效的，但是在分配给 x8 的表达式中，typeguard 可以工作，但对于 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 由于某种原因无法应用类型保护，或者它是否是 typescript 中的一个错误。那么，当 typescript 可以应用打字机时，是否有某种规则手册？或者它可能是一个错误？还是有其他原因我没有编译这些示例？

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

Answer 1

我花了很长时间试图写出为什么像 expr1 || expr2 && expr3 这样的特定表达式的机械解释。在某些情况下而不是在其他情况下充当类型守卫。它最终变成了几页，但仍然没有考虑到您示例中的所有情况。如果你关心你可以查看为 expression operators 实现的代码在 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 :支持连续类型保护，其中一次对多个相关变量执行变窄。它因为太复杂而关闭，因为为了避免指数时间算法，您需要将其硬编码为一些通常不会非常有益的少量检查。语言维护者的建议:使用更多惯用语检查。

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