ferrule

rfcs

active

ferrule rfcs

rfcs (request for comments) describe features that are proposed but not yet part of the core specification. they represent future directions for the language.

what is an rfc?

an rfc is a design document for a feature that:

  • is too large or risky for the current milestone
  • needs community feedback before commitment
  • represents a significant change to the language

rfcs are not commitments. they may be accepted, modified, or rejected.

rfc status

statusmeaning
draftinitial proposal, open for feedback
acceptedwill be implemented in target version
implementedmerged into main spec
rejecteddecided against
deferredgood idea, but not now

active rfcs

α2 target

rfctitlestatus
0001error transformation (map_error)draft
0002debug context framesdraft
0003const genericsdraft

β target

rfctitlestatus
0005higher-kinded typesdraft
0006mapped typesdraft
0010structured concurrencydraft
0011async effectsdraft

future / unscheduled

rfctitlestatus
0004compile-time evaluation (comptime)planned
0007conditional typesplanned
0008variadic genericsplanned
0009template literal typesplanned
0012capsules (unique resources)planned
0013capability attenuationplanned
0014content-addressed packagesplanned
0015webassembly supportplanned
0016inline assemblyplanned

writing an rfc

use the template as a starting point. an rfc should:

  1. explain the motivation clearly
  2. describe the design in enough detail to implement
  3. discuss tradeoffs and alternatives
  4. reference prior art from other languages

rfc process

  1. draft: author writes initial proposal
  2. discussion: community feedback, revisions
  3. decision: accept, reject, or defer
  4. implementation: if accepted, implement and test
  5. merge: move to main spec when stable

On this page