Skip to content

Commit 9c7b69e

Browse files
committed
Remove mentions of unstable sort_by_cached key from stable documentation
1 parent eca1e18 commit 9c7b69e

File tree

1 file changed

+0
-8
lines changed

1 file changed

+0
-8
lines changed

src/liballoc/slice.rs

-8
Original file line numberDiff line numberDiff line change
@@ -1306,10 +1306,6 @@ impl<T> [T] {
13061306
/// This sort is stable (i.e. does not reorder equal elements) and `O(m n log(m n))`
13071307
/// worst-case, where the key function is `O(m)`.
13081308
///
1309-
/// For expensive key functions (e.g. functions that are not simple property accesses or
1310-
/// basic operations), [`sort_by_cached_key`](#method.sort_by_cached_key) is likely to be
1311-
/// significantly faster, as it does not recompute element keys.
1312-
///
13131309
/// When applicable, unstable sorting is preferred because it is generally faster than stable
13141310
/// sorting and it doesn't allocate auxiliary memory.
13151311
/// See [`sort_unstable_by_key`](#method.sort_unstable_by_key).
@@ -1496,10 +1492,6 @@ impl<T> [T] {
14961492
/// randomization to avoid degenerate cases, but with a fixed seed to always provide
14971493
/// deterministic behavior.
14981494
///
1499-
/// Due to its key calling strategy, [`sort_unstable_by_key`](#method.sort_unstable_by_key)
1500-
/// is likely to be slower than [`sort_by_cached_key`](#method.sort_by_cached_key) in
1501-
/// cases where the key function is expensive.
1502-
///
15031495
/// # Examples
15041496
///
15051497
/// ```

0 commit comments

Comments
 (0)