| 创建日期 | (开始撰写的日期, YYYY-MM-DD) |
|---|---|
| 目标完成版本 | (2.x) |
| 参考问题 | (如果有，填写现有相关问题) |
| 当前状态 | Pending / Active / Landed / Rejected |
| 所有者 | 是谁开启这篇文章的？留下联系方式 |
简单描述你想要解决什么问题？实现什么问题？
如果提案涉及新的或更改的模块，则需要包含基本的代码示例。
如果这部分不适用，请忽略。
我们为什么要这么做？期望是什么？结果是什么？
请重点解释其动机，以便如果该RFC不被接受，这种动机可以用于开发替代解决方案。换句话说，枚举您试图解决的约束条件
这是RFC的大部分内容。解释设计足够的细节，让熟悉 Mog 的人理解，为熟悉的人来实现。这应该涉及到细节和极端情况，并包括如何使用该特性的示例。任何新的术语都应该在这里定义。
为什么我们不应该这样做呢?请考虑:
- 实现成本，包括代码大小和复杂性
- 集成此功能与其他现有和计划的功能
- Mog 其他生态兼容的成本 （是 Breaking Change ？）
选择任何道路都需要权衡。试着在这里辨认他们。
还考虑过其他的设计吗？不这样做的影响是什么？
如果我们实现这个提案，现有的 Mog 开发者将如何使用它？这是一个突破性的变化吗？这将如何影响 Mog 生态系统中的其他项目?
可选，但建议初稿使用。设计的哪些部分仍然待定？