Rust 领导层成立了一个规范团队，迄今为止在没有规范的情况下蓬勃发展的编程语言 Rust 终于有了规范的关键一步。
这是对去年 6 月 RFC（征求意见）的落实，该 RFC 提出了 rust 是否想要一个规范的讨论。
新团队有四名成员，Joel Marcey 是编辑，Felix Klock 和 Maras Bos 是团队负责人，Eric Huss 是团队成员。Bos 是最初 RFC 的作者。
根据该团队的最初公告，他们将由利益相关者指导，包括 Rust 语言团队的所有成员，以及其他人，包括操作系统的一名或多名代表，特别是 Linux 和 Windows。
今年 9 月，微软在 Rust 上发布了 Windows 驱动程序开发的早期代码。
规范团队和语言团队之间的关系并不是照搬其它语言的组织架构。
例如，在 C 和 C++ 中，标准委员会定义语言，而实现者构建编译器可能只是规范的部分实现，也可能扩展它。Java 有一个社区进程，它提供了一个官方规范。
不过，Rust 规范团队表示，"Rust 语言定义的权力仍然掌握在相关团队手中，例如语言团队和库 API 团队。这与规范团队的最初目标不谋而合，该团队指出："我们预计规范的早期版本将主要专注于提供当前 Rust 版本的详细描述。
可以说，如果规范团队不负责"Rust 语言的定义"，那么它就不完全是一个通常理解的规范团队，尽管它提供的内容读起来更像是规范而不是文档。
这个问题一直争论不休，一位社区成员问道："如果最终的真相仍然是'无论 rustc 做什么'，那么首先制定规范的意义何在？ 另一位团队成员的回答是"如果 rustc 与规范不同，那就是其中任何一个的错误，需要根据具体情况确定是哪一个。
尽管如此，该团队仍将努力使任何寻找语言问题答案的 Rust 程序员都可以访问该规范。该团队还承认，其最初的工作可能存在差距，但预计这些差距会随着规范的发展而减少。
那么，规范将如何与语言保持同步？
Rust 目前的发布周期为 6 周，这个快速的周期可能会将规范抛在后面。"Rust 版本将独立于规范批准过程进行" 新团队表示，即使这意味着"该版本将在没有相关规范的情况下发布"。不过，当涉及到大到足以称为"语言功能"的变化时，有人试图划清界限。希望最终更新的规范将与发布节奏同步交付。
规范团队的成立是第一步，而 Rust 的完整规范的概念还有一段距离。如果它来了，那仍将是有价值的。有评论说："我相信我的雇主......目前被 C 语言困住了，因为没有我们可以在 Isabelle 中忠实地表示的官方形式规范，拥有一个精确的数学定义将有助于我为我们小组采用 Rust 进行验证工作提供论据。Isabelle 是证明数学公式的工具。
精确性很重要，虽然规范问题不会困扰大多数开发人员，但拥有一个规范文本，将有可能提高语言的价值。