diff options
| author | kennytm <kennytm@gmail.com> | 2019-02-16 00:55:47 +0800 |
|---|---|---|
| committer | kennytm <kennytm@gmail.com> | 2019-02-16 14:11:28 +0800 |
| commit | f05e6bf7089fa3d5f3b490eb8d9fc89bc044604d (patch) | |
| tree | 256a9a879d98e6aaffb4497c290c8795322c1c2c /src/liballoc/slice.rs | |
| parent | 84e88da4311e4c2dac3789de708ec5232a3deeff (diff) | |
| parent | 317f15304e6091a1f3cc58c52d36df037ef50db0 (diff) | |
| download | rust-f05e6bf7089fa3d5f3b490eb8d9fc89bc044604d.tar.gz rust-f05e6bf7089fa3d5f3b490eb8d9fc89bc044604d.zip | |
Rollup merge of #58074 - scottmcm:stabilize-sort_by_cached_key, r=SimonSapin
Stabilize slice_sort_by_cached_key
I was going to ask on the tracking issue (https://github.com/rust-lang/rust/issues/34447), but decided to just send this and hope for an FCP here. The method was added last March by https://github.com/rust-lang/rust/pull/48639.
Signature: https://doc.rust-lang.org/std/primitive.slice.html#method.sort_by_cached_key
```rust
impl [T] {
pub fn sort_by_cached_key<K, F>(&mut self, f: F)
where F: FnMut(&T) -> K, K: Ord;
}
```
That's an identical signature to the existing `sort_by_key`, so I think the questions are just naming, implementation, and the usual "do we want this?".
The implementation seems to have proven its use in rustc at least, which many uses: https://github.com/rust-lang/rust/search?l=Rust&q=sort_by_cached_key
(I'm asking because it's exactly what I just needed the other day:
```rust
all_positions.sort_by_cached_key(|&n|
data::CITIES.iter()
.map(|x| *metric_closure.get_edge(n, x.pos).unwrap())
.sum::<usize>()
);
```
since caching that key is a pretty obviously good idea.)
Closes #34447
Diffstat (limited to 'src/liballoc/slice.rs')
| -rw-r--r-- | src/liballoc/slice.rs | 7 |
1 files changed, 5 insertions, 2 deletions
diff --git a/src/liballoc/slice.rs b/src/liballoc/slice.rs index c4f4a80a017..f4b2d463778 100644 --- a/src/liballoc/slice.rs +++ b/src/liballoc/slice.rs @@ -257,6 +257,10 @@ impl<T> [T] { /// This sort is stable (i.e., does not reorder equal elements) and `O(m n log(m n))` /// worst-case, where the key function is `O(m)`. /// + /// For expensive key functions (e.g. functions that are not simple property accesses or + /// basic operations), [`sort_by_cached_key`](#method.sort_by_cached_key) is likely to be + /// significantly faster, as it does not recompute element keys. + /// /// When applicable, unstable sorting is preferred because it is generally faster than stable /// sorting and it doesn't allocate auxiliary memory. /// See [`sort_unstable_by_key`](#method.sort_unstable_by_key). @@ -312,7 +316,6 @@ impl<T> [T] { /// # Examples /// /// ``` - /// #![feature(slice_sort_by_cached_key)] /// let mut v = [-5i32, 4, 32, -3, 2]; /// /// v.sort_by_cached_key(|k| k.to_string()); @@ -320,7 +323,7 @@ impl<T> [T] { /// ``` /// /// [pdqsort]: https://github.com/orlp/pdqsort - #[unstable(feature = "slice_sort_by_cached_key", issue = "34447")] + #[stable(feature = "slice_sort_by_cached_key", since = "1.34.0")] #[inline] pub fn sort_by_cached_key<K, F>(&mut self, f: F) where F: FnMut(&T) -> K, K: Ord |
