Rust Internals debates index-aware slice sorting APIs for data-oriented code

Sorting a leaderboard by a separate score table, reordering UI rows, or preserving tie-break context could get a lot less awkward in Rust if slice sorting grows index-aware variants. A Rust Internals discussion posted April 14, 2026, titled sort_by_index and sort_by_key_and_index, proposed both stable and unstable forms, including sort_by_index, sort_by_key_and_index, sort_unstable_by_index, and sort_unstable_by_key_and_index.

The pitch is aimed squarely at data-oriented programming. Instead of first building a permutation by hand with enumerate, sort, and a second pass to apply the result, the API would pass either an item index or an index plus item reference into the key function. That makes it possible to sort one array using keys stored in another, which is the kind of cross-slice rearrangement that shows up in structure-of-arrays layouts and other performance-minded code.

The thread quickly moved from ergonomics to implementation, and that is where the idea starts to look less like a cosmetic tweak and more like a real systems tradeoff. One responder pointed out that a working implementation would likely need to allocate a temporary vector of indices, because the indices themselves move as elements are swapped during sorting. Another suggested a caller-provided scratch array of usize values as a way to keep the allocation outside the library call.

That tension matters because Rust already has a nearby precedent. The standard library’s sort_by_cached_key allocates internally, but it does not guarantee the order in which key-generator calls happen. For some workloads, that is a fine compromise. For others, especially where the ordering depends on outside data or on an element’s position rather than the element alone, index-aware sorting would expose a different kind of control. The existing sort_unstable stays in place and does not allocate, while the stable sort path already carries its own allocation costs.

This is not a new wish list item either. A Rust Internals thread from November 8, 2021 asked for argsort-style methods, one to compute the indices that would sort a slice and another to reorder a slice by a given permutation. Commenters in that discussion framed the use case as column-oriented data or applying one slice’s ordering to another. A later thread on December 21, 2021 about unallocating stable sort added more context, noting that the current stable sort allocates and that the implementation uses at most half the size of the input slice, while another comment observed that sort_by_cached_key can use sort_unstable internally because the cached index makes items distinct.

Taken together, the new proposal reads like part of a longer push to make permutation-first workflows feel native in Rust. If it lands, it could trim a familiar layer of bespoke code from hobby projects, data pipelines, and any Rust program that needs to sort by reference, not by value.