Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add [T]::as_ptr_range() #2791
Unless there’s a lot of design to discuss we’re generally OK with accepting a PR adding “small” APIs to the standard library, without an RFC. Having two people (submitter + reviewer) think something is a good idea is deemed good enough for including unstable APIs, on the basis that there will be wider review and consensus-gathering before FCP for stabilization.
@rust-lang/libs We should probably tweak https://github.com/rust-lang/rfcs/blob/master/libs_changes.md#is-an-rfc-required to reflect current practice regarding new APIs.
Good to know! I'll send a PR to the Rust repository then.
Before I make the same mistake again: Would the things I describe in future possibilities warrant an RFC, or could that also be a Rust PR directly? (Still a small change, but there's more to discuss about signatures and names, I'd guess.)
I should have clarified: my previous comment is about the process in general. I don’t mean that this RFC should be closed, now that it’s written.
@m-ou-se It’s not really a mistake. There are two options, if unsure do what’s easiest to you.
One of the reasons the RFC process exists is that people sometimes poured a lot of effort into implementing something that turned later out not to be accepted, or not in that form. This is not a concern when an implementation PR is easy to make.