{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibxtviy6x5lxrdmkxscxx3vksil5sydomz6bftomt2hick3lp7lii",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mjisdlqtqi72"
  },
  "path": "/t/t-sort-by-index-and-t-sort-by-key-and-index/24172#post_9",
  "publishedAt": "2026-04-15T00:25:59.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "length checks fail to propagate across non-trivial conditions"
  ],
  "textContent": "I would love something like that too. I end up with some variations of parallel arrays / structure-of-arrays quite often.\n\nThat'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.\n\nI'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.\n\n\n    [values].sort_by_keys(&mut [keys])\n    // or\n    [keys].sort_values(&mut [values])\n\n\nThe 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]))`.",
  "title": "`<[T]>::sort_by_index` and `<[T]>::sort_by_key_and_index`"
}