Rustfmt 对 let-else 语句的支持

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

Rustfmt 将从 2023-07-02 nightly 工具链开始添加对格式化 let-else 语句 的支持，然后 let-else 格式化支持应该作为 1.72 版本的一部分进入稳定 Rust。

概述

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

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

对 let-else 语句的 Rustfmt 支持是一个长期以来的请求，项目采取了许多步骤来防止功能稳定化和格式化支持之间再次出现延迟，并制定了额外的程序，以使对仅限 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。