Skip to content

Commit f3adec6

Browse files
committed
Auto merge of #53918 - Havvy:doc-sort-by, r=GuillaumeGomez
Doc total order requirement of sort(_unstable)_by I took the definition of what a total order is from the Ord trait docs. I specifically put "elements of the slice" because if you have a slice of f64s, but know none are NaN, then sorting by partial ord is total in this case. I'm not sure if I should give such an example in the docs or not. r? @GuillaumeGomez
2 parents 4bec59c + 99bed21 commit f3adec6

File tree

2 files changed

+32
-0
lines changed

2 files changed

+32
-0
lines changed

src/liballoc/slice.rs

+16
Original file line numberDiff line numberDiff line change
@@ -213,6 +213,22 @@ impl<T> [T] {
213213
///
214214
/// This sort is stable (i.e. does not reorder equal elements) and `O(n log n)` worst-case.
215215
///
216+
/// The comparator function must define a total ordering for the elements in the slice. If
217+
/// the ordering is not total, the order of the elements is unspecified. An order is a
218+
/// total order if it is (for all a, b and c):
219+
///
220+
/// * total and antisymmetric: exactly one of a < b, a == b or a > b is true; and
221+
/// * transitive, a < b and b < c implies a < c. The same must hold for both == and >.
222+
///
223+
/// For example, while [`f64`] doesn't implement [`Ord`] because `NaN != NaN`, we can use
224+
/// `partial_cmp` as our sort function when we know the slice doesn't contain a `NaN`.
225+
///
226+
/// ```
227+
/// let mut floats = [5f64, 4.0, 1.0, 3.0, 2.0];
228+
/// floats.sort_by(|a, b| a.partial_cmp(b).unwrap());
229+
/// assert_eq!(floats, [1.0, 2.0, 3.0, 4.0, 5.0]);
230+
/// ```
231+
///
216232
/// When applicable, unstable sorting is preferred because it is generally faster than stable
217233
/// sorting and it doesn't allocate auxiliary memory.
218234
/// See [`sort_unstable_by`](#method.sort_unstable_by).

src/libcore/slice/mod.rs

+16
Original file line numberDiff line numberDiff line change
@@ -1510,6 +1510,22 @@ impl<T> [T] {
15101510
/// This sort is unstable (i.e. may reorder equal elements), in-place (i.e. does not allocate),
15111511
/// and `O(n log n)` worst-case.
15121512
///
1513+
/// The comparator function must define a total ordering for the elements in the slice. If
1514+
/// the ordering is not total, the order of the elements is unspecified. An order is a
1515+
/// total order if it is (for all a, b and c):
1516+
///
1517+
/// * total and antisymmetric: exactly one of a < b, a == b or a > b is true; and
1518+
/// * transitive, a < b and b < c implies a < c. The same must hold for both == and >.
1519+
///
1520+
/// For example, while [`f64`] doesn't implement [`Ord`] because `NaN != NaN`, we can use
1521+
/// `partial_cmp` as our sort function when we know the slice doesn't contain a `NaN`.
1522+
///
1523+
/// ```
1524+
/// let mut floats = [5f64, 4.0, 1.0, 3.0, 2.0];
1525+
/// floats.sort_by(|a, b| a.partial_cmp(b).unwrap());
1526+
/// assert_eq!(floats, [1.0, 2.0, 3.0, 4.0, 5.0]);
1527+
/// ```
1528+
///
15131529
/// # Current implementation
15141530
///
15151531
/// The current algorithm is based on [pattern-defeating quicksort][pdqsort] by Orson Peters,

0 commit comments

Comments
 (0)