rust-lang/rfcs

Rust rfc 现状

rust-lang/rfcs 代码库概览

  • README.md，说明 RFC 的目的是什么，何时需要提交 RFC（何时不需要），RFC 如何编写，如何提交 RFC，RFC 生命周期如何管理
  • style-guide RFC 中代码样式规范
  • text RFC 文档的存储目录

简述

大多数变更，比如 bugfix 、文档，通过 Pull Request 完成

但是某些 “实质性” 的变更，需要通过一些设计过程，让社区达成共识

RFC (request for comments) 流程，旨在为新特性进入语言和标准库提供一致和受控的路径。帮助所有的利益相关方都可以对语言在不断发展的方向上有信心

什么场景触发 RFC 流程

如果您打算对Rust，Cargo，CrateS.IO 或 RFC 过程本身进行“实质性”更改，则需要遵循此过程。基于社区规范的 “实质性” 变更是什么构成的，并根据您提出改变的生态系统的哪个部分而变化，但可能包括以下内容。

  • 任何非 bugfix 的 想进入语言的 语义或语法更改
  • 删除语言功能，包括 “feature-gated”
  • 编译器和库之间的接口，包括LANG项目和内部 的更改
  • 添加到 std

不需要RFC的变更：

  • 重建，重组，重构或以其他方式 “变化形态但不会改变意义” 的变更
  • 添加严格改善客观，数值质量标准（警告移除，加速，更好的跨平台新，并发度，陷阱和错误等）
  • 只对开发人员可见对 rust 用户不可见的变更

提交须知

如下提案可能被快速拒绝

  • 低质量的提案
  • 以前拒绝的 feature 的提案
  • 不适合近期路线图的提案

官方论坛

  • 在官方 Discord 上讨论了讨论我们开发人员讨论论坛的主题
  • 偶尔在开发人员论坛上发布 “pre-RFCs” 。您可以在此仓库中提交问题进行讨论，但这些次数不会被团队积极地查看。

作为经验丰富的规则，接受了从长远的项目开发人员的鼓励反馈，特别是相关子团队的成员是一个很好的迹象表明RFC值得追求。

RFC 流程

  • Fork rfc repo
  • 将 0000-template.md 复制到 text/0000-my-feature.md（其中 “my-feature” 是描述性的）。不要分配RFC号码；这将是PR号码，如果接受RFC，我们将相应地重命名文件。
  • 填写RFC，需要注意细节：没有提出令人信服的动机、对设计的影响缺乏了解、或对缺点或替代方案不诚实的建议性文件往往不受欢迎。
  • 提交一个 PR 请求。作为一个 PR，RFC将从更大的社区收到设计反馈，作者应该准备好修改它作为回应。
  • 该 RFC 的编号将是 PR 的 ID
  • 每个 PR 将添加上最相关的 子团队 的 label
  • 建立共识，整合反馈。获得广泛支持的RFC比那些没有收到任何意见的RFC更有可能取得进展。特别是随时可以联系RFC受让人，以获得确定利益相关者和障碍的帮助。
  • 子团队将在 RFC 尽量在 PR 下中进行讨论，离线讨论的总结将发表到 PR 中
  • RFC很少会一成不变地通过这个过程，特别是当替代方案和缺点被展示出来的时候。你可以对 RFC 进行大大小小的修改，以澄清或改变设计，但要以新 commit 的方式提交到 PR 中，并在 PR 中留下评论，解释你的修改。具体来说，不要在 PR 上可见后再 Squash 或 Rebase 提交。
  • 在某些时候，小组的成员将提出 “最后论期动议” （FCP），以及RFC的处理（合并，关闭或推迟）
    • 当讨论了足够多的权衡，小组能够做出决定时，就会采取这一步骤。这并不要求RFC线的所有参与者达成共识（这通常是不可能的）。然而，支持 RFC 处置的论点需要已经被清楚地表达出来，而且在子团队之外不应该有强烈的反对该立场的共识。分组成员在采取这一步骤时，要运用他们的最佳判断力，而FCP本身也要确保有足够的时间和通知，让利益相关者在过早做出决定的情况下进行反击。
    • 对于讨论时间较长的RFC，在提出FCP动议之前，通常会有一个总结性意见，试图说明讨论的现状和主要的权衡/分歧点。
    • 在真正进入FCP之前，所有的子团队成员必须签字；这往往是许多子团队成员第一次全面深入审查RFC的时刻。
  • 在大多数情况下，FCP期间是平静的，RFC要么被合并，要么被关闭。然而，有时会有大量新的论点或想法被提出，FCP被取消，RFC又回到发展模式。

RFC 生命周期

  • 一旦一个RFC变得 “活跃”，那么作者就可以实现它，并将该功能作为 PR 提交到Rust repo。”活跃” 并不是橡皮图章，尤其是并不意味着该功能最终会被合并；它确实意味着原则上所有主要的利益相关者都同意该功能，并且愿意合并它。
  • 此外，一个给定的RFC已经被接受并且是 “活跃的” 这一事实并不意味着它的实现被分配了什么优先级，也不意味着是否有一个Rust开发者被分配了实现该功能的任务。虽然RFC的作者不一定要写实现，但这是迄今为止看到RFC完成的最有效的方式：作者不应该期望其他项目开发者会承担实现他们所接受的功能的责任。
  • 对 “活动” RFC的修改可以在后续的 PR 中进行。我们努力以反映该功能最终设计的方式来编写每一个RFC；但这个过程的性质意味着我们不能期望每一个合并的RFC都能实际反映下一个主要版本时的最终结果。
  • 一般来说，RFC一旦被接受，就不应该进行实质性的修改。只有非常小的改动才应作为修正案提交。更多的实质性修改应该是新的RFC，并在原RFC上添加注释。确切地说，什么是 “非常小的改动” 是由分团队决定的；更多细节请查看分团队的具体指南。

审查 RFC

  • 在 RFC PR 发布的同时，子团队可能会安排与作者 and/or 相关利益相关者的会议，以更详细地讨论问题，在某些情况下，该主题可能会在分小组会议上讨论。不管是哪种情况，会议的摘要都会发布到RFC PR 中。
  • 在充分了解利弊之后，子团队做出最终决定。这些决定可以在任何时候做出，但分团队会定期发布决定。当做出决定后，RFC拉动请求将被合并或关闭。无论哪种情况，如果在线的 PR 讨论区中没有讨论清楚，子团队需要加上评论，并说明决定的理由。

实现 RFC

  • 一些被接受的RFC代表了需要立即实施的重要功能。其他被接受的RFC可以代表一些可以等到一些任意的开发者觉得喜欢做的功能。每一个被接受的RFC都有一个相关的问题，跟踪它在Rust仓库中的实现情况；因此，相关的问题可以通过团队对Rust仓库中所有问题的分流过程分配一个优先级。
  • RFC的作者没有义务去实现它。当然，欢迎RFC作者(像其他开发者一样)在RFC被接受后将其实施情况张贴出来供审查。
  • 如果你对一个 “活跃的” RFC 的实现感兴趣，但又不能确定是否已经有人在做，请随时提出问题（例如，在相关 issue 上留下评论）。

延期 RFC

  • 一些 RFC 拉取请求在关闭时（作为拒绝过程的一部分）会被贴上 “推迟 “标签。用 “postponed” 标签关闭的RFC，是因为我们既不想评估这个提案，也不想在未来的某个时候实现所描述的特性，而且我们相信我们有能力等到那个时候再去做。历史上，”postponed” 是用来推迟到1.0之后的特性。推迟的拉取请求可能会在时机成熟时重新开放。我们没有任何正式的流程，你应该询问相关子团队的成员。
  • 通常，标记为 “推迟” 的RFC拉取请求已经通过了非正式的第一轮评估，即 “我们是否认为我们可能会考虑做出RFC拉取请求中概述的这一改变，或者它的一些半明显的变体”。(当后一个问题的答案是 “不 “时，适当的回应是关闭RFC，而不是推迟它)。

Help this is all too informal

这个过程的目的是为了在目前的情况下尽可能的轻量化。一如既往，我们试图让这个过程由共识和社区规范驱动，而不是强加更多不必要的结构。

Rust rfc 模板

整体结构

  • 头部元信息
  • 摘要
  • 动机
  • 指南级别的解释
  • 参考级别解释
  • 缺点
  • 理由和替代方案
  • 现有技术
  • 未解决的问题
  • 未来的可能性

文件名

0000-feature-name.md

头部元信息

Feature Name: (fill me in with a unique ident, my_awesome_feature)
Start Date: (fill me in with today's date, YYYY-MM-DD)
RFC PR: rust-lang/rfcs#0000
Rust Issue: rust-lang/rust#0000
  • Feature Name: 特性唯一标识（和文件名没有关系）
  • Start Date: 启动时间
  • RFC PR: 当前 PR 的链接，PR 的 id 将作为 RFC 的编号

摘要

我们为什么要这样做？它支持哪些用例？预期的结果是什么？

指南级别的解释

解释该提案，好像它已被包含在语言中，并且您正在向另一个 Rust 程序员传授它。这通常意味着：

  • 引入新的命名概念
  • 主要用例子来解释这个特性
  • 解释 Rust 程序员应该如何思考这个特性，以及它应该如何影响他们使用 Rust 的方式。它应该尽可能具体地解释影响。
  • 如果适用，提供错误信息、废弃警告或迁移指导的示例。
  • 如果适用，描述向现有的 Rust 程序员和新的 Rust 程序员教授这个功能的区别。

对于以实现为导向的RFC（例如，编译器内部），本节应专注于编译贡献者如何考虑变革，并举例说明其具体影响。对于政策RFC，本节应提供对政策的示例驱动的介绍，并在具体方面解释其影响。

参考级别解释

这是RFC的技术部分。以足够的细节解释设计：

  • 该功能与其他功能的相互作用是明确的。
  • 合理地明确了如何实现该功能。
  • 通过示例解剖视角案例。

本节应回到上一节所举的例子，并更充分地解释详细提案如何使这些例子发挥作用。

缺点

存在缺点

理由和替代方案

  • 为什么在可能的设计中，这种设计是最好的？
  • 还考虑过哪些其他设计，不选择这些设计的理由是什么？
  • 不这样做的影响是什么？

现有技术

讨论与本提案有关的现有技术，包括好的和坏的。其中可包括以下几个例子：

  • 对于语言、库、crate、工具和编译器的建议。这个功能在其他编程语言中是否存在？ 他们的社区有什么经验？
  • 对于社区的建议。是否有其他社区做了这个功能，他们有什么经验？
  • 对于其他团队来说。我们可以从其他社区在这里做的事情中学到什么经验？
  • 论文。有没有发表过的论文或者是讨论这个问题的好帖子？如果你有一些相关的论文可以参考，这可以作为一个更详细的理论背景。

本节旨在鼓励您作为作者思考其他语言的经验教训，为您的RFC读者提供更全面的信息。如果没有先例，那也没关系–无论你的想法是全新的，还是从其他语言改编而来，我们都会感兴趣。

请注意，虽然其他语言创造的先例是一些动力，但它本身并不能成为RFC的动力。也请考虑到rust有时会故意偏离通用语言的特性。

未解决的问题

  • 在这个功能被合并之前，你期望通过RFC程序解决设计中的哪些部分？
  • 在稳定化之前，你期望通过这个功能的实现来解决设计中的哪些部分？
  • 您认为哪些相关问题不在本 RFC 的范围内，可以在未来独立于本 RFC 的解决方案解决？

未来的可能性

想一想你的提案的自然延伸和演变会是什么，以及它将如何整体地影响语言和项目。试着把这部分作为一个工具，在你的提案中更全面地考虑所有可能与项目和语言的互动。同时考虑这一切如何与项目和相关子团队的路线图相适应。

这也是一个 “倾倒想法 “的好地方，如果这些想法不在你正在编写的RFC范围内，但在其他方面是相关的。

如果你已经尝试过，但想不出任何未来的可能性，你可以简单地声明你想不出任何东西。

请注意，在未来可能性部分写下一些东西并不是接受当前或未来 RFC 的理由；这样的说明应该在本 RFC 或后续 RFC 的动机或理由部分。这一节只是提供补充信息。

Rust 一个 rfc 的例子

1210-impl-specialization.md

Rust rfc 自描述 rfc

0002-rfc-process.md