@@ -1314,7 +1314,7 @@ impl<T> [T] {
1314
1314
/// It is designed to be very fast in cases where the slice is nearly sorted, or consists of
1315
1315
/// two or more sorted sequences concatenated one after another.
1316
1316
///
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 .
1318
1318
///
1319
1319
/// # Examples
1320
1320
///
@@ -1326,8 +1326,8 @@ impl<T> [T] {
1326
1326
/// ```
1327
1327
#[ stable( feature = "slice_sort_by_key" , since = "1.7.0" ) ]
1328
1328
#[ 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
1331
1331
{
1332
1332
let mut indices: Vec < _ > = self . iter ( ) . map ( f) . enumerate ( ) . map ( |( i, k) | ( k, i) ) . collect ( ) ;
1333
1333
// The elements of `indices` are unique, as they are indexed, so any sort will be stable
@@ -1418,8 +1418,8 @@ impl<T> [T] {
1418
1418
/// Sorts the slice with a key extraction function, but may not preserve the order of equal
1419
1419
/// elements.
1420
1420
///
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`] .
1423
1423
///
1424
1424
/// This sort is unstable (i.e. may reorder equal elements), in-place (i.e. does not allocate),
1425
1425
/// and `O(m n log m n)` worst-case, where the key function is `O(m)`.
@@ -1432,8 +1432,8 @@ impl<T> [T] {
1432
1432
/// randomization to avoid degenerate cases, but with a fixed seed to always provide
1433
1433
/// deterministic behavior.
1434
1434
///
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.
1437
1437
///
1438
1438
/// # Examples
1439
1439
///
@@ -1444,12 +1444,13 @@ impl<T> [T] {
1444
1444
/// assert!(v == [1, 2, -3, 4, -5]);
1445
1445
/// ```
1446
1446
///
1447
+ /// [`sort_by_key`]: #method.sort_by_key
1448
+ /// [`sort_unstable_by_key`]: #method.sort_unstable_by_key
1447
1449
/// [pdqsort]: https://github.com/orlp/pdqsort
1448
1450
#[ stable( feature = "sort_unstable" , since = "1.20.0" ) ]
1449
1451
#[ 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
1453
1454
{
1454
1455
core_slice:: SliceExt :: sort_unstable_by_key ( self , f) ;
1455
1456
}
0 commit comments