@@ -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 method 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 method 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 method 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 method 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