-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
VecDeque has no sort_by
method (should possibly have one to match Vec).
#27322
Comments
How come either method has to be inherent? Seems like this could be a trait that requires |
|
Wouldn't it have to be |
@retep998 the thing is std has no optimal or inplace sorting! All we have is naive merge sort (because it was argued that our sort should be stable). Our sort support is a bit trash imo. Quicksort (unstable) or wikisort (stable but complicated) would be good to have here. Maybe even expose insertionsort! Even then, it's genuinely unclear to me what would be optimal here. Seems like linearizing the array to make it contiguous and avoid modulo logic could yield huge benefits. |
|
Changing that may be an unacceptable break. |
It'd be cool, if a little overkill, to have a crate with a bunch of different sorting functions. That might make a good crate for contain-rs. |
Oh no, we haven't documented that it's a stable sort. That's a strange oversight. |
"Oh yes" you mean? |
The current situation was definitely an active decision. I'm having trouble finding it, though. I basically agree that it's a weird cost, but there's possibly an argument to be had that it's the "safer" default, and unstable_sort could easily be the opt-in to less reliable behavior. |
@petrochenkov It should be stable by default because a stable sort is more versatile. Reordering equally ordered elements in sort is a potential gotcha, too, and Rust wants to be a nice language. The third party crate space is open to find other sorting algorithms with different tradeoffs. |
Some discussion: |
Why was this closed? The PR linked by bors has nothing to do with VecDeque as far as I can see, and I cannot find a way to sort a VecDeque optimally in std. Someone (@hyeonu in the rust discord) mentioned From VecDeque for Vec and back guarantees to not allocate (In the docs), but it (1) requires ownership of the VecDeque (So can't use it to sort &mut VecDeque afaik) and (2) requires moving some data around before beginning the sort(Which shouldn't be necessary unless I'm missing something). I'm not sure if there are other scenarios that it would make sense to sort that provide random access but are not contiguous memory from first to last (Which the current sort in std requires because it uses slices), but there might be. |
It seems like this should be possible, at least. A slightly non-optimal implementation would be to sort the front and back slices separately and then swap elements back and forth as needed (second step of merge sort, basically). |
Closed because of #69425 I assume |
I just came across a use case for this while working on a visit order for the UI graph in conrod - its absence took me by surprise 😸
Is there a particular reason this hasn't been implemented yet? Or has it just not popped up yet (pun intended)?
The text was updated successfully, but these errors were encountered: