YaoXiang RFC（请求评议）索引
RFC（Request for Comments）是YaoXiang语言特性设计提案的正式提交格式。
目录
模板
| 文件 | 说明 |
|---|---|
| RFC_TEMPLATE.md | RFC标准模板 |
| EXAMPLE_full_feature_proposal.md | 完整示例（模式匹配增强） |
草案RFC
| 编号 | 标题 | 作者 | 创建日期 | 状态 |
|---|---|---|---|---|
| RFC-002 | RFC-002：基于 libuv 的资源类型 IO 实现层 | 晨煦 | 2026-01-05 | 草案 |
| RFC-019 | RFC-019: 类型级同像性 (Typed Homoiconicity) - 语法即类型 | 晨煦 | 2026-02-20 | 草案 |
| RFC-028 | RFC-028：JIT 编译器 — VM 内多级执行引擎 | 晨煦 | 2026-06-11 | 草案 |
| RFC-031 | RFC-031：优化级别与 Pass 管理器 | 晨煦 | 2026-06-16 | 草案 |
| RFC-033 | RFC-033: ^^ 反射运算符 | 晨煦 | 2026-06-16 | 审核中 |
| RFC-034 | RFC-034: 统一调试工具链 | 晨煦 | 2026-07-06 | 草案 |
| RFC-035 | RFC-035: MCP Server 支持（AI Agent 集成） | 晨煦 | 2026-07-11 | 草案 |
| RFC-027a | RFC-027a: 终止检查的证明函数兜底 | 晨煦 | 2026-09-14 | 草案 |
| RFC-029a | RFC-029a: 模块缓存与增量重编译 | 晨煦 | 2026-09-07 | 草案 |
审核中RFC
| 编号 | 标题 | 作者 | 创建日期 | 状态 |
|---|---|---|---|---|
| RFC-032 | RFC-032: spawn 统一表达式修饰 — 消除 spawn for 特殊情况 | 晨煦 | 2026-06-16 | 审核中 |
已接受RFC
已废弃RFC
| 编号 | 标题 | 作者 | 创建日期 | 状态 |
|---|---|---|---|---|
| RFC-001 | RFC-001：并作模型与错误处理系统 | 晨煦 | 2025-01-05 | 已废弃（被 RFC-024 取代） |
| RFC-020 | RFC-020：动态模块与 FFI 集成 | 晨煦 | 2026-03-14 | 已废弃 |
| RFC-021 | RFC-021: 库驱动 FFI 扩展与跨语言调用支持 | 晨煦 | 2026-03-14 | 已废弃 |
| RFC-022 | RFC 022: 霍尔逻辑静态验证支持（规约注释与规约类型） | 晨煦 | 2026-03-16 | 已废弃（被 RFC-027 取代） |
| RFC-023 | RFC-023: 闭包捕获模型 | 晨煦 | 2026-05-29 | 已废弃 |
已拒绝RFC
| 编号 | 标题 | 作者 | 创建日期 | 状态 |
|---|---|---|---|---|
| RFC-003 | RFC-003：版本规划 | 晨煦 | 2025-01-05 | 已拒绝 |
| RFC-005 | RFC-005: 自动化CVE安全检查系统 | 晨煦 | 2025-01-05 | 已拒绝 |
| RFC-016 | RFC 016: 量子原生支持与多重后端集成 | 晨煦 | 2026-02-13 | 已拒绝 |
| RFC-025 | RFC-025: 可扩展原语类型机制 | 晨煦 | 2026-06-05 | 已拒绝 |
RFC生命周期
草案 → 审核中 → 已接受 → 已废弃（被取代）
↓
已拒绝（不通过）状态说明
| 状态 | 位置 | 说明 |
|---|---|---|
| 草案 | rfc/draft/ | 作者草稿，等待提交审核 |
| 审核中 | rfc/review/ | 开放社区讨论和反馈 |
| 已接受 | rfc/accepted/ | 成为正式设计文档，进入实现阶段 |
| 已废弃 | rfc/deprecated/ | 曾被接受，被新设计取代 |
| 已拒绝 | rfc/rejected/ | 被拒绝的RFC文档 |
文档修订规则
RFC 文档只能包含正确信息。 设计变更时，直接修改原文使其表达当前正确语义； 不得保留错误内容再添加「勘误」块修正。
保留「原文 + 勘误」是最差的写法：读者读到一半才发现前面全作废，前面的阅读成本被浪费，且容易误把已废止的段落当作现行语义引用。勘误块看上去谨慎，实际是把整理成本转嫁给了读者。
正确做法
| 情形 | 做法 |
|---|---|
| 实现与原文不符、原文被推翻 | 直接改写该段落为正确内容，删除原表述 |
| 示例代码不再可运行 | 直接改成可运行的形态，不要保留旧示例 |
| 需要让读者知道「以前是什么样」 | 只在特意做错误对比时保留错误内容，并紧邻标注「此写法是错误的」及原因 |
| 需要追溯设计演变 | 写在 Git 提交信息或 issue 中，不写进 RFC 正文 |
例外
以下的错误信息可以保留：
- 特意做的对比教学：明确标注为正误对照，且错误一侧紧邻解释「为何错」
- 已废弃 RFC（
rfc/deprecated/）：作为历史记录，但应标注被谁取代
辅助手段
- RFC 顶部的
status/updated字段反映最新修订时间，无需在正文写「本次修订了什么」 - 实现状态用表格的 ✅ / ❌ 表达，避免在正文穿插状态叙述
- 完整的修订历史用
git log -- <文件>查看
提交RFC
- 阅读 RFC_TEMPLATE.md 了解格式要求
- 参考 EXAMPLE_full_feature_proposal.md 学习写法
- 创建新文件，命名为
序号-描述性标题.md - 将文件放入
docs/reference/rfc/draft/目录 - 更新本索引文件，添加新RFC条目
- 提交PR进入审核流程
贡献指南
请参阅 CONTRIBUTING.md 了解贡献指南。