# Implementing new language features
<!-- toc -->
When you want to implement a new significant feature in the compiler,
you need to go through this process to make sure everything goes
smoothly.
**NOTE: this section is for *language* features, not *library* features,
which use [a different process].**
See also [the Rust Language Design Team's procedures][lang-propose] for
proposing changes to the language.
## The @rfcbot FCP process
When the change is small and uncontroversial, then it can be done
with just writing a PR and getting an r+ from someone who knows that
part of the code. However, if the change is potentially controversial,
it would be a bad idea to push it without consensus from the rest
of the team (both in the "distributed system" sense to make sure
you don't break anything you don't know about, and in the social
sense to avoid PR fights).
If such a change seems to be too small to require a full formal RFC process
(e.g., a small standard library addition, a big refactoring of the code, a
"technically-breaking" change, or a "big bugfix" that basically amounts to a
small feature) but is still too controversial or big to get by with a single r+,
you can propose a final comment period (FCP). Or, if you're not on the relevant
team (and thus don't have @rfcbot permissions), ask someone who is to start one;
unless they have a concern themselves, they should.
Again, the FCP process is only needed if you need consensus – if you
don't think anyone would have a problem with your change, it's OK to
get by with only an r+. For example, it is OK to add or modify
unstable command-line flags or attributes without an FCP for
compiler development or standard library use, as long as you don't
expect them to be in wide use in the nightly ecosystem.
Some teams have lighter weight processes that they use in scenarios
like this; for example, the compiler team recommends
filing a Major Change Proposal ([MCP][mcp]) as a lightweight way to
garner support and feedback without requiring full consensus.
You don't need to have the implementation fully ready for r+ to propose an FCP,
but it is generally a good idea to have at least a proof
of concept so that people can see what you are talking about.
When an FCP is proposed, it requires all members of the team to sign off the
FCP. After they all do so, there's a 10-day-long "final comment period" (hence
the name) where everybody can comment, and if no concerns are raised, the
PR/issue gets FCP approval.
## The logistics of writing features
There are a few "logistic" hoops you might need to go through in
order to implement a feature in a working way.
### Warning Cycles
In some cases, a feature or bugfix might break some existing programs
in some edge cases. In that case, you might want to do a crater run
to assess the impact and possibly add a future-compatibility lint,
similar to those used for
[edition-gated lints](diagnostics.md#edition-gated-lints).
### Stability
We [value the stability of Rust]. Code that works and runs on stable
should (mostly) not break. Because of that, we don't want to release
a feature to the world with only team consensus and code review -
we want to gain real-world experience on using that feature on nightly,
and we might want to change the feature based on that experience.
To allow for that, we must make sure users don't accidentally depend
on that new feature - otherwise, especially if experimentation takes
time or is delayed and the feature takes the trains to stable,
it would end up de facto stable and we'll not be able to make changes
in it without breaking people's code.
The way we do that is that we make sure all new features are feature
gated - they can't be used without enabling a feature gate
(`#[feature(foo)]`), which can't be done in a stable/beta compiler.
See the [stability in code] section for the technical details.
Eventually, after we gain enough experience using the feature,
make the necessary changes, and are satisfied, we expose it to