2024 年即将到来，正如 Rust 的资深爱好者所知，这意味着 Rust 的新版本即将到来！
什么是版本？
您可能知道，Rust 的新版本每六周发布一次。新版本的语言既可以添加新功能，也可以更改现有功能，但根据 Rust 的 1.0 稳定性保证，只能以向后兼容的方式进行更改。
但这是否意味着 Rust 永远不能进行向后不兼容的更改？不完全是！这就是“版本”的意义：Rust 以向后兼容的方式引入向后不兼容更改的机制。如果这听起来像是一个矛盾，那么版本有三个关键属性来保证稳定性：
-
版本是可选择加入的；只有当 crate 的作者明确要求时，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 流程！（除了之前链接中提到的渠道外，请随时在 我们的 Zulip 频道中宣布您的 pre-RFC。）
请尽快提交您的 RFC！我们的目标是在 2024 年下半年发布 2024 版本，这意味着我们希望在 5 月底之前完成所有功能的实现（不仅是功能本身，还包括所有与版本相关的迁移工具），这意味着 RFC 应在 2 月底之前被接受。由于 RFC 需要时间讨论和考虑，我们强烈建议您在 12 月底或最迟 1 月的第一周提交您的 RFC。
我们希望定期更新 2024 版本正在进行的开发情况。同时，如果您有任何疑问，或者您想帮助我们实现新版本，我们邀请您在 Rust Zulip 的 #edition 频道中聊天。