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