讨论为 JavaScript 设计类型系统的难点与渐进式类型取舍

我会说这比那要更棘手一些。

我们很可能还没有一个能精确表达所有 JavaScript 惯用法的类型系统。Elixir 在很多方面都没有 JavaScript 那么复杂,而我们仍然不得不为其类型系统开发大量新理论!

所以当你遇到一个不受支持的惯用法时,作为类型系统开发者,你的选项有:

1. 开发新理论并证明其正确性(我怀疑如今的模型能否自主做到这一点)

2. 拒绝该惯用法,牺牲兼容性(这会让采用变得更困难)

3. 作为渐进式类型系统,回退到动态类型

选项 3 又会带来它自身的取舍,因为动态代码必须与静态代码交互(不受支持的惯用法越多,动态部分就越多!)。所以你需要在以下之间做选择:

a. 从动态代码调用静态代码时返回 dynamic(),放弃进一步静态类型检查的机会(这是可靠的)

b. 从动态代码调用静态代码时返回静态类型,可能在运行时导致类型不匹配(这是不可靠的)

c. 从动态代码调用静态代码时返回静态类型并附加运行时检查,统一两种行为但可能影响性能(这是可靠的)

d. 使用我们为 Elixir 开发的 strong arrows 理论(https://t.co/jGDJGeokQ4),但对于像 JS 这样高度多态的语言,它可能不太适用

另一方面,据我理解,TypeScript 做出了刻意的取舍,尤其是在开发者体验方面,而一个新的类型系统当然可以探索与当前趋势相符的不同选择。

PS:我并非科班出身的类型理论学者,尽管我实现过一个在大规模使用的类型系统。以上内容可能包含不准确之处!