Skip to content

Commit 2350170

Browse files
committed
Document guarantees about BinaryHeap invariant
1 parent aedb756 commit 2350170

File tree

1 file changed

+9
-1
lines changed
  • library/alloc/src/collections/binary_heap

1 file changed

+9
-1
lines changed

library/alloc/src/collections/binary_heap/mod.rs

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

0 commit comments

Comments
 (0)