自 宣布成立类型团队的初始博文 以及我们最初设定的目标发布以来，已经一年多了。有关团队是什么、为什么成立以及我们之前阐述的总体目标的详情，请查看那篇博文。简而言之，类型团队的职责范围涵盖 Rust 语言和编译器中涉及类型系统的部分，例如类型检查、Trait 解析和借用检查。我们的短期和长期目标是使类型系统健全、一致、可扩展且快速。
在深入细节之前，值得快速分享一点：团队在过去一年里非常成功。通常，衡量影响是困难的，特别是当长期路线图目标难以量化进展，而各种短期目标要么达成要么未能达成时。但是，有一个明确的统计数据多少能反映团队的进展：在过去一年左右的时间里，超过50项面向用户的变更 已合并，每一项都通过 FCP 经过类型团队的共识单独批准。
这些变更位于语言设计和实现的边界，类型团队（同时是语言团队和编译器团队的子团队）的存在意味着 Rust 项目不仅有能力做出这些决策，而且我们还有足够了解和经验丰富的类型系统专家来做出明智的决策，从而使语言整体变得更好。
类型团队的优先事项
为了评估我们过去一年的进展以及未来的路线图，让我们先按重要性顺序介绍主要优先事项。在本文的其余部分，我们将引用这些优先事项。为了实现我们的目标，我们需要一个健康的维护者团队，他们拥有专业知识和能力来应对问题并实现复杂的变更。
类型系统应是健全的 (Sound)
Rust 的主要承诺之一是，仅使用安全代码时不会出现未定义行为。您可能会惊讶地发现，目前存在一些 已知类型系统 Bug，它们破坏了这些保证。这些问题大多数是由熟悉编译器内部工作原理的人通过专门寻找发现的，我们通常不期望用户偶然遇到这些 Bug。尽管如此，我们非常关心修复它们，并正在努力构建一个完全健全且理想情况下经过验证的类型系统。
类型系统应是一致的 (Consistent)
类型系统应该易于理解。我们应尽可能避免粗糙的边缘和特殊情况。我们希望尽可能保持实现和用户可见行为的简单性。在可能的情况下，我们希望考虑整体设计，而不是提供局部的针对性修复。这对于建立对类型系统健全性的信任至关重要，并有助于构建更简单的 Rust 心智模型。
类型系统应是可扩展的 (Extensible)
Rust 仍在发展，未来我们将需要扩展类型系统以启用新的语言特性。这要求类型系统具有可扩展性和易于理解性。语言设计不应为了规避当前类型系统实现的不足而进行调整。我们应该与其他团队和用户合作，确保了解他们的问题，并在我们的实现和设计中考虑未来可能的扩展。
类型系统应是快速的 (Fast)
我们关注 Rust 的编译时间，并希望考虑我们的设计对编译时间的影响。我们应寻找有效的方法来加速现有实现，例如改进缓存或在适用时添加快速路径。我们还应注意未来添加到类型系统的特性对编译时间的影响，并在可能的情况下提出更高性能的解决方案。
最新动态
过去一年里，我们非常活跃并取得了一些重大进展。此外，还有一些非技术性的最新动态想与大家分享。
组织动态
首先，热烈欢迎自公布博文以来加入团队的两名新成员：@BoxyUwU 和 @aliemjay。@BoxyUwU 在 const generics 方面做了大量工作，并为下一代 Trait 解析器的设计做出了重要贡献。@aliemjay 在不透明类型（impl Trait）和借用检查方面做出了一些非常精细的改进。他们都是团队宝贵的补充。
我们还在去年十月，紧接着 EuroRust 会议之前，组织了另一次类型团队的线下会面。我们讨论了团队现状，研究了当前的实现挑战和正在进行的工作，并回顾和更新了 上次会面的路线图。本文将涵盖大部分内容。
最后，正如 RFC 中讨论的，我们希望团队负责人定期轮换，主要是为了分担领导工作的负担和经验。因此，@nikomatsakis 将轮换出，@lcnr 将加入并与 @jackh726 一起担任联合负责人。
路线图进展和重要里程碑
下一代 Trait 解析器
下一代 Trait 解析器 方面已经做了 大量工作。该倡议在去年年底发布了 单独的更新。虽然我们原本希望在几个月前 稳定其在一致性检查 (coherence) 中的使用，但这暴露了一些额外的细微行为回归和挂起问题，导致了延迟。我们正在努力修复这些问题，并打算尽快合并稳定化 PR。我们即将能在所有地方都启用新的解析器来编译标准库和编译器，之后我们将能够运行 crater 来找出剩余的问题。我们预计仍会有许多小问题和与现有实现的行为差异，因此还有很多工作要做。在稳定新实现之前，还有一些待解决的开放设计问题。
Async 和 impl Trait
得益于 @compiler-errors 和 @spastorino 的巨大努力，我们在 1.75 版本中稳定了 Trait 中的 async 函数 (AFIT) 和 Trait 中返回位置的 impl Trait (RPITIT)。@cjgillot 大幅改进了生成器（以及因此的 async 函数）在类型系统中的表示方式1。这使我们无需太多额外工作就能够支持递归的 async 函数2。
设计下一代 Trait 解析器揭示了使用旧 Trait 解析器实现的类型别名 impl Trait (TAIT) 的问题和未来兼容性挑战。我们目前正在重塑设计和实现。@oli-obk 正在领导这项工作。这也影响了 RPIT 的边缘情况，迫使我们小心谨慎，避免意外破坏。TAIT 存在一些开放的语言设计问题，因此我们计划稳定关联类型位置的 impl Trait (ATPIT)，因为它避免了这些语言设计问题，同时仍然弥合了表达能力的差距。
a-mir-formality
过去一年，我们在 a-mir-formality 上的进展有限，主要是因为我们能够分配给这项工作的时间比预期的少。我们已将其用作基础，探索针对共归纳（coinductive）Trait 的直观方法，这对于解决许多剩余的不健全问题是必需的。
修复健全性问题
我们修复了多个长期存在的不健全问题，请参阅 已关闭问题的完整列表。其中最值得注意的是 #80176。这个微妙的问题导致我们在 Trait 实现中接受了函数签名具有 Trait 定义中不存在的生命周期要求的 方法。在调用 Trait 方法时，这些要求从未被证明。由于有些 crate 偶然依赖了这种模式，即使它们的用法没有利用这种不健全性，我们还是首先合并了一个 未来兼容性 Lint，并在几个版本后将其升级为硬错误。
我们还花时间 对剩余的开放问题进行了分类，并将其整合到我们的长期规划中。由于它们的修复依赖于共归纳 Trait 语义和对隐含边界（implied bounds）的改进，因此大多数剩余问题都被下一代 Trait 解析器所阻塞。还有一些剩余问题目前至少可以部分修复，我们打算在进行中逐步解决它们。最后，还有一些问题我们尚未找到最佳方法，需要进一步考虑。
未来展望
过去一年我们取得了重大进展，但工作尚未完成！本节介绍我们 2024 年剩余时间的目标。对于每个项目，我们还链接了作为 Rust 项目 实验性新路线图流程 一部分提出的项目目标。
-Znext-solver
我们最大的目标是在所有地方默认使用 下一代 Trait 解析器 并完全取代现有实现。我们目前正在最终确定其 在一致性检查 (coherence checking) 中的使用 的稳定化。这本身就应能修复多个不健全问题，并解决当前实现的许多小问题和不一致之处。更多详情请参阅稳定化报告。
我们还在努力将其实现提取到一个编译器外部的独立库中。我们希望在今年年底前与 rust-analyzer 共享 Trait 解析器。他们目前使用 chalk，该项目已不再积极维护。在 rust-analyzer 中使用下一代 Trait 解析器将为解析器带来大量额外的测试，同时通过积极影响性能和正确性来改善 IDE 体验。
我们计划逐步在编译器的其他领域推广使用此解析器，直到我们能够在 2025 年底前完全移除现有实现。这一切换本身将修复多个不健全问题，并解除对大量未来工作的阻塞。它将普遍清理类型系统的许多粗糙边缘，例如高阶类型中的关联类型。许多不健全问题只能在完全使用新实现后才能修复。
a-mir-formality
我们打算今年更积极地开发 a-mir-formality，以便在我们的设计过程中使用它。使用它来建模类型系统的部分内容已经产生了令人难以置信的影响，我们希望在此基础上继续发展。我们正在努力通过启用其对实际 Rust 代码片段的使用以及增加 Fuzzing 支持来更有效地测试 a-mir-formality。这将使我们对类型系统模型获得更多信心，并指导其未来的开发。
我们计划今年完全形式化类型系统的一些组件。一致性 (Coherence) 相当独立，非常微妙，并且对健全性至关重要。这在过去阻碍了我们对其进行重大改进。我们还打算形式化共归纳 Trait 语义，这很难推断且对于修复许多长期存在的不健全问题是必需的。
语言变更和 Polonius
我们打算今年准备好不透明类型的内部实现，以迎接 TAIT 和 ATPIT 的稳定化。我们也希望今年能在一致性检查中处理关联类型方面取得重大改进。
我们的另一个目标是让 Polonius（下一代借用检查器）在 Nightly 版本中可用，这样一旦有更多时间进行优化和测试，我们就能在 2025 年稳定它。
我们还打算支持其他语言特性的开发，例如作为 async 项目目标 一部分的 async 闭包，以及有望在不久的将来稳定化的 dyn Trait upcasting。
路线图
2024 年底目标
- 下一代 Trait 解析器
- 在一致性检查中稳定
- 被 rust-analyzer 使用
- ATPIT 稳定
- a-mir-formality
- 支持对 Rust 代码片段进行 Fuzzing 和测试
- 完成一致性检查和共归纳 Trait 语义的模型
- Polonius 完整实现在 Nightly 可用
2025 年底目标
- 下一代 Trait 解析器在所有地方默认使用
- TAIT 稳定
- Polonius 稳定
2027 年底目标
- 下一代 Trait 解析器
- 支持共归纳和
for<'a>的（隐含）where 边界 - 启用完美 derive
- 支持共归纳和
- a-mir-formality 完整建模 Rust 的健全性关键部分
- 修复所有已知的类型系统不健全问题