It could be interesting when you want to sort two slices using the same order, for exemple, let's say you have
let mut keys = [0, 2, 1, 3];
let mut values = ["d_val0", "c_val2", "b_val1", "a_val3"];
And you want to sort both slice "the same way", you can't just sort the values slice, or else you will get &["a_val3", "b_val1", "c_val2", "d_val0"] instead of &["d_val0", "b_val1", "c_val2", "a_val3"].
The problem with proposing new additions to the standard library is that you have to justify why this method must be in the standard library and can not exist as a utility function/crate.
In general only functions/methods are added that are definitely useful for a large number of people, otherwise one would have dead-code in the standard library.
Another problem is "what if the method was not the right decision?" and one later on regrets adding it to the standard library?
One can not remove (as far as I know) methods from the standard library through an edition, so the best thing one could do would be to deprecate it.
A lot of deprecated methods add noise to the documentation which makes reading the docs a bit more annoying with every new deprecated method.
So what I want to say with this, is that one has to think really carefully about which methods should be added to the standard library and you need to give very convincing arguments how this could be used.
I would recommend adding a few examples to your post that show how one could use it.
A working implementation with an extension trait on play.rust-lang.org would be very appreciated as well.
FWIW, I've wanted this functionality before. Right now, reordering requires cloning or copying, but it would be great if there was some general interface that would allow sorting based on an external order.
It seems to me like the best way to apply a permutation to a slice in-place is to first have the permutation in represented according to cycle notation. Then you don't need that scratchpad anymore that the SO answer was talking about.
If the usage pattern is: create a permutation for one unsorted slice and apply it to multiple slices, then creating an optimal1 representation of the permutation first seems like the correcte approach.
1optimal for the application of in-place reordering slices
This approach would mean that an abstract "Permutation" datatype would be used instead of just a list/array of indices. This also seems suficciently specific to be better fitted for a custom crate than the standard library.