YaoXiang（Request for Comments）インデックス
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: spawnモデルとエラーハンドリングシステム | 晨煦 | 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: Hoare論理静的検証サポート（仕様注釈と仕様型） | 晨煦 | 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 を参照してください。