Rustfmt 将从 nightly 2023-07-02 工具链开始添加对格式化 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 格式化规则。

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 团队，将在以后完成将格式化支持整合在一起所需的工作。

采取的措施

已经采取了许多措施来改善这一领域。这包括解决上述问题并处理多年来在没有风格团队的情况下积累的“风格债务”的措施，以及建立新的流程和机制来实现其他格式化/风格改进。

• 启动了一个新的、永久的风格团队，负责风格指南。
• 建立了一种机制来发展默认风格，同时仍然保持稳定性保证 (RFC 3338)。
• 开发了一个 nightly-syntax-policy，该策略为不稳定/仅限 nightly 的语法提供关于风格规则的清晰度，并使 Rustfmt 能够更早地为这些语法提供支持。

此外，风格团队还在继续努力解决那些“风格债务”项目的积压问题，而 Rustfmt 团队也正在积极进行相应的格式化实现工作。Rustfmt 团队还专注于扩大团队规模，以提高贡献者和审查能力。

结论

我们知道，许多人一直希望得到 let-else 格式化支持，我们很抱歉花了这么长时间。我们也认识到，Rustfmt 现在开始格式化 let-else 语句可能会导致一些格式化混乱，这是我们努力避免的一种非常不希望看到的情况。

但是，我们相信提供 let-else 格式化支持的好处超过了这些缺点。虽然我们可能在处理风格积压问题时，在未来还会有一个或两个类似的情况，但我们希望随着时间的推移，这个新的团队和这些新的流程将通过解决在 let-else 延迟中发挥了过大作用的历史问题，以及带来各种其他改进，来减少（或消除）再次发生这种可能性。

风格团队和 Rustfmt 团队都在 Zulip 上闲逛，所以如果您想了解更多信息或有任何问题，请在 T-Style 和/或 T-Rustfmt 上访问我们。