Skip to content

Commit dab7935

Browse files
committed
reword 'sort-by' edge-conditions documentation; resolves #130122
1 parent 8c2c9a9 commit dab7935

File tree

1 file changed

+9
-4
lines changed

1 file changed

+9
-4
lines changed

library/alloc/src/slice.rs

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

0 commit comments

Comments
 (0)