Status: Draft | Under Review | Accepted | Rejected | Superseded
Authors:
A brief (1-2 paragraph) description of the proposal. What is being proposed and why? This should be understandable without reading the rest of the document.
Why is this change needed? What problem does it solve? What use cases does it enable? Include any relevant background context that helps readers understand the motivation.
- Specific goal 1
- Specific goal 2
What is explicitly out of scope for this RFC? List items that might be assumed to be in scope but are intentionally deferred or excluded.
- Non-goal 1 (left for future RFCs)
- Non-goal 2
The detailed technical design. This is the core of the RFC and should be comprehensive enough for implementation.
Break the design into logical subsections. Include:
- Data structures and APIs
- Algorithms and workflows
- Code examples where helpful
- Edge cases and error handling
// Example code blocks for API proposals
struct Example {
field: Type,
}What other approaches were considered? Why were they rejected? This helps readers understand the design space and the reasoning behind the chosen approach.
Optional section for unresolved questions that need input during the review process.
| Date | Description |
|---|---|
| YYYY-MM-DD | Initial draft |