解读 Rust 2021 Edition RFC
作者/编辑：张汉东
目前 Rust 2021 Edition 正在讨论中，RFC 3085 目前已经取代了 RFC 2052 成为新的 RFC。
Edition 在RFC 2052中提出，Rust在2018年发布了第一个 Edition版本。这项工作在许多方面都是成功的，但也带来了一些困难的教训。 RFC 3085 为 2021 Edition 提出了不同的模型。 需要注意的是，目前该 RFC 还未合并。
「2021 Edition 模型」讨论的关键点包括：
Edition用于将语言引入更改，否则可能会破坏现有代码，例如引入新关键字。Edition永远不允许分裂生态系统。 我们只允许不同版本的 crate 进行互操作的更改。Edition以其出现的年份命名（例如，Rust 2015，Rust 2018，Rust 2021）。- 发布新
Edition时，我们还会发布工具以自动执行 crate 的迁移。 可能需要进行一些手动操作，但是这种情况很少见。 - Nightly 工具链提供对即将发布的
Edition的“预览”访问权限，以便我们可以随时进行针对将来Edition的工作。 - 我们维护一个《
Edition迁移指南》，其中提供了有关如何迁移到下一Edition的指南。 - 只要有可能，都应使新功能适用于所有
Edition。
该RFC旨在确立 Edition 的高级用途，并描述RFC对最终用户的感觉。 它有意避免进行详细的策略讨论，这些讨论将由相应的子团队（编译器，lang，开发工具等）来解决。
目标与设计原则
顺序代表优先级
Edition不能分裂生态系统。
最重要的一条规则是：一个Edition中的 crate 可以与其他Edition中编译的 crate 无缝地互操作。不管Edition如何，所有 Rust 代码最终都会在编译器中编译为相同的内部 IR。
Edition迁移应该很方便且尽最大可能自动化完成。
在发布新Edition的同时也会发布一些工具帮助自动升级Edition。并且维护《Edition迁移指南》以便手动迁移之需。
-
由用户来控制何时使用新的
Edition -
Edition注定是要被使用的。目标是看到所有Rust用户都采用新Edition。 -
Rust 应该感觉像是一种语言，而非被
Edition分割为多种“方言”。
Edition向 Rust 引入了向后不兼容的更改，从而又增加了 Rust 开始感觉像具有多种方言的语言的风险。 我们想要避免人们进入 Rust 项目的经历，并对给定的代码含义或可以使用的功能种类感到不确定。 这就是为什么我们更喜欢基于年份的版本（例如Rust 2018，Rust 2021），这些版本将许多更改组合在一起，而不是细粒度的选择加入; 可以简洁地描述基于年份的版本，并确保当您进入代码库时，相对容易地确定可以使用哪些功能。
一些背景
Rust 2018版在 RFC 2052中被描述为一个“集结点”，不仅引入了一些迁移，而且还是许多其他更改（例如更新本书，实现连贯的新API集等）的目标。这在很多方面都很有帮助，但在其他方面却是有害的。 例如，在是否有必要升级到新Edition以使用其功能方面存在一定的困惑（尚不清楚该困惑是否具有除困惑之外的其他负面影响）。 这也是组织本身将所有内容整合在一起的压力。 它与「火车模型」相反，后者旨在确保我们具有“低压力”发布。
相反，2021版故意是“低调”事件，其重点仅在于介绍已进行了一段时间的一些迁移，惯用法lint和其他工作。 我们没有将其与其他无关的更改进行协调。 这并不是说我们永远不应该再发布“集结点”。 但是，目前，我们在工作中并没有一整套协调一致的变化，我们需要将这些变化汇总在一起。
但是，由于此更改，Rust 2018的一项好处可能会丢失。 有一定比例的潜在Rust用户可能对Rust感兴趣，但兴趣不足以跟进每个Edition并跟踪发生了什么变化。 对于这些用户，一篇博客文章列出了Rust 2018以来发生的所有令人振奋的事情，足以说服他们尝试一下Rust。 我们可以通过发布回顾过去几年的回顾来解决这个问题。 但是，我们不必将此回顾与Edition联系在一起，因此，此RFC中未对此进行描述。
小结
通过以上内容，我想你应该对目前官方的 Rust 2021 Edition 工作内容有所了解。目前该 RFC 还在持续且激烈的讨论中，更多内容可以移步该 RFC 的 PR中参看。
在官方的 Edition Guide 文档中，已经增加了 Next Edition 可能发布的功能集合，感兴趣可以自行关注。