Skip to content

Commit 9ab80a5

Browse files
committed
reword 'sort-by' edge-conditions documentation; resolves rust-lang#130122
1 parent d571ae8 commit 9ab80a5

File tree

1 file changed

+9
-4
lines changed

1 file changed

+9
-4
lines changed

library/alloc/src/slice.rs

Lines changed: 9 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -178,10 +178,15 @@ impl<T> [T] {
178178
/// This sort is stable (i.e., does not reorder equal elements) and *O*(*n* \* log(*n*))
179179
/// worst-case.
180180
///
181-
/// If the implementation of [`Ord`] for `T` does not implement a [total order] the resulting
182-
/// order of elements in the slice is unspecified. All original elements will remain in the
183-
/// slice and any possible modifications via interior mutability are observed in the input. Same
184-
/// is true if the implementation of [`Ord`] for `T` panics.
181+
/// If the comparison function compare does not implement a [total order], the function may
182+
/// panic; even if the function exits normally, the resulting order of elements in the slice is
183+
/// unspecified.
184+
///
185+
/// Even if `sort_by` or `compare` panics, all original elements will remain in the slice and
186+
/// any possible modifications via interior mutability are observed in the input. This ensures
187+
/// that recovery code (for instance inside of a `Drop` or following a `catch_unwind`) will
188+
/// still have access to all the original elements. For instance, if the slice belongs to a
189+
/// `Vec`, the `Vec::drop` method will be able to dispose of all contained elements.
185190
///
186191
/// When applicable, unstable sorting is preferred because it is generally faster than stable
187192
/// sorting and it doesn't allocate auxiliary memory. See

0 commit comments

Comments
 (0)