Rust 成立规范团队，推动官方语言规范制定

Rust 团队在几个月前接受了 RFC 3355 的提议，决定开始制定 Rust 语言的官方规范。由 Eric（Rust Reference 的维护者）、Felix（Rust 语言团队）、Joel（Rust 基金会）和 Mara（RFC 的作者）来共同推动这项工作的进行。

截至今日，Eric 四人代表规范团队发文介绍了这项工作的最新进展，以及后续的一些其他规划。

Editor

第一步是填补 RFC 中规定的“editor”角色。规范的协调和编辑职责被特意委托给 Rust 基金会，以确保工作的连续性。

由于没有面试到合适的人选，基金会选择考虑内部选择作为替代方案。作为其现有工作的一部分，该基金会的技术总监 Joel 表示愿意担任该职位的候选人。Eric、Felix 和 Mara 等也同意了这一提议，“因为他在行业标准和技术编辑方面拥有丰富的经验，并且与 Rust 项目关系密切”。

规范团队（Specification Team）

由于相关工作不可能只由 editor 单人完成，因此还在围绕规范工作组建一个团队，即规范团队（Specification Team），作为语言团队的一个子团队。

最初成员包括：

• Felix Klock (team lead)
• Mara Bos (team lead)
• Joel Marcey (team member, editor)
• Eric Huss (team member)

利益相关者（Stakeholders）

将挑选并维护一份利益相关者名单，他们将担任顾问和审阅者。最初名单包括：

• Rust 语言团队全体成员
• 来自 types team 的一名或多名代表
• operational semantics team 的一名或多名代表
• 来自 Ferrocene 的一名或多名代表（高可靠性/可用性，例如汽车行业。）
• Formal Methods Research and Development 的一名或多名代表
• Operating System Development的一名或多名代表 (Rust for Linux; Microsoft)

Authority and Approval

虽然规范团队负责撰写和编辑规范，但 Rust 语言的定义权仍属于相关团队，如语 language team 和 library API team。这些团队应在必要时让其他团队/子团队参与进来，例如提出问题、提名问题进行​​讨论以及请求 FCP 批准关键决策。

为了让规范团队能够在不受审批流程限制的情况下生成内容并进行迭代，我们将在工作存储库中制定规范草案。在一些工具的帮助下，我们将公开跟踪哪些项目仍需要团队批准，以及哪些项目受到利益相关者的公开关注。

我们将所有变更分类为次要变更或重大变更。较小的更改是对规范团队来说似乎没有争议或微不足道的项目。例如，语言团队已经通过 FCP 批准的更改、排版和语法修复、初衷明确的澄清，以及类似的令人兴奋的更改。重大变更是那些可能有问题、重要或有争议的变更。规范团队和相关权威团队的任何成员以及任何规范利益相关者都可以将更改标记为重大更改。对规范的重大更改必须经过通常的批准流程（例如语言 FCP）才能出现在规范的已发布（非草案）版本中。

语言和规范团队应努力拥有至少一名共同成员（例如 Felix）充当联络人，以帮助确保我们对次要变更与重大变更的理解保持同步。

目标

规范团队的目标是创建和维护 Rust 规范。Rust 规范的目的是提供权威资源来确定哪些源文本是有效的 Rust 程序以及此类程序的行为方式。

一个理想的规范既要：

• 为当前和未来的 Rust 版本定义给定 Rust 程序的语义的规范边界
• 提供与该规范实例相关的 Rust 版本特有的语义描述细节。

特定于版本的详细信息的规定可以直接在规范中提供，也可以通过委托给相关 Rust 团队拥有的其他文档来间接提供。

渐进式开发

既要为当前和未来的 Rust 版本提供规范性约束，又要描述当前 Rust 版本的细节。因此该团队决定将通过迭代和渐进的方式最大限度地提高其工作价值。

我们预计该规范的早期版本将重点关注提供当前 Rust 版本的详细描述。这样的规范可以从现有的工作成果（如 Ferrocene 规范）中衍生出来，因为该规范明确侧重于提供特定 Rust 版本的详细说明。对这些特定版本描述的反馈意见将帮助我们了解如何以最佳方式在规范中制定规范性约束。

由于我们前面提到的对当前 Rust 版本的关注，规范的早期版本可能会有一些空白，其中规定的界限比必要的更加不精确。例如，规定“不安全的 Rust 代码可能会导致未定义的行为”没有提供有关如何编写定义良好的不安全代码的指导。即使存在这种不精确性，规定的界限仍然可以提供有用的高级保证（例如“安全的 Rust 不会导致未定义的行为”）。规范的未来版本会添加更多说明性细节（例如“不安全的 Rust 代码在以下条件下不会导致未定义的行为：……”），直到我们达到所需的精度级别。

范围

规范应至少涵盖 Rust 语法和语义的以下领域某些部分可能与特定后端或目标实现技术（如 inline asm）有内在联系。

• Rust 的语法，通过 Backus-Naur Form (BNF) 或 BNF 的一些合理扩展来指定。
• Macro expansion
  • Macro-by-example (macro_rules) transcription; Hygiene
  • cfg 属性
  • Procedural macros; attributes 以及 derive
• 路径和标识符解析
  • Modules
• 静态语义
  • 类型定义；类型表达式；布局
  • 类型推断和类型检查；子类型化
  • 生命周期和借用检查
• 泛型；关联项解析和 Trait solving
• 安全 Rust 的操作语义
  • 绑定表格；匹配表达式；drop glue
  • 值的移动和复制；借用
  • field projection; method dispatch
    • operator overloading
• 不安全 Rust 的操作语义
  • memory model
  • inline assembly
• Const evaluation
• Crates 和 crate linkage

此列表可随着时间的推移而扩展。

Presentation

Rust 规范将是一个可公开访问的文档，类似于所有其他 Rust 文档（并具有相同的许可条款）。文本将以英语编写，并且仅使用规范本身定义的技术术语或在免费在线词典中具有明确定义的技术术语。

规范中的各个项目都可以被引用和命名：不仅可以在超链接中，而且在文本中（例如“[syntax.patterns.arm.5]”）。在可能的情况下，这些名称/项目引用应在不同版本的规范中持续存在。

规范的迭代应包括突出显示版本之间差异的 renderings。（参见 Ada 参考手册等。）

Rust 规范将以鼓励志愿者贡献的格式进行维护，即使规范团队预计必须对每个贡献进行重新授权，以保持规范的一致性。

虽然完整性和正确性是首要任务，但团队将尽力使规范尽可能易于理解。理想情况下，任何 Rust 程序员都应该能够深入研究并找到他们可能遇到的任何语言问题的答案，而无需询问已经非常熟悉该文档的“language lawyer”。

发布节奏

Rust 发布将独立于规范审批流程进行。

如果给定版本的规范尚未获得批准，则该版本将在没有相关规范的情况下发布。（不过，该团队可能会在后续提供与给定版本相关的规范。）

这是设计使然。规范工作不得为项目增加需要克服的新障碍，以履行其现有义务，例如 6 周的发布周期。

团队愿景是最终能够达到自动交付更新规范的程度，并且能够按照项目的 6 周发布节奏完成。但是，从短期和中期来看，其希望能够自由地滞后于 6 周的发布节奏。当规范团队为以前未涉及的领域逐步添加新内容，或大幅缩小当前版本规范的规定范围时，滞后于 Rust 发布计划的能力可能会特别有用。

虽然规范开发过程不会阻止发布，但语言功能的更改应与规范的相关更新相结合。一旦开始发布与特定版本相关的规范，那么如果没有规范团队批准对当前草案规范的相应拉取请求，则对当前规范中记录的语言功能的更改就无法稳定。规范中未记录的语言功能的更改可以在不更新规范的情况下稳定下来，但需要规范团队成员确认相应的功能未记录。

通过强制执行新功能在稳定之前必须成为规范的一部分的规则，有望消除规范与 Rust 版本之间潜在滞后的主要根源。

下一步

• 为团队制定定期会议时间表。
• 确定利益相关者名单。
• 制作第一个“demo product”，供利益相关者审查。