-
Notifications
You must be signed in to change notification settings - Fork 13.3k
std: Stabilize a number of small APIs #27370
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The following APIs were all marked with a `#[stable]` tag: * process::Child::id * error::Error::is * error::Error::downcast * error::Error::downcast_ref * error::Error::downcast_mut * io::Error::get_ref * io::Error::get_mut * io::Error::into_inner * hash::Hash::hash_slice * hash::Hasher::write_{i,u}{8,16,32,64,size}
r? @aturon |
r? @huonw (rust_highfive has picked a reviewer for you, use r? to override) |
@@ -233,8 +232,7 @@ impl Error { | |||
/// | |||
/// If this `Error` was constructed via `new` then this function will | |||
/// return `Some`, otherwise it will return `None`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should add a note to the docs for these methods about the need to call via UFCS - it confused the hell out of me for a while when I was writing tests for them.
EDIT: Ah, looks like it works now from the tests, nvm.
lgtm |
Is there any paper trail documenting the rationale for stabilizing these? Why these and why now? |
We've got a huge number (~150) of unstable features in the standard library, and we need to start taking action on them. Many of them have been around for months so they either need to be deprecated or they need to be stabilized. This is a small set of features which feel pretty uncontroversial and are part of the crucial designs of primitives leading up to 1.0:
I would like to include more but they all seemed to have at least one unresolved question. |
Don't care about process and io, but I recall we historically had issues with the hasher API as is. Are these parts not part of the problem, or has something changed? (maybe I'm misremembering) |
You can find more of the initial discussion here: #19673, but it was largely about the high-level design (where generics are, the signature of |
👍 on the hasher stuff -- seems harmless at worst. |
Thanks for the explanation. @bors r+ |
📌 Commit 76db37e has been approved by |
⌛ Testing commit 76db37e with merge 8c6e940... |
💔 Test failed - auto-mac-32-opt |
@bors: retry On Thu, Jul 30, 2015 at 3:25 AM, bors notifications@github.com wrote:
|
⌛ Testing commit 76db37e with merge 938f5d7... |
💔 Test failed - auto-linux-64-opt |
@bors: retry On Thu, Jul 30, 2015 at 11:42 AM, bors notifications@github.com wrote:
|
⌛ Testing commit 76db37e with merge 70fe4ef... |
💔 Test failed - auto-mac-32-opt |
@bors: retry On Thu, Jul 30, 2015 at 2:25 PM, bors notifications@github.com wrote:
|
The following APIs were all marked with a `#[stable]` tag: * process::Child::id * error::Error::is * error::Error::downcast * error::Error::downcast_ref * error::Error::downcast_mut * io::Error::get_ref * io::Error::get_mut * io::Error::into_inner * hash::Hash::hash_slice * hash::Hasher::write_{i,u}{8,16,32,64,size}
The following APIs were all marked with a
#[stable]
tag: