原文链接 2024年6月26日 · 由 lcnr 代表类型团队发布
自从第一篇博客文章宣布类型团队及其初始目标以来，已经过去了一年多的时间。关于团队是什么，为什么成立，或我们之前陈述的总体目标的详细信息，请查看那篇博客文章。简而言之，类型团队的职责包括Rust语言和编译器中涉及类型系统的部分，例如类型检查、特性解决和借用检查。我们的短期和长期目标都是为了使类型系统健全、一致、可扩展且快速。
在进入细节之前，值得分享一个快速的要点：过去一年，团队非常成功。通常，衡量影响是困难的，特别是当长期路线图目标难以量化进展，而各种短期目标要么达成要么没有达成时。但有一个明确的统计数据可以某种程度上表明团队的进展：在过去的一年里，有超过50项面向用户的更改已经落地，每一项都是通过FCP单独批准的。
这些变化位于语言设计和实现的边界上，类型团队（它是语言团队和编译器团队的子团队）存在的意义不仅在于Rust项目有能力做出这些决定，还在于我们有足够的人员具备类型系统的知识和经验，能够做出总体上让语言变得更好的明智决策。
类型团队的优先事项
为了评估我们过去一年的进展和未来的路线图，让我们从按重要性排序的主要优先事项开始。在本篇文章的其余部分中，我们将参照它们。为了达到我们的目标，我们需要一个健康的维护者群体，他们有能力和精力应对问题并实施复杂的更改。
类型系统应该是健全的
Rust的一个主要承诺是使用安全代码时不会有未定义行为。您可能会惊讶于目前已知的一些类型系统漏洞打破了这些保证。这些问题大多是由熟悉编译器内部工作的人通过明确寻找发现的，我们通常不期望用户偶然遇到这些错误。尽管如此，我们非常关心修复这些问题，并致力于实现一个完全健全且理想上经过验证的类型系统。
类型系统应该是一致的
类型系统应该易于推理。如果可能，我们应尽量避免粗糙的边缘和特殊情况。我们希望尽可能保持实现和面向用户的行为简单。我们希望考虑整体设计，而不是提供局部的有针对性的修复。这对于建立对类型系统健全性的信任是必要的，并允许Rust拥有更简单的心理模型。
类型系统应该是可扩展的
Rust仍在发展，我们需要扩展类型系统以启用新的语言特性。这要求类型系统是可扩展且易于理解的。语言的设计不应适应其当前类型系统实现的不足。我们应与其他团队和用户合作，确保我们了解他们的问题，并在我们的实现和设计中考虑可能的未来扩展。
类型系统应该是快速的
我们关心Rust的编译时间，并希望在设计中考虑对编译时间的影响。我们应寻找有效的方法来加快现有实现，通过改进缓存或在适用时添加快速路径。我们还应意识到未来对类型系统的添加对编译时间的影响，并在可能的情况下提出更高效的解决方案。
更新
过去一年里我们非常活跃，取得了显著的进展。我们还想分享一些非技术性的更新。
组织更新
首先，热烈欢迎自公告发布以来加入团队的两位新成员：[@BoxyUwU](github.com/boxyuwu)和[@...%25E5%2592%258C%255B%40aliemjay "https://github.com/boxyuwu)%E5%92%8C%5B@aliemjay")](github.com/aliemjay)。[...%25E3%2580%2582%255B%40BoxyUwU "https://github.com/aliemjay)%E3%80%82%5B@BoxyUwU")](github.com/boxyuwu)在常量...%25E5%259C%25A8%25E5%25B8%25B8%25E9%2587%258F%25E6%25B3%259B%25E5%259E%258B%25E6%2596%25B9%25E9%259D%25A2%25E5%2581%259A%25E4%25BA%2586%25E5%25A4%25A7%25E9%2587%258F%25E5%25B7%25A5%25E4%25BD%259C%25EF%25BC%258C%25E5%25B9%25B6%25E5%25AF%25B9%25E4%25B8%258B%25E4%25B8%2580%25E4%25BB%25A3%25E7%2589%25B9%25E6%2580%25A7%25E8%25A7%25A3%25E5%2586%25B3%25E5%2599%25A8%25E7%259A%2584%25E8%25AE%25BE%25E8%25AE%25A1%25E5%2581%259A%25E5%2587%25BA%25E4%25BA%2586%25E9%2587%258D%25E5%25A4%25A7%25E8%25B4%25A1%25E7%258C%25AE%25E3%2580%2582%255B%40aliemjay "https://github.com/boxyuwu)%E5%9C%A8%E5%B8%B8%E9%87%8F%E6%B3%9B%E5%9E%8B%E6%96%B9%E9%9D%A2%E5%81%9A%E4%BA%86%E5%A4%A7%E9%87%8F%E5%B7%A5%E4%BD%9C%EF%BC%8C%E5%B9%B6%E5%AF%B9%E4%B8%8B%E4%B8%80%E4%BB%A3%E7%89%B9%E6%80%A7%E8%A7%A3%E5%86%B3%E5%99%A8%E7%9A%84%E8%AE%BE%E8%AE%A1%E5%81%9A%E5%87%BA%E4%BA%86%E9%87%8D%E5%A4%A7%E8%B4%A1%E7%8C%AE%E3%80%82%5B@aliemjay")](github.com/aliemjay)在不...%25E5%259C%25A8%25E4%25B8%258D%25E9%2580%258F%25E6%2598%258E%25E7%25B1%25BB%25E5%259E%258B%25EF%25BC%2588%2560impl "https://github.com/aliemjay)%E5%9C%A8%E4%B8%8D%E9%80%8F%E6%98%8E%E7%B1%BB%E5%9E%8B%EF%BC%88%60impl") Trait`）和借用检查方面做了一些非常微妙的改进。他们都是团队中无价的成员。
去年十月，在EuroRust之前，我们还组织了另一次类型团队线下聚会。我们讨论了团队的现状，审视了当前的实现挑战和正在进行的工作，并回顾和更新了上次聚会的路线图。大部分内容将在这篇博客文章中讨论。
最后，正如RFC中所讨论的那样，我们希望定期轮换负责人，主要是为了帮助分享负责人的工作负担和经验。因此，@nikomatsakis将轮换出去，@lcnr将加入，与@jackh726共同领导。
路线图进展和主要里程碑
下一代特性解决器
在下一代特性解决器方面做了大量工作。该项目在去年年底发布了单独的更新。虽然我们希望几个月前在一致性检查中稳定其使用，但这暴露出了一些额外的小行为回归和挂起，导致了延迟。我们正在努力修复这些问题，并打算很快合并稳定化PR。我们正在接近编译标准库和编译器，并在启用新解决器后运行crater，以找出剩余的问题。我们预计会有大量的次要问题和现有实现的行为差异，因此还有很多工作要做。在稳定新实现之前，我们还需要解决一些开放的设计问题。
Async 和 impl Trait
我们在1.75版本中稳定了特性中的async-fn（AFIT）和返回位置的impl Trait（RPITIT），这要归功于@compiler-errors和@spastorino的巨大努力。@cjgillot大大改进了生成器（因此也包括async函数）在类型系统中的表示方式1。这使我们能够支持递归async函数，而无需做太多额外工作2。
设计下一代特性解决器暴露了我们使用旧特性解决器的类型别名impl Trait（TAIT）实现的问题和未来兼容性挑战。我们目前正在重新设计和实现。@oli-obk正在领导这一努力。这也影响了RPIT的边缘情况，使我们必须小心避免意外的破坏。TAIT存在一些开放的语言设计问题，因此我们计划稳定关联类型位置的impl Trait（ATPIT），因为它避免了这些语言设计问题，同时仍然填补了表达能力的空白。
a-mir-formality
在过去的一年里，我们在a-mir-formality方面取得了有限的进展，主要是因为我们分配的时间少于预期。我们已将其用作对共归递特性（coinductive traits）的直观方法的基础，这是解决许多剩余不健全问题所必需的。
修复健全性问题
我们修复了多个长期存在的不健全问题，详见已关闭问题的完整列表。其中最显著的是#80176。这个微妙的问题导致我们在特性实现中接受了在特性定义
中不存在的生命周期要求的方法签名。这些要求在调用特性方法时从未得到验证。由于一些库偶然依赖于这种模式，即使它们的用法没有利用这种不健全性，我们首先合并了一个未来兼容性警告，然后在几个版本后将其变为硬性错误。
我们还花时间分类剩余的开放问题并将其纳入我们的长期规划。大多数剩余问题都被下一代特性解决器阻碍，因为修复它们依赖于共归递特性语义和隐含边界的改进。目前有一些问题可以在现在至少部分解决，我们打算在进行时逐步解决。最后，还有一些问题我们尚未找到最佳方法，需要进一步考虑。
展望未来
在过去的一年里我们取得了显著进展，但我们还没有完成！本节涵盖了我们2024年剩余时间的目标。对于每个项目，我们还链接到我们作为Rust项目实验性新路线图过程的一部分提出的项目目标。
-Znext-solver
我们的最大目标是默认在所有地方使用下一代特性解决器并完全替换现有实现。我们目前正在完成其在一致性检查中的稳定化。这应该已经修复了多个不健全问题，并修复了许多现有实现的小问题和不一致。详见稳定化报告。
我们还在努力将其实现提取到编译器之外的单独库中。我们希望在今年年底前与rust-analyzer共享特性解决器。他们目前使用Chalk，后者已不再积极维护。在rust-analyzer中使用下一代特性解决器应该会对解决器进行大量额外测试，同时通过正面影响性能和正确性来改善IDE体验。
我们打算在编译器的其他领域逐步推出解决器，直到2025年底前我们能够完全删除现有实现。这一转换本身将修复多个不健全问题，并将解除大量未来工作的阻碍。它将全面清理类型系统的许多粗糙边缘，例如高阶类型中的关联类型。许多不健全问题只有在我们完全使用新实现后才能修复。
a-mir-formality
我们打算在今年更积极地开发a-mir-formality，以便在我们的设计过程中使用它。使用它来建模类型系统的部分已经产生了非常大的影响，我们希望在此基础上进一步发展。我们正在努力通过启用其对实际Rust代码片段的使用和添加模糊测试支持来更有效地测试a-mir-formality。这将使我们对类型系统模型获得更多信心，并指导其未来发展。
我们计划今年全面形式化类型系统的一些组件。一致性检查是相对独立、非常微妙且健全性至关重要的。这在过去阻碍了我们对其进行重大改进的进展。我们还打算形式化共归递特性语义，这些语义难以推理，并且是解决许多长期存在的健全性问题所必需的。
语言变更和Polonius
关联类型位置impl Trait（ATPIT）项目目标
Nightly上的Polonius项目目标
我们打算在今年内为TAIT和ATPIT的稳定化准备好不透明类型的内部实现。我们还希望在今年改进我们在一致性检查中处理关联类型的方式。
我们的另一个目标是让下一代借用检查器Polonius在Nightly上可用，这将使我们在2025年有时间进行更多优化和测试后稳定它。
我们还打算支持其他语言特性的开发，例如属于异步项目目标的异步闭包，以及希望在不久的将来稳定的动态特性向上转换。
路线图
2024年底前
- 下一代特性解决器
- 在一致性检查中稳定
- 被rust-analyzer使用
- ATPIT稳定化
- a-mir-formality
- 支持模糊测试和Rust代码片段测试
- 完整的共归递特性语义和一致性模型
- Nightly上的完整Polonius实现
2025年底前
- 默认在所有地方使用下一代特性解决器
- TAIT稳定化
- Polonius稳定化
2027年底前
- 下一代特性解决器
- 支持共归递和（隐式）where-bounds on for<'a>
- 启用完美派生（perfect derive）
a-mir-formality全面建模Rust的健全性关键部分- 修复所有已知的类型系统不健全问题