Document guarantees about BinaryHeap invariant

This commit is contained in:
David Tolnay 2023-01-05 00:04:59 -08:00
parent aedb756020
commit 23501703fb
No known key found for this signature in database
GPG Key ID: F9BA143B95FF6D82

View File

@ -166,12 +166,20 @@ mod tests;
/// It is a logic error for an item to be modified in such a way that the /// It is a logic error for an item to be modified in such a way that the
/// item's ordering relative to any other item, as determined by the [`Ord`] /// item's ordering relative to any other item, as determined by the [`Ord`]
/// trait, changes while it is in the heap. This is normally only possible /// trait, changes while it is in the heap. This is normally only possible
/// through [`Cell`], [`RefCell`], global state, I/O, or unsafe code. The /// through interior mutability, global state, I/O, or unsafe code. The
/// behavior resulting from such a logic error is not specified, but will /// behavior resulting from such a logic error is not specified, but will
/// be encapsulated to the `BinaryHeap` that observed the logic error and not /// be encapsulated to the `BinaryHeap` that observed the logic error and not
/// result in undefined behavior. This could include panics, incorrect results, /// result in undefined behavior. This could include panics, incorrect results,
/// aborts, memory leaks, and non-termination. /// aborts, memory leaks, and non-termination.
/// ///
/// As long as no elements change their relative order while being in the heap
/// as described above, the API of `BinaryHeap` guarantees that the heap
/// invariant remains intact i.e. its methods all behave as documented. For
/// example if a method is documented as iterating in sorted order, that's
/// guaranteed to work as long as elements in the heap have not changed order,
/// even in the presence of closures getting unwinded out of, iterators getting
/// leaked, and similar foolishness.
///
/// # Examples /// # Examples
/// ///
/// ``` /// ```