Implement a free sorted_unstable

[chris-ha458]

Would it be possible to merge this?

[Philippe-Cholet]

It surely seems legitimate. But I don't know what is our policy about "free" functions yet.
@phimuemue @jswrenn

[jswrenn]

@chris-ha458, can you say a little bit about why you need this to be a free function? Why is the existing method not adequate?

[chris-ha458]

It definitely is not a "need" but a "nice to have".

I'm not finding the specific snippet of code right now but it looks a bit like this.

use itertools::sorted;

fn process_vec(mut input: Vec<String>) -> Vec<String> {
    input.push("1".to_string());
    // other processing steps
    sorted(input)
}

This is a small contrived example, but i think you can see how it could be useful.
Right now if I want to use unstable sort, it would have to end with

input.sort_unstable()
input
}

With my PR it could follow the above

sort_unstable(input)
}

This proposed change is minor and not critical. However, it could enhance the functionality in scenarios involving functional chaining, tail calls, maps, and closures.

While introducing additional code increases maintenance complexity, only looking at the immediately related sections of the code, the simplicity of this change does not seem to significantly add to that burden.

I understand that this PR may be closed for various reasons. Nonetheless, explanations for closing or prerequisites for merging would be beneficial, if only for documentation purposes.

[scottmcm]

I think the note is that you could use https://docs.rs/itertools/latest/itertools/trait.Itertools.html#method.sorted_unstable to write

fn process_vec(mut input: Vec<String>) -> Vec<String> {
    input.push("1".to_string());
    // other processing steps
    input.into_iter().sorted_unstable()
}

without a free function, while still moving it.

But it's certainly true that if https://docs.rs/itertools/latest/itertools/fn.sorted.html was apparently decided to be worth having at some point, it's hard to say why a sorted_unstable function wouldn't be...

[chris-ha458]

I agree with all of your points.
Coming from developing with python, my intuition was that sorted only exists to provide a similar interface in rust. Tbh I'm not sure that would have been a good idea, since there are different idiomatic patterns are available in rust, but such design choices happen all the time.

If that were the case it would be easy to reject this one. First of all, python does not offer a sorted_unstable function. Secondly offering sorted in the first place would have been a suboptimal choice and this would be doubling down on a bad path.

I don't think this is a problem, hence authoring the PR but I could definitely understand anybody that does..

[Philippe-Cholet]

It's either input.into_iter().sorted_unstable() or (the proposed) sorted_unstable(input). Free functions convert into an iterator under the hood, which for me is the main selling point.
#91 added the free "sorted" (I was looking for a reason that would help us here but no).

Edit: About free functions, I found that interesting.