The Rust RFC Process — Rust Lecture Notes

The Rust Request for Comments (RFC) process (rust-lang/rfcs) is the consensus-driven design workflow used to propose, debate, and approve substantial changes to the Rust language, standard library, Cargo, and project governance. For smaller standard library additions (such as adding a helper method on Option or slice), the Library API Team uses a lighter-weight API Change Proposal (ACP) workflow in rust-lang/libs-team.

Choosing the Right Proposal Track:

  - Bug fix, diagnostic tweak, or perf optimization?
    ---> Direct Pull Request to `rust-lang/rust` (No RFC needed!)

  - New method/trait in `core`/`alloc`/`std`?
    ---> API Change Proposal (ACP) issue in `rust-lang/libs-team`

  - New language syntax, type-system rule, Edition change, or Cargo feature?
    ---> Full RFC Pull Request in `rust-lang/rfcs`!

Required Sections of a Rust RFC Document

Every RFC in rust-lang/rfcs/text/NNNN-feature-name.md follows a standardized engineering template designed to force clear trade-off analysis:

RFC Section	Purpose
Summary	One-paragraph explanation of the proposed change.
Motivation	Why are we doing this? What concrete real-world problems or ergonomics gaps does it solve?
Guide-level explanation	How do you teach this feature to an everyday Rust programmer? (Written like a chapter of The Rust Programming Language with clear examples).
Reference-level explanation	Exact compiler/specification rules: grammar changes, type-inference rules, borrow-checker interactions, ABI/layout rules, and corner cases.
Drawbacks	*Why should we not* do this?** (Compile-time cost, language complexity budget, teaching burden).
Rationale and alternatives	Why is this design the best among alternative syntax or library approaches? What happens if we do nothing?
Prior art	How do C++, Swift, Haskell, OCaml, Zig, or ecosystem crates handle this?
Unresolved questions	Details intentionally deferred to be answered during nightly implementation before stabilization.
Future possibilities	Natural extensions that build on this RFC in the future without committing to them today.

Domain Teams That Review RFCs

Each RFC is assigned to one or more official Rust sub-teams (T-*), and merging (@rfcbot fcp merge), postponing (fcp postpone), or closing (fcp close) requires consensus from that team:

T-lang (Language Team): Syntax, semantics, type system, borrow checker, unsafe memory model.
T-libs-api (Library API Team): Public types, traits, and functions in core, alloc, and std.
T-compiler (Compiler Team): Implementation feasibility and compile-time performance in rustc.
T-cargo (Cargo Team): Manifest keys, dependency resolution, and build orchestration.
T-types (Types Team): Trait solver (next-solver), lifetimes, coherence, and variance.

/// Example of a feature that started as an ACP / RFC and stabilized into `core`:
/// `core::net::{IpAddr, SocketAddr}` (RFC 2832 -> moved networking address types into `core`).
use core::net::{IpAddr, Ipv4Addr, SocketAddr};

fn main() {
    let addr = SocketAddr::new(IpAddr::V4(Ipv4Addr::LOCALHOST), 8080);
    println!("RFC 2832 `core::net::SocketAddr`: {addr}");
}

RFC 2832 `core::net::SocketAddr`: 127.0.0.1:8080