- 开始日期。(给我填上今天的日期，YYY-MM-DD)
- 参考问题。(填写现有的相关问题，如果有的话)
- 实施PR。(留空)
对该功能的简要解释。
如果建议涉及到一个新的或改变了的API，包括一个基本的代码例子。 如果这部分不适用就省略。
我们为什么要这样做？它支持什么用例？预期的结果是什么？ 结果是什么？
请专注于解释动机，这样如果这个RFC不被接受。 可以利用这个动机来开发其他的解决方案。换句话说。 列举你要解决的约束条件，而不要把它们与你心中的解决方案联系得太紧密。 紧密联系到你所考虑的解决方案。
这是RFC的大部分内容。对设计的解释要足够详细，以便让熟悉该实现的人 实现。这应该涉及到具体的细节和角落的情况。 并包括如何使用该功能的例子。任何新的术语都应该 在这里定义。
为什么我们不应该**这样做？请考虑。
- 实施成本，包括代码大小和复杂性
- 建议的功能是否可以在用户空间实现
- 对用户的影响
- 该功能与其他现有和计划中的功能的整合
- 迁移的成本（它是一个破坏性的变化吗？）
选择任何路径都是有代价的。尝试在这里识别它们。
还考虑了哪些其他的设计？不这样做的影响是什么？
如果我们实施这个建议，现有的用户将如何采用它？这是不是 这是一个破坏性的变化吗？我们可以编写一个代码模型吗？我们可以为它所替代的原始API提供一个运行时适配器库吗？
可选的，但建议用于初稿。设计中的哪些部分仍然是 待定？