@@ -1314,7 +1314,7 @@ impl<T> [T] {
13141314 /// It is designed to be very fast in cases where the slice is nearly sorted, or consists of
13151315 /// two or more sorted sequences concatenated one after another.
13161316 ///
1317- /// The algorithm allocates temporary storage the size of `self` .
1317+ /// The algorithm allocates temporary storage in a `Vec<(K, usize)` the length of the slice .
13181318 ///
13191319 /// # Examples
13201320 ///
@@ -1326,8 +1326,8 @@ impl<T> [T] {
13261326 /// ```
13271327 #[ stable( feature = "slice_sort_by_key" , since = "1.7.0" ) ]
13281328 #[ inline]
1329- pub fn sort_by_key < B , F > ( & mut self , f : F )
1330- where F : FnMut ( & T ) -> B , B : Ord
1329+ pub fn sort_by_key < K , F > ( & mut self , f : F )
1330+ where F : FnMut ( & T ) -> K , K : Ord
13311331 {
13321332 let mut indices: Vec < _ > = self . iter ( ) . map ( f) . enumerate ( ) . map ( |( i, k) | ( k, i) ) . collect ( ) ;
13331333 // The elements of `indices` are unique, as they are indexed, so any sort will be stable
@@ -1418,8 +1418,8 @@ impl<T> [T] {
14181418 /// Sorts the slice with a key extraction function, but may not preserve the order of equal
14191419 /// elements.
14201420 ///
1421- /// Note that, currently, the key function for `sort_unstable_by_key` is called multiple times
1422- /// per element, unlike `sort_stable_by_key` .
1421+ /// Note that, currently, the key function for [ `sort_unstable_by_key`] is called multiple times
1422+ /// per element, unlike [`sort_by_key`] .
14231423 ///
14241424 /// This sort is unstable (i.e. may reorder equal elements), in-place (i.e. does not allocate),
14251425 /// and `O(m n log m n)` worst-case, where the key function is `O(m)`.
@@ -1432,8 +1432,8 @@ impl<T> [T] {
14321432 /// randomization to avoid degenerate cases, but with a fixed seed to always provide
14331433 /// deterministic behavior.
14341434 ///
1435- /// Due to its key calling strategy, `sort_unstable_by_key` is likely to be slower than
1436- /// `sort_by_key` in cases where the key function is expensive.
1435+ /// Due to its key calling strategy, [ `sort_unstable_by_key`] is likely to be slower than
1436+ /// [ `sort_by_key`] in cases where the key function is expensive.
14371437 ///
14381438 /// # Examples
14391439 ///
@@ -1444,12 +1444,13 @@ impl<T> [T] {
14441444 /// assert!(v == [1, 2, -3, 4, -5]);
14451445 /// ```
14461446 ///
1447+ /// [`sort_by_key`]: #method.sort_by_key
1448+ /// [`sort_unstable_by_key`]: #method.sort_unstable_by_key
14471449 /// [pdqsort]: https://github.com/orlp/pdqsort
14481450 #[ stable( feature = "sort_unstable" , since = "1.20.0" ) ]
14491451 #[ inline]
1450- pub fn sort_unstable_by_key < B , F > ( & mut self , f : F )
1451- where F : FnMut ( & T ) -> B ,
1452- B : Ord
1452+ pub fn sort_unstable_by_key < K , F > ( & mut self , f : F )
1453+ where F : FnMut ( & T ) -> K , K : Ord
14531454 {
14541455 core_slice:: SliceExt :: sort_unstable_by_key ( self , f) ;
14551456 }
0 commit comments