"What requires an RFC?" documentation seems out of date for "small" library additions

I've noticed a pattern recently of people opening issues for or actually writing "micro-RFCs" for adding a method to std, and getting responses that they could just open a PR to rust-lang/rust instead for something that small.

When I saw this happen yesterday (on https://github.com/rust-lang/rfcs/issues/2809) it occurred to me that our official documentation on what requires an RFC might be contributing to this, so I re-read some of it:

rust-lang/rfcs "When you need to follow this process"

What constitutes a "substantial" change is evolving based on community norms and varies depending on what part of the ecosystem you are proposing to change, but may include the following.


  • Additions to std .

RFC guidelines - libraries sub-team

For instance new APIs almost certainly merit an RFC.


Submit an RFC if the change is a:


  • New API

Maybe we should update some of these documents to make an explicit distinction between "small" new APIs that are better as a PR and "large" ones that need an RFC?


Honestly, I personally think that having a short "mRFC" on irlo (or I guess an RFC issue?) is a good thing, as it allows a moment to get an extra few eyes on an API addition before tying together API opinions and code review.

That said, I do agree that we should strive to have our documentation up to date with conventions as much as reasonable, and current convention is that a "small," feature-gated std addition can just FCP a PR rather than going through an (m)RFC first.

My recent proposal about Result::into_ok tells me that: 1) even a small addition will be bikeshedded to hell; 2) it will probably become better as a result. The originally proposed method name was unwrap_infallible, which caused people, including part of me, to cringe.

Yes, but that sott of bikeshed can be done after implementation, while it is still in nightly. RFCs should be for things where there are multiple implementations, all of which have strengths and weaknesses that make it hard to pick a way. Your RFC had 1, maybe 2 cannonical implementations that don't differ by much.

Another reason for an RFC is where the inplementation itself would be expensive, so we would like to check if it has a chance of getting into stable before implementing it.

1 Like

I don't have good experience with issues opened on rust-lang/rfcs as a way to do a mini-RFC. They are often unstructured and vague owing to this being "just an issue", and they tend to get overlooked. There were months-old proposals-as-issues to add a method equivalent to Result::into_ok both on rust-lang/rust and rust-lang/rfcs, and they went nowhere. A PR adding feature-gated items, however, requires an issue on rust-lang/rust to mark the stability attribute with, so it's either issue+PR on rust-lang/rust if it's small and obvious, or a full RFC for something that needs to be discussed.