2024 年即将到来，正如长期 Rust 爱好者所知，这意味着一个新的 Rust 版本即将发布！
什么是版本？
您可能知道，Rust 每六周发布一个新的版本。语言的新版本既可以添加内容，也可以更改内容，但根据 Rust 的1.0 稳定性保证，只能以向后兼容的方式进行。
但这是否意味着 Rust 永远不能进行向后不兼容的更改？并非完全如此！这就是版本的作用：Rust 用于以向后兼容的方式引入向后不兼容更改的机制。如果这听起来像矛盾，那么版本有三个关键属性来维护稳定性保证
-
版本是可选的；只有当其作者明确要求时，箱子才会收到重大更改。
-
使用旧版本的箱子永远不会被抛弃；为原始 Rust 2015 版本编写的箱子仍然受每个 Rust 版本的支持，并且仍然可以使用每个新版本附带的所有新功能，例如新的库 API、编译器优化等。
-
版本永远不会拆分库生态系统；使用新版本的箱子可以依赖于使用旧版本的箱子（反之亦然！），因此没有人需要担心版本相关的兼容性问题。
为了将变化降至最低，Rust 的新版本每三年发布一次。我们已经有了2015 版本、2018 版本、2021 版本，以及即将发布的 2024 版本。我们希望得到您的帮助！
Rust 2024 版本提案征集
我们知道您非常喜欢 Rust，但说实话，没有哪种语言是完美的，Rust 也不例外。因此，如果您有想法，如果那个讨厌的稳定性保证不存在，Rust 会变得更好，现在是分享的时候了！还要注意，潜在的版本相关更改不仅限于语言本身：我们还将考虑对 Cargo 和 rustfmt 的更改。
请记住，以下标准决定了我们正在寻找的更改类型
- 更改必须可以在不违反上一节中列出的严格属性的情况下实现。具体来说，箱子能够进行跨版本依赖关系，这限制了跨箱子边界生效的更改，例如公共 API 的签名。但是，我们偶尔会发现，版本相关的更改曾经被认为是不可能的，实际上是可行的，因此，如果您不确定您的想法是否符合此标准，不要灰心；为了安全起见，请提出您的想法！
-
我们努力确保几乎所有版本相关的更改都可以自动应用于现有代码库（通过像
cargo fix这样的工具），以便尽可能轻松地升级到新版本。 -
即使版本可以进行任何给定的更改，但这并不意味着它应该进行。我们不希望进行大规模的侵入性更改，或者会从根本上改变语言特性的更改。请将您的提案重点放在以下方面，例如修复明显的错误、更改令人讨厌的行为、解除未来功能开发的阻碍，以及使语言更易于使用和更一致。
为了激发您的想象力，这里有一个现实世界的例子。在 2015 和 2018 版本中，通过[foo].into_iter()迭代固定长度数组将产生对迭代元素的引用；这令人惊讶，因为在其他类型上，调用.into_iter()会产生一个迭代器它产生的是拥有值而不是引用。这种限制存在的原因是，旧版本的 Rust 缺乏以通用方式为所有可能的固定长度数组实现特性的能力。一旦 Rust 最终能够表达这一点，所有版本最终都获得了在固定长度数组中迭代拥有值的能力；但是，在[foo].into_iter()的特定情况下，更改现有行为会导致大量代码在野外崩溃。因此，我们使用 2021 版本来修复[foo].into_iter()特定情况下的这种不一致，使我们能够解决这个长期存在的问题，同时保留 Rust 的稳定性保证。
如何贡献
与 Rust 的其他更改一样，版本相关的提案遵循 RFC 流程，如Rust RFC 存储库中所述。请遵循其中记录的流程，并请考虑发布您的 RFC 草案以收集初步反馈，然后再正式提交，以便在您真正提交后加快 RFC 流程！（除了之前链接中提到的场所之外，请随时将您的预 RFC 公布到我们的 Zulip 频道。）
请尽快提交您的 RFC！我们的目标是在 2024 年下半年发布 2024 版本，这意味着我们希望在 5 月底之前完成所有实现（不仅是功能本身，还有所有版本相关的迁移工具），这意味着 RFC 应该在 2 月底之前被接受。由于 RFC 需要时间来讨论和考虑，我们强烈建议您在 12 月底之前或最迟在 1 月初提交您的 RFC。
我们希望定期更新 2024 版本的开发进展。同时，如果您有任何问题，或者您想帮助我们实现新版本，我们邀请您加入Rust Zulip 中的#edition频道进行聊天。