自 最初的博客文章 宣布类型团队及其初始目标以来,已经过去了一年多。有关团队是什么、为什么成立或我们之前声明的总体目标的详细信息,请查看该博客文章。简而言之,类型团队的职责范围扩展到 Rust 语言和编译器中涉及类型系统的部分,例如类型检查、特征求解和借用检查。我们的短期和长期目标有效地致力于使类型系统健壮、一致、可扩展和快速。
在深入细节之前,值得分享一个快速要点:该团队在过去一年中非常成功。通常,很难衡量影响,尤其是在长期路线图目标难以量化进度,而各种短期目标要么实现要么没有实现的情况下。但是,有一个清晰的统计数据在一定程度上表明了团队的进展:在过去一年左右的时间里,超过 50 个面向用户的更改 已落地,每个更改都通过 FCP 获得了类型团队的共识。
这些更改位于语言设计和实现的边界,类型团队(它是语言和编译器团队的子团队)的存在意味着 Rust 项目不仅有带宽做出这些决定,而且我们还有足够多的人员拥有类型系统的知识和经验,可以做出明智的决定,从而使语言整体上变得更好。
类型团队的优先事项
为了评估我们过去一年的进展和未来的路线图,让我们从我们的主要优先事项开始,按重要性排序。我们将在本文的其余部分中引用它们。为了实现我们的目标,我们需要一个健康的维护者群体,他们拥有专业知识和能力来应对问题并实施复杂的更改。
类型系统应该是健壮的
Rust 的主要承诺之一是,仅使用安全代码时不会出现未定义的行为。您可能会惊讶地发现,目前 已知的类型系统错误 会破坏这些保证。大多数这些问题是由熟悉编译器内部工作原理的人员通过明确地寻找它们而发现的,我们通常不希望用户意外遇到这些错误。无论如何,我们非常关心修复它们,并努力实现一个完全健壮的,理想情况下经过验证的类型系统。
类型系统应该是始终如一的
类型系统应该易于推理。我们应该尽可能避免粗糙的边缘和特殊情况。我们希望保持实现和面向用户的行为尽可能简单。在可能的情况下,我们希望考虑整体设计,而不是提供本地目标修复。这是建立对类型系统健壮性的信任所必需的,并允许对 Rust 建立更简单的思维模型。
类型系统应该是可扩展的
Rust 仍在不断发展,我们将需要扩展类型系统以在未来启用新的语言功能。这要求类型系统是可扩展且易于理解的。语言的设计不应适应其当前类型系统实现的缺点。我们应该与其他团队和用户合作,确保我们了解他们的问题,并在我们的实现和设计中考虑可能的未来扩展。
类型系统应该是快速的
我们关心 Rust 的编译时间,并希望考虑我们的设计对编译时间的影响。我们应该寻找有效的方法来加快现有实现,例如通过改进缓存或在适用时添加快速路径。我们还应该了解类型系统未来添加对编译时间的影响,并在可能的情况下建议性能更高的解决方案。
更新
我们在过去一年中非常活跃,取得了一些重大进展。我们还有一些非技术性更新要分享。
组织更新
首先,热烈欢迎自公告文章发布以来加入团队的两名新成员:@BoxyUwU 和 @aliemjay。 @BoxyUwU 一直在 const generics 上做了很多工作,并对下一代特征求解器的设计做出了重大贡献。 @aliemjay 一直在对不透明类型(impl Trait
)和借用检查进行一些非常细微的改进。他们都是团队中不可或缺的成员。
我们还在去年 10 月组织了另一个类型团队线下聚会,紧随 EuroRust 之后。我们讨论了团队的现状,查看了当前的实现挑战和正在进行的工作,并审查和更新了 先前聚会的路线图。本文将涵盖其中大部分内容。
最后,正如 RFC 中所讨论的,我们希望领导者定期轮换,主要是为了帮助分担领导者工作的负担和经验。因此,@nikomatsakis 将轮换出去,@lcnr 将加入与 @jackh726 共同领导。
路线图进展和主要里程碑
下一代特征求解器
在 下一代特征求解器 上做了很多工作。该计划在去年年底发布了 单独的更新。虽然我们希望 在几个月前稳定其在一致性中的使用,但这发现了额外的细微行为回归和挂起,导致延迟。我们正在努力解决这些问题,并打算尽快合并稳定化 PR。我们正接近于使用新求解器在所有地方启用标准库和编译器的编译,之后我们将能够运行 crater 来找出剩余的问题。我们预计现有实现的细微问题和行为差异将持续存在,因此这里还有很多工作要做。此外,在稳定新实现之前,我们还必须解决一些开放的设计问题。
impl Trait
Async 和 感谢 @compiler-errors 和 @spastorino 的巨大努力,我们在 1.75 版本中稳定了 async
-fn in traits (AFIT) 和 return-position impl Trait
in traits (RPITIT)。 @cjgillot 极大地改进了生成器(因此是异步函数)在类型系统中的表示方式1。这使我们能够在没有太多额外工作的情况下支持递归 async
函数2。
设计下一代特征求解器发现了我们使用旧特征求解器实现类型别名 impl Trait
(TAIT) 的问题和未来兼容性挑战。我们目前正在重新设计和实现。 @oli-obk 正在带头进行这项工作。这也影响了 RPIT 的边缘情况,迫使我们谨慎行事,避免意外破坏。TAIT 存在一些开放的语言设计问题,因此我们计划稳定关联类型位置 impl Trait
(ATPIT),因为它避免了这些语言设计问题,同时仍然缩小了表达能力差距。
a-mir-formality
我们在过去一年中在 a-mir-formality
上取得了有限的进展,主要是因为我们能够分配给这项工作的时间少于预期。我们已将其用作通向协归纳特征的直观方法的基础,协归纳特征对于许多剩余的健壮性问题是必要的。
修复健壮性问题
我们修复了多个长期存在的类型系统不安全问题,请查看 已关闭问题的完整列表。其中最值得注意的是 #80176。这个微妙的问题导致我们在特质实现中接受了方法,这些方法的函数签名具有特质定义中不存在的生命周期要求。这些要求在调用特质方法时从未被证明。由于有一些箱子意外地依赖于这种模式,即使它们的用法没有利用这种不安全性,我们首先合并了一个 未来兼容性lint,然后在几个版本后将其改为硬错误。
我们还花时间 对剩余的开放问题进行分类,并将它们整合到我们的长期规划中。大多数剩余的问题都阻塞在下一代特质求解器上,因为修复它们依赖于共归纳特质语义和对隐式约束的改进。有一些剩余的问题现在可以至少部分修复,我们打算在前进的过程中解决它们。最后,还有一些问题,我们还没有找到最佳的解决方法,需要进一步考虑。
展望未来
我们在过去一年取得了重大进展,但我们还没有完成!本节涵盖了我们对 2024 年剩余时间的目标。对于每个项目,我们还链接到我们作为 Rust 项目 实验性新路线图流程的一部分提出的项目目标。
-Znext-solver
我们最大的目标是默认情况下在所有地方使用 下一代特质求解器,并完全替换现有的实现。我们目前正在完成 其在一致性检查中的使用的稳定化。这应该已经修复了多个不安全问题,并修复了当前实现中的许多较小问题和不一致。有关更多详细信息,请参阅稳定性报告。
我们还在努力将其实现提取到编译器本身之外的单独库中。我们希望在今年年底之前与 rust-analyzer 共享特质求解器。他们目前使用 chalk,它不再积极维护。在 rust-analyzer 中使用下一代特质求解器应该会为求解器带来更多额外的测试,同时也会通过积极影响性能和正确性来改善 IDE 体验。
我们打算在编译器的其他领域逐步推出求解器,直到我们能够在 2025 年底之前完全删除现有的实现。这种切换本身将修复多个不安全问题,并将解除大量未来工作的阻塞。它通常会清理类型系统中的许多粗糙边缘,例如高阶类型中的关联类型。许多不安全问题只有在我们完全使用新实现后才能修复。
a-mir-formality
我们打算今年更积极地开发 a-mir-formality
,以便将其用于我们的设计过程。使用它来建模类型系统的部分已经产生了难以置信的影响,我们希望在此基础上继续发展。我们正在努力通过启用其对实际 Rust 代码片段的使用以及添加模糊测试支持来更有效地测试 a-mir-formality
。这将使我们能够对类型系统的模型更有信心,并将指导其未来的发展。
我们计划今年完全形式化类型系统的一些组件。一致性相当自包含,非常微妙,并且对健壮性至关重要。这使得我们过去无法对其进行重大改进。我们还打算形式化共归纳特质语义,这些语义难以推理,并且对于修复许多长期存在的健壮性问题是必要的。
语言变更和 polonius
我们打算在今年准备好不透明类型的内部实现,以便稳定 TAIT 和 ATPIT。我们还希望今年在一致性检查中对关联类型的处理进行重大改进。
我们的另一个目标是让 Polonius(下一代借用检查器)在 nightly 上可用,这将使我们能够在 2025 年稳定它,届时我们将有时间进行更多优化和测试。
我们还打算支持其他语言特性的开发,例如 async
-闭包(它是 异步项目目标的一部分)和 dyn
-特质向上转型,希望这些特性能够在不久的将来稳定下来。
路线图
2024 年底
- 下一代特质求解器
- 在一致性检查中稳定
- 由 rust-analyzer 使用
- ATPIT 稳定
- a-mir-formality
- 支持模糊测试和测试 Rust 代码片段
- 完成一致性和共归纳特质语义模型
- 在 nightly 上提供完整的 polonius 实现
2025 年底
- 默认情况下在所有地方使用下一代特质求解器
- TAIT 稳定
- polonius 稳定
2027 年底
- 下一代特质求解器
- 支持
for<'a>
上的共归纳和(隐式)where-约束 - 启用完美派生
- 支持
- a-mir-formality 完全模拟 Rust 中对健壮性至关重要的部分
- 修复所有已知的类型系统不安全性