Rustfmt 对 let-else 语句的支持

2023 年 7 月 1 日 · Caleb Cartwright 代表 风格团队 和 Rustfmt 团队

Rustfmt 将从 nightly 2023-07-02 工具链开始，添加对格式化 let-else 语句的支持，随后 let-else 的格式化支持应该会在 1.72 版本中来到 stable Rust。

概述

let-else 语句早在 2022 年就已作为 1.65.0 版本的一部分稳定化。然而，Rustfmt 的当前和之前版本并未对 let-else 语句提供格式化支持。当 Rustfmt 遇到 let-else 语句时，它会保持原样，保留开发者最初手动编写的样式。

更新到支持 let-else 格式化的工具链之一后，您可能会注意到 cargo fmt/rustfmt 调用想要“改变”let-else 语句的格式。然而，这实际上并非格式化方面的“改变”，而仅仅是 Rustfmt 首次应用let-else 格式化规则。

Rustfmt 对 let-else 语句的支持是一个长期以来的请求，项目组已采取多项措施，以防止特性稳定化与格式化支持之间的延迟再次发生，并制定了额外流程，应能更快地为仅限 nightly 的语法提供格式化支持。

背景与上下文

Rust 有一个官方的风格指南，阐明了 Rust 代码的默认格式化风格。风格指南充当规范，定义了 Rustfmt 的默认格式化行为，而 Rustfmt 的主要任务是基于该风格指南规范提供自动化格式化能力。Rustfmt 是风格指南的直接使用者，但 Rustfmt 并不能单方面决定语言构造的默认格式化风格。

最初的风格指南是多年前（始于 2016 年）开发起来的，由一个风格团队与社区通过 RFC 流程协作完成。随后，风格指南在 2018 年通过RFC 2436正式确定。

用今天的术语来说，最初的风格团队更像是一个项目工作组，因为它有一个固定的范围，主要目标仅仅是汇集最初的风格指南。因此，一旦指南正式确定，该初始风格团队便解散了。

随后，Rust 项目中没有明确负责风格指南的指定小组，也没有明确专注于确定新的语言构造官方风格的小组。

没有拥有风格指南的团队/小组最初并没有引起问题，因为头几年出现的新语法在默认风格和格式化方面争议相对较小。然而，随着时间推移，当社区共识越来越少，且项目内没有管理团队来最终决定新语言语法应如何设计风格时，挑战便开始出现。

let-else 语句无疑就是这种情况，关于它们应如何设计风格存在各种不同的观点。没有团队/小组来做出决定并更新风格指南以包含 let-else 语句的官方规则，Rustfmt 因此受阻，无法继续。

围绕 let-else 语句的这些情况促使整个项目组更加认识到需要建立一个团队来拥有并维护风格指南。然而，大家也很清楚，组建一个新团队和相应的流程需要一些时间，于是决定在新团队和新流程刚起步之时，不阻止那些本已完全准备好稳定化的特性（如 let-else 语句）的稳定化。

因此，let-else 语句在没有格式化支持的情况下被稳定化并发布，并且理解是新风格团队，随后是 Rustfmt 团队，将完成纳入格式化支持所需的必要工作。

已采取的措施

为了改善这方面的情况，已采取了多项措施。这包括解决上述问题，处理在没有风格团队期间多年来累积的一些‘风格债’，以及建立新的流程和机制，以带来其他格式化/样式改进。

此外，风格团队也在继续努力处理那些积压的‘风格债’项，而 Rustfmt 团队正在积极进行相应的格式化实现。Rustfmt 团队还专注于壮大团队，以提高贡献者和评审能力。

结论

我们知道许多人长期以来一直想要 let-else 的格式化支持，对此我们深感抱歉。我们也认识到 Rustfmt 现在开始格式化 let-else 语句可能会引起一些格式化变动，这是我们努力避免的非常不理想的情况。

然而，我们相信提供 let-else 格式化支持的好处大于这些缺点。在我们处理风格积压项时，未来可能还会有一两个类似的情况发生，但我们希望随着时间推移，这个新团队和这些新流程能够解决导致 let-else 延迟如此严重的历史问题，从而减少（或消除）再次发生的可能性，并带来各种其他改进。

风格团队和 Rustfmt 团队都在 Zulip 上，如果您想更深入参与或有任何问题，请访问T-Style和/或T-Rustfmt。