-
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 sort_floats #93396
Comments
I feel like |
I don't think these are useful. Surely it's not very hard to use I think, although longer, forcing the long usage makes users aware of the possible issues, instead of sweeping them under the rug. As for name, I think |
As mentioned in rust-lang/unsafe-code-guidelines#237 (comment), we probably shouldn't stabilize the current implementation of this at the moment -- it looks increasingly likely that we're going to have to say that the sign bit of NaN is fundamentally non-deterministic, at least in the short term. A sorting function that puts NaNs non-deterministically at the start or end of the slice is probably far too error-prone for us to want to stabilize. (I probably should have pushed back harder than I did on |
I just learned the existence of this... and while I like the idea of having this capability, just tacking on a separate method called "sort_floats" feels very unwieldy. It feels like it would be much more ergonomic to do something like adding an implementation of |
I don't like that it uses If there's going to be a dedicated method, I'd like one that is optimized for finite floats which can use the cheapest comparison available, ignoring what that means for Also it should be |
Feature gate:
#![feature(sort_floats)]
This is a tracking issue for the
sort_floats
method on[f32]
and[f64]
, a convenience method to sort a slice of floats by callingsort_unstable_by
usingtotal_cmp
.Public API
Steps / History
[f32]::sort_floats
and[f64]::sort_floats
#93397Open questions
sort
, which would require some additional steps (possibly negative impls forOrd
onf32
andf64
) to avoid a name conflict?The text was updated successfully, but these errors were encountered: