`<[T]>::sort_by_index` and `<[T]>::sort_by_key_and_index`

I would love something like that too. I end up with some variations of parallel arrays / structure-of-arrays quite often.

That's technically quite close to sort_by_cached_key, but I almost never end up using actual sort_by_cached_key, because typically I have to build all the keys first using some elaborate process that can't make keys on demand, so I have to make my own "cached_key" storage, but still need the "sort" part.

I'm not sure if |slice, i, j| could optimize out bounds checks. I've tried to make LLVM remove bounds checks in select_nth_unstable and found that length checks fail to propagate across non-trivial conditions. But something that takes a slice of keys and a slice of values to sort, performs a one-time length check, and then swaps with unsafe indexing under the hood if necessary, would be fine for me.

[values].sort_by_keys(&mut [keys])
// or
[keys].sort_values(&mut [values])

The latter could work with multiple homogeneous parallel arrays via [keys].sort_values(&mut [[values]; N]). With some hypothetical variadic generics, or enough macro hacks, maybe it could support multiple different parallel arrays [keys].sort_values((&mut [T], &mut [U])).