2023 年 1 月，Rust 官方博客发布了一篇公告，正式宣布 Types Team（类型团队） 的成立。
说"正式宣布"，是因为这个团队其实早在 2022 年 5 月底就已经悄然运作了------只是一直没有对外说过。这次公告，是在团队完成了一次为期三天的线上线下混合会议之后，借着年初的时机，向社区汇报：我们是谁、做了什么、接下来要去哪里。
本文就是基于 Rust 官方博客 2023 年 1 月 20 日发布的《Officially announcing the types team》整理撰写，作者为 Jack Huey，代表 The Types Team。
两个数字，说明问题有多严重
公告开门见山地列出了两个数字，解释为什么需要成立这样一个团队。
220 个：Rust 目前有约 220 个已接受但尚未完整实现的语言、编译器或类型系统特性的追踪 Issue，其中约一半已经存在了至少三年，许多更是积压了更久。这些 Issue 之所以久拖不决，不单是人手不足的问题，更根本的原因是：在 Rust 这样复杂的语言里，想把一个特性的语义和整体语言上下文对齐，本身就极其困难。往往没有人能一眼看出"要把这件事做完，具体该做什么"。
62 个：目前有 62 个未解决的健全性漏洞（unsoundness issues）。听起来很吓人，但公告也做了说明：这些几乎都是在极端边界条件下才会触发的问题，是专门找 bug 的人刻意去戳才能发现的；正常写代码几乎不会踩到。尽管如此，这些漏洞不应该存在，而修复它们一直没有一个明确的归口。
这两个数字共同指向一个结论：Rust 的类型系统需要一个专职团队来系统性地治理。
类型系统到底管哪些东西？
公告把 Types Team 的职责范围划定在三个紧密相关的组件上：
- 类型检查器（Type Checker）：负责确定变量的类型，以及类型之间的关系是否合法；
- Trait 求解器（Trait Solver）：负责回答"类型 T 是否满足某个 trait 约束"这类问题；
- 借用检查器（Borrow Checker）：负责验证 Rust 的所有权模型在任何情况下都成立。
这三者合在一起，就是 Rust 的"类型系统"。它们在实现上深度耦合，往往牵一发而动全身，独立处理任何一个都很难不影响其他两个。
这个边界由 RFC 3254 正式确立，Types Team 对这个范围内的设计和实现拥有完整的决策权。
两个父团队，一项特殊授权
Types Team 在 Rust 的治理结构中有一个独特的位置：它同时拥有两个父团队------语言团队（Lang Team）和编译器团队（Compiler Team），这在 Rust 的团队体系中是独一份的。
这两个父团队分别向 Types Team 做了不同的授权：
- 语言团队授权 Types Team 负责类型系统的设计------不是"这个特性用起来顺不顺手"这类体验层面的事，而是"这个机制在类型系统内部是怎么运作的"这类底层语义的决策；
- 编译器团队授权 Types Team 负责 trait 系统实现层面的定义和维护。
更重要的是一项额外授权：健全性漏洞的修复。过去，修复一个涉及类型系统的健全性 bug，需要同时协调语言团队和编译器团队，流程繁琐。现在，Types Team 在大多数情况下可以独立完成评估和修复，无需两个父团队同步参与。
即便某个修复在技术上会破坏向后兼容性（修复安全漏洞本不在 Rust 的兼容性承诺范围内），类型团队也可以经过内部签字确认，并用 Crater 工具评估对生态系统的影响后，自行推进------而不需要跨团队拉会。这让关闭健全性漏洞这件事变得切实可行。
Chalk 的终结，以及两条新路
Types Team 公告中最让人瞩目的技术决策，是对 Chalk 命运的宣判。
Chalk 是一个从 2015 年就开始开发的实验性 trait 求解器。它的思路是把 Rust trait 系统的语法和语义翻译成一套类似 Prolog 的逻辑规则，用逻辑求解器来处理 trait 查询，然后替换编译器内部的旧求解器。Rust-analyzer 今天仍在使用 Chalk。
但经过多年的开发，团队得出了一个结论：Chalk 很可能不是 Rust 的长期解决方案。原因有两点：
第一，trait 求解器只是整个类型系统的一部分。如果只对这一部分单独建模，就很难把它和类型检查器、借用检查器之间的关系描述清楚；而对整个类型系统统一建模，才能得到完整的图景。
第二，编译器和形式化的需求其实是两件不同的事。编译器需要高性能，还要能追踪足够多的信息来生成有用的错误提示；而一个好的形式化模型，需要的是完整、易读、易维护。Chalk 多年来试图同时满足这两者，结果两者都没有做好。
于是，团队走向了两条并行的新路：
a-mir-formality：这是一个对 Rust 整个类型系统进行形式化描述的项目。它的目标不是直接跑在生产编译器里，而是成为评估新特性设计和健全性漏洞的"参考实现"------在一个干净的模型上验证想法，然后再把结论同步给实际的编译器。项目最初用 PLT Redex 编写，Rust 移植版本正在进行中。
新的内置 Trait 求解器（New In-Tree Trait Solver）：这是一个直接在 rustc 代码树内编写的新 trait 求解器，目标是最终替换掉现有的旧求解器。它的范围比 a-mir-formality 小，设计上会尽可能复用现有编译器的基础设施，以减少迁移代价。为了将来可能被独立拆出，它从一开始就被设计为尽可能模块化。
已经完成的健全性修复
在去年 5 月到公告发布的约七个月内，团队已经落地了一系列健全性修复：
- Rust 1.65 修复了隐含边界（implied bounds）在非规范化类型下的处理，未发现兼容性回归；
- Rust 1.66 修复了不透明类型（opaque type）上不应存在的隐式生命周期约束，未发现兼容性回归；
- Rust 1.68 将引入
IMPLIED_BOUNDS_ENTAILMENTlint，标记一类发现了大量历史代码回归的不健全模式，以"未来兼容性警告"的方式给出过渡期； - 另有若干修复正在推进中，部分因发现兼容性回归而需要额外工作。
这些数字说明了一件事：修复健全性问题并不总是无痛的。有时确实会让旧代码无法编译，即使那些代码从技术上讲本来就不应该通过编译。团队的做法是尽量给出过渡期，并用 Crater 提前评估影响范围。
正在推进的新特性
公告还列出了几个与类型系统深度绑定、类型团队深度参与的特性：
GATs（泛型关联类型）：这是列表里唯一一个已经稳定的特性，于 Rust 1.65 稳定。GATs 早在类型团队成立之前就存在，但稳定化最后阶段的推进工作由团队主导完成。
TAITs（类型别名 impl Trait）：正确实现这个特性需要对类型检查器有深入的理解。公告时点已接近稳定。
Trait 向上转型（Trait Upcasting）：允许把一个 trait 对象向上转型为它的父 trait，改动不大但涉及类型系统交互。
否定 impl（Negative Impls）：允许显式声明某个类型不实现某个 trait。还有若干 bug 和健全性问题未解决，距稳定还有距离。
RPITITs 和 AFITs：分别是"在 trait 方法中返回 impl Trait"和"在 trait 方法中使用 async fn"。这两个特性依赖 GATs 和 TAITs 的基础，目前一起追踪。
分四阶段的路线图
公告给出了一张具体的时间表，把目标切成了四段：
2023 年夏季（6 个月内）
- 新 trait 求解器达到可测试状态；
- a-mir-formality 能够针对 Rust 测试套件运行；
- TAITs 和 RPITITs/AFITs 稳定，或走上稳定路径。
2023 年底
- 新 trait 求解器替换旧求解器的部分功能（不是全部）；
- 新求解器有完整的入门文档；
- a-mir-formality 正式纳入语言设计流程。
2024 年底
- rustc 和 rust-analyzer 共用同一个新 trait 求解器；
- 可扩展的 trait 错误 API 在内部可用；
- Polonius 借用检查器达到可用状态；
- 更高阶 trait 约束中的隐含边界问题得到解决；
impl Trait基本上可以出现在任何应该出现的地方。
2027 年底
- 类型系统相关的健全性问题全部解决；
- 大多数语言扩展变得容易实现，大型扩展变得可行；
- a-mir-formality 通过 Rust 测试套件的 99.9%。
一个团队的成立，意味着什么
这篇公告读下来，有一点很值得注意：Types Team 的成立，首先解决的不是技术问题，而是组织问题。
过去，类型系统相关的决策需要在语言团队和编译器团队之间反复协调。一个健全性 bug 的修复，往往因为归口不清而搁置。一个新特性的推进，往往因为没有明确的负责人而在追踪 Issue 里沉睡。
现在，这些问题有了一个明确的主人。设计、实现、健全性修复------在这个范围内，Types Team 说了算，不需要每次都拉两个团队协调。
这件事的重要性，可能不比任何一个具体的技术突破低。