YaoXiang RFC (Request for Comments) Index
RFC (Request for Comments) is the formal submission format for YaoXiang language feature design proposals.
Contents
Template
| File | Description |
|---|---|
| RFC_TEMPLATE.md | RFC standard template |
| EXAMPLE_full_feature_proposal.md | Complete example (Pattern Matching Enhancement) |
Draft RFCs
| Number | Title | Author | Creation Date | Status |
|---|---|---|---|---|
| RFC-002 | RFC-002: libuv-Based Resource Type IO Implementation Layer | 晨煦 | 2026-01-05 | Draft |
| RFC-019 | RFC-019: Type-Level Homoiconicity - Syntax as Types | 晨煦 | 2026-02-20 | Draft |
| RFC-028 | RFC-028: JIT Compiler — Multi-Level Execution Engine in VM | 晨煦 | 2026-06-11 | Draft |
| RFC-031 | RFC-031: Optimization Levels & Pass Manager | 晨煦 | 2026-06-16 | Draft |
| RFC-033 | RFC-033: ^^ Reflection Operator | 晨煦 | 2026-06-16 | Under Review |
| RFC-034 | RFC-034: Unified Debugging Toolchain | 晨煦 | 2026-07-06 | Draft |
| RFC-035 | RFC-035: MCP Server Support (AI Agent Integration) | 晨煦 | 2026-07-11 | Draft |
| RFC-027a | RFC-027a: Termination Check Proof Function Fallback | 晨煦 | 2026-09-14 | Draft |
| RFC-029a | RFC-029a: Module Cache & Incremental Recompilation | 晨煦 | 2026-09-07 | Draft |
RFCs Under Review
| Number | Title | Author | Creation Date | Status |
|---|---|---|---|---|
| RFC-032 | RFC-032: spawn Unified Expression Modifier — Eliminating spawn for Special Case | 晨煦 | 2026-06-16 | Under Review |
Accepted RFCs
Deprecated RFCs
| Number | Title | Author | Creation Date | Status |
|---|---|---|---|---|
| RFC-001 | RFC-001: spawn Model and Error Handling System | 晨煦 | 2025-01-05 | Deprecated (Replaced by RFC-024) |
| RFC-020 | RFC-020: Dynamic Modules and FFI Integration | 晨煦 | 2026-03-14 | Deprecated |
| RFC-021 | RFC-021: Library-Driven FFI Extension and Cross-Language Call Support | 晨煦 | 2026-03-14 | Deprecated |
| RFC-022 | RFC 022: Hoare Logic Static Verification Support (Specification Annotations and Specification Types) | 晨煦 | 2026-03-16 | Deprecated (Replaced by RFC-027) |
| RFC-023 | RFC-023: Closure Capture Model | 晨煦 | 2026-05-29 | Deprecated |
Rejected RFCs
| Number | Title | Author | Creation Date | Status |
|---|---|---|---|---|
| RFC-003 | RFC-003: Version Planning | 晨煦 | 2025-01-05 | Rejected |
| RFC-005 | RFC-005: Automated CVE Security Scanning System | 晨煦 | 2025-01-05 | Rejected |
| RFC-016 | RFC 016: Quantum-Native Support and Multi-Backend Integration | 晨煦 | 2026-02-13 | Rejected |
| RFC-025 | RFC-025: Extensible Primitive Type Mechanism | 晨煦 | 2026-06-05 | Rejected |
RFC Lifecycle
Draft → Under Review → Accepted → Deprecated (Replaced)
↓
Rejected (Not Approved)Status Description
| Status | Location | Description |
|---|---|---|
| Draft | rfc/draft/ | Author's draft, awaiting submission for review |
| Under Review | rfc/review/ | Open community discussion and feedback |
| Accepted | rfc/accepted/ | Becomes an official design document, entering the implementation phase |
| Deprecated | rfc/deprecated/ | Previously accepted, replaced by a new design |
| Rejected | rfc/rejected/ | Rejected RFC documents |
Document Revision Rules
RFC documents must only contain correct information. When design changes occur, directly modify the original text to express the current correct semantics; Do not retain incorrect content and add an "errata" block to correct it.
Retaining "original text + errata" is the worst approach: readers discover halfway through that everything before is voided, the prior reading effort is wasted, and it becomes easy to mistakenly quote deprecated sections as current semantics. An errata block may seem cautious, but it actually shifts the organizational cost onto the reader.
Correct Approach
| Situation | Approach |
|---|---|
| Implementation does not match the original text, or the original text has been overturned | Directly rewrite the paragraph with correct content, delete the original wording |
| Example code no longer runs | Directly modify it to a runnable form; do not retain the old example |
| Need to let readers know "what it used to be" | Only retain incorrect content when deliberately making an error comparison, and label it directly with "This writing is incorrect" and the reason |
| Need to trace design evolution | Record it in Git commit messages or issues, not in the RFC body |
Exceptions
The following incorrect information may be retained:
- Deliberate contrastive teaching: Clearly marked as a correct/incorrect comparison, with the incorrect side immediately followed by an explanation of "why it is wrong"
- Deprecated RFCs (
rfc/deprecated/): Kept as historical records, but should note which RFC replaced them
Auxiliary Methods
- The
status/updatedfields at the top of the RFC reflect the latest revision time; there is no need to write "what was revised this time" in the body - Use ✅ / ❌ in tables to express implementation status, avoiding status narration interspersed in the body
- View the complete revision history using
git log -- <file>
Submitting an RFC
- Read RFC_TEMPLATE.md to understand the format requirements
- Refer to EXAMPLE_full_feature_proposal.md to learn how to write
- Create a new file named
number-descriptive-title.md - Place the file in the
docs/reference/rfc/draft/directory - Update this index file to add the new RFC entry
- Submit a PR to enter the review process
Contribution Guidelines
Please refer to CONTRIBUTING.md for contribution guidelines.