Skip to content

Commit e7e0dc7

Browse files
committed
reword edge-conditions documentation on all slice 'sort' functions; resolves #130122
1 parent 8c2c9a9 commit e7e0dc7

File tree

1 file changed

+47
-20
lines changed

1 file changed

+47
-20
lines changed

library/alloc/src/slice.rs

+47-20
Original file line numberDiff line numberDiff line change
@@ -180,10 +180,9 @@ 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 implementation of [`Ord`] for `T` does not implement a [total order], the function
184+
/// may panic; even if the function exits normally, the resulting order of elements in the slice
185+
/// is unspecified. See also the note on panicking below.
187186
///
188187
/// When applicable, unstable sorting is preferred because it is generally faster than stable
189188
/// sorting and it doesn't allocate auxiliary memory. See
@@ -212,7 +211,15 @@ impl<T> [T] {
212211
///
213212
/// # Panics
214213
///
215-
/// May panic if the implementation of [`Ord`] for `T` does not implement a [total order].
214+
/// May panic if the implementation of [`Ord`] for `T` does not implement a [total order], or if
215+
/// the [`Ord`] implementation itself panics.
216+
///
217+
/// All safe functions on slices preserve the invariant that even if the function panics, all
218+
/// original elements will remain in the slice and any possible modifications via interior
219+
/// mutability are observed in the input. This ensures that recovery code (for instance inside
220+
/// of a `Drop` or following a `catch_unwind`) will still have access to all the original
221+
/// elements. For instance, if the slice belongs to a `Vec`, the `Vec::drop` method will be able
222+
/// to dispose of all contained elements.
216223
///
217224
/// # Examples
218225
///
@@ -241,10 +248,9 @@ impl<T> [T] {
241248
/// This sort is stable (i.e., does not reorder equal elements) and *O*(*n* \* log(*n*))
242249
/// worst-case.
243250
///
244-
/// If the comparison function `compare` does not implement a [total order] the resulting order
245-
/// of elements in the slice is unspecified. All original elements will remain in the slice and
246-
/// any possible modifications via interior mutability are observed in the input. Same is true
247-
/// if `compare` panics.
251+
/// If the comparison function `compare` does not implement a [total order], the function may
252+
/// panic; even if the function exits normally, the resulting order of elements in the slice is
253+
/// unspecified. See also the note on panicking below.
248254
///
249255
/// For example `|a, b| (a - b).cmp(a)` is a comparison function that is neither transitive nor
250256
/// reflexive nor total, `a < b < c < a` with `a = 1, b = 2, c = 3`. For more information and
@@ -263,7 +269,14 @@ impl<T> [T] {
263269
///
264270
/// # Panics
265271
///
266-
/// May panic if `compare` does not implement a [total order].
272+
/// May panic if `compare` does not implement a [total order], or if `compare` itself panics.
273+
///
274+
/// All safe functions on slices preserve the invariant that even if the function panics, all
275+
/// original elements will remain in the slice and any possible modifications via interior
276+
/// mutability are observed in the input. This ensures that recovery code (for instance inside
277+
/// of a `Drop` or following a `catch_unwind`) will still have access to all the original
278+
/// elements. For instance, if the slice belongs to a `Vec`, the `Vec::drop` method will be able
279+
/// to dispose of all contained elements.
267280
///
268281
/// # Examples
269282
///
@@ -295,10 +308,9 @@ impl<T> [T] {
295308
/// This sort is stable (i.e., does not reorder equal elements) and *O*(*m* \* *n* \* log(*n*))
296309
/// worst-case, where the key function is *O*(*m*).
297310
///
298-
/// If the implementation of [`Ord`] for `K` does not implement a [total order] the resulting
299-
/// order of elements in the slice is unspecified. All original elements will remain in the
300-
/// slice and any possible modifications via interior mutability are observed in the input. Same
301-
/// is true if the implementation of [`Ord`] for `K` panics.
311+
/// If the implementation of [`Ord`] for `K` does not implement a [total order], the function
312+
/// may panic; even if the function exits normally, the resulting order of elements in the slice
313+
/// is unspecified. See also the note on panicking below.
302314
///
303315
/// # Current implementation
304316
///
@@ -313,7 +325,15 @@ impl<T> [T] {
313325
///
314326
/// # Panics
315327
///
316-
/// May panic if the implementation of [`Ord`] for `K` does not implement a [total order].
328+
/// May panic if the implementation of [`Ord`] for `K` does not implement a [total order], or if
329+
/// the [`Ord`] implementation or the key-function `f` panics.
330+
///
331+
/// All safe functions on slices preserve the invariant that even if the function panics, all
332+
/// original elements will remain in the slice and any possible modifications via interior
333+
/// mutability are observed in the input. This ensures that recovery code (for instance inside
334+
/// of a `Drop` or following a `catch_unwind`) will still have access to all the original
335+
/// elements. For instance, if the slice belongs to a `Vec`, the `Vec::drop` method will be able
336+
/// to dispose of all contained elements.
317337
///
318338
/// # Examples
319339
///
@@ -347,10 +367,9 @@ impl<T> [T] {
347367
/// storage to remember the results of key evaluation. The order of calls to the key function is
348368
/// unspecified and may change in future versions of the standard library.
349369
///
350-
/// If the implementation of [`Ord`] for `K` does not implement a [total order] the resulting
351-
/// order of elements in the slice is unspecified. All original elements will remain in the
352-
/// slice and any possible modifications via interior mutability are observed in the input. Same
353-
/// is true if the implementation of [`Ord`] for `K` panics.
370+
/// If the implementation of [`Ord`] for `K` does not implement a [total order], the function
371+
/// may panic; even if the function exits normally, the resulting order of elements in the slice
372+
/// is unspecified. See also the note on panicking below.
354373
///
355374
/// For simple key functions (e.g., functions that are property accesses or basic operations),
356375
/// [`sort_by_key`](slice::sort_by_key) is likely to be faster.
@@ -369,7 +388,15 @@ impl<T> [T] {
369388
///
370389
/// # Panics
371390
///
372-
/// May panic if the implementation of [`Ord`] for `K` does not implement a [total order].
391+
/// May panic if the implementation of [`Ord`] for `K` does not implement a [total order], or if
392+
/// the [`Ord`] implementation panics.
393+
///
394+
/// All safe functions on slices preserve the invariant that even if the function panics, all
395+
/// original elements will remain in the slice and any possible modifications via interior
396+
/// mutability are observed in the input. This ensures that recovery code (for instance inside
397+
/// of a `Drop` or following a `catch_unwind`) will still have access to all the original
398+
/// elements. For instance, if the slice belongs to a `Vec`, the `Vec::drop` method will be able
399+
/// to dispose of all contained elements.
373400
///
374401
/// # Examples
375402
///

0 commit comments

Comments
 (0)