typescript - 在不同类型检查 (tsconfig) 上创建编译器错误

Question

有人可以解释为什么这不会引发错误吗？

interface A {
    id?: number;
}
const a:A = {
    id: 5
};
const testA: boolean = (a === 1); //works, but why?


interface B {
    id: number;
}
const b:B = {
    id: 5
};
const testB: boolean = (b === 1); //compiler error -> expected that also on A

Playground Link

Answer 1

让我们检查一下这种行为:

let foo: { foo?: number } = { foo: 1 };
foo = 1; // error, no common properties
foo === 1; // okay

在 TypeScript 2.4 及以上版本中，赋值失败是因为 foo 的类型是 weak type (所有属性都是可选的，例如 Partial<Something> )与 number 没有相同的属性.根据结构兼容性的正常规则(在 TS2.4 之前)，这个赋值应该成功，因为只要 number没有任何名为 foo 的属性, 没有不兼容...在运行时 (1).foo是 undefined , 和 undefined是您在阅读时期望的事情之一 foo来自 {foo?: number} .但这是一个潜在的错误来源，因此 TS2.4 引入了弱类型检测来捕获它们；也就是说，弱类型不兼容的语言阻止了可分配性。

但是，比较成功，因为弱类型不兼容并不会阻止可比性。这两种类型仍然被认为具有可比性。为什么？好吧，我不确定动机是什么，但我可以看出它至少是故意的。曾经有人插入更新成型 TypeScript spec .我认为他们已经放弃了这样的更新(语言变化太快，他们没有足够的资源来持续研究规范，结果是为了理解当前的语言，你需要继续阅读发行说明、GitHub 问题，甚至源代码)，但我看到其中一个未合并的拉取请求， microsoft/TypeScript#17215 ，提供了有关可比性的详细信息。 Specifically :

whether a type is considered weak has no bearing on whether two types are comparable

所以你去。可比性忽略了类型的弱点，因此您可以比较 {foo?: number}与 number .这是故意的，虽然同样，不知道为什么。

我猜你(或其他人)提交了 microsoft/TypeScript#36602问这个。如果我们想想象改变这一点，这里要问的一个重要问题是:如果我们收紧它，现实世界中的 TypeScript 代码会被破坏。如果它很多，并且大多数损坏都没有捕获合法的错误，那么这种情况发生变化的可能性很小。即使它只是在发现错误方面有所改进，它也可能会降低编译器的性能，以至于不值得。唯一可以确定的方法是让 TS 团队同意考虑针对此更改的拉取请求。我不在那个团队所以🤷‍♂️。

最后，让我们将前面的代码稍作修改，以确保我们了解非重叠弱类型、非重叠非弱类型和重叠弱类型之间的区别:

这是一个非重叠的非弱类型:

let bar: { bar: number } = { bar: 1 };
bar = 1; // error, not assignable
bar === 1; // error, not comparable 

赋值和比较都失败；这些类型在结构上不兼容。这是一个重叠的弱类型:

let baz: { toFixed?(): string } = { toFixed: () => "" };
baz = 1; // okay
baz === 1; // okay

赋值和比较都成功；自 number有一个 toFixed()返回 string 的方法,(好吧， Number 有， number 在访问其成员时被强制转换为 Number)类型 {toFixed?(): string}是重叠的弱类型 number .

好的，希望这有助于理解行为。祝你好运!

Playground link to code