Skip to content

Commit

Permalink
Remove mentions of unstable sort_by_cached key from stable documentation
Browse files Browse the repository at this point in the history
  • Loading branch information
varkor committed Mar 26, 2018
1 parent eca1e18 commit 9c7b69e
Showing 1 changed file with 0 additions and 8 deletions.
8 changes: 0 additions & 8 deletions src/liballoc/slice.rs
Original file line number Diff line number Diff line change
Expand Up @@ -1306,10 +1306,6 @@ 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).
Expand Down Expand Up @@ -1496,10 +1492,6 @@ impl<T> [T] {
/// randomization to avoid degenerate cases, but with a fixed seed to always provide
/// deterministic behavior.
///
/// Due to its key calling strategy, [`sort_unstable_by_key`](#method.sort_unstable_by_key)
/// is likely to be slower than [`sort_by_cached_key`](#method.sort_by_cached_key) in
/// cases where the key function is expensive.
///
/// # Examples
///
/// ```
Expand Down

0 comments on commit 9c7b69e

Please sign in to comment.