-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Tracking issue for clamp RFC #44095
Comments
Add clamp functions Implementation of clamp feature: Tracking issue: rust-lang#44095 RFC: rust-lang/rfcs#1961
Add clamp functions Implementation of clamp feature: Tracking issue: rust-lang#44095 RFC: rust-lang/rfcs#1961
…Rust library method of the same name. Fixes breakage from rust-lang/rust#44095.
This comment has been minimized.
This comment has been minimized.
Explicitly invoke `Au::clamp()` to avoid colliding with the unstable Rust library method of the same name. Fixes breakage from rust-lang/rust#44095. r? @Manishearth
cc @rust-lang/libs, this is a case similar to Nominating for the triage meeting on Tues. Any thoughts in the meantime? |
I'm kind of with @bluss on this one in that it would be nice not to repeat it. "Clamp" is probably a great name, but could we sidestep this by choosing a different name? |
|
If we think we might need to rename, it's probably best to revert the PR immediately, and then test more carefully with crater etc. @Xaeroxe, up for that? |
Sure. I've never used crater before, but I can learn. |
@Xaeroxe ah sorry, I meant getting a revert PR up quickly. (I'm on vacation today so you may need someone else on libs, like @BurntSushi or @alexcrichton, to help land it). |
I'm preparing the PR now. Have fun on your vacation! |
PR ready #44438 |
Revert clamp Revert clamp per #44095 (comment) while we take time to assess the potential backwards compatibility damage done by it.
Could |
I suppose that idea mandates an RFC. |
I gotta say though I've been working on getting a 4 line function into the std library for 6 months now. I'm kind of worn out. The same function got merged into num in 2 days and that's good enough for me. If anyone else really wants this in the std library go ahead, but I'm just not ready for another 6 months of this. |
I'm reopening this so that @aturon 's previous nomination will still be seen. |
I think that either this should go in as-written or the guidance on what changes can be made should be updated to avoid wasting peoples' time in future. It was very clear from early that this could cause the breakage it did. Personally, I compared it to
And the response to that was "The function It feels, subjectively, to me that if this RFC is reverted, the actual rule is "You basically can't put new methods on traits in std, except maybe |
You also can't really put new methods on actual types either. Consider the situation where someone had an "extension trait" for a type in std. Now std implements a method the extension trait provided as an actual method on this type. Then this reaches stable, but this new method is still behind a feature flag. The compiler will then complain that the method is behind a feature flag and can't be used with the stable toolchain, instead of the compiler choosing the extension trait's method like before and thus causing breakage on the stable compiler. |
It's also worth noting: This isn't just a standard library problem. Method call syntax makes it really difficult to avoid introducing breaking changes just about anywhere in the ecosystem. |
This has been merged and unstable for about a year and a half now. How do we feel about stabilizing this? |
I would love stabilizing this! |
If |
@Xaeroxe I think the process is to submit stabilization PR and ask for libs team consensus on that. It seems that t-libs is overloaded and can't keep up with non-fcped things. |
Okay, did that #77872 |
@matklad actually an FCP proposal already started last year at #44095 (comment), but it is stuck because there is one remaining checkbox. |
In that case, I think being pinged about once a year on an issue is pretty tolerable. @Kimundi #44095 (comment) is still awaiting your attention |
The libs team has changed quite a bit since the FCP was started. What do you all think about just starting a new FCP in the stabilization PR? Feels like that shouldn't take longer than waiting for the remaining checkboxes here. |
@LukasKalbertodt fine by me, do you mind kicking that off? |
Cancelling the FCP here, because that FCP now happened on the stabilization PR: #77872 (comment) @Fcpbot cancel |
uh @rfcbot cancel |
@m-ou-se proposal cancelled. |
Stabilize clamp Tracking issue: rust-lang#44095 Clamp has been merged and unstable for about a year and a half now. How do we feel about stabilizing this?
Stabilized in #77872, I think this can be closed. |
Move {f32,f64}::clamp to core. `clamp` was recently stabilized (tracking issue: rust-lang#44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`), the versions for the `f32` and `f64` primitives were added in `std` (together with `floor`, `sin`, etc.), not in `core` (together with `min`, `max`, `from_bits`, etc.). This change moves them to `core`, such that `clamp` on floats is available in `no_std` programs as well.
Rust std's `clamp` has been stabilised in 1.50: rust-lang/rust#44095 This is already the minimum supported version, so no change there 👍
Tracking issue for rust-lang/rfcs#1961
PR here:
#44097#58710Stabilization PR: #77872
TODO:
The text was updated successfully, but these errors were encountered: