|
78 | 78 | //! * You want a bit vector.
|
79 | 79 | //!
|
80 | 80 | //! ### Use a `BitSet` when:
|
81 |
| -//! * You want a `VecSet`. |
| 81 | +//! * You want a `BitVec`, but want `Set` properties |
82 | 82 | //!
|
83 | 83 | //! ### Use a `BinaryHeap` when:
|
84 | 84 | //! * You want to store a bunch of elements, but only ever want to process the "biggest"
|
|
89 | 89 | //!
|
90 | 90 | //! Choosing the right collection for the job requires an understanding of what each collection
|
91 | 91 | //! is good at. Here we briefly summarize the performance of different collections for certain
|
92 |
| -//! important operations. For further details, see each type's documentation. |
| 92 | +//! important operations. For further details, see each type's documentation, and note that the |
| 93 | +//! names of actual methods may differ from the tables below on certain collections. |
93 | 94 | //!
|
94 | 95 | //! Throughout the documentation, we will follow a few conventions. For all operations,
|
95 | 96 | //! the collection's size is denoted by n. If another collection is involved in the operation, it
|
|
280 | 281 | //! a variant of the `Entry` enum.
|
281 | 282 | //!
|
282 | 283 | //! If a `Vacant(entry)` is yielded, then the key *was not* found. In this case the
|
283 |
| -//! only valid operation is to `set` the value of the entry. When this is done, |
| 284 | +//! only valid operation is to `insert` a value into the entry. When this is done, |
284 | 285 | //! the vacant entry is consumed and converted into a mutable reference to the
|
285 | 286 | //! the value that was inserted. This allows for further manipulation of the value
|
286 | 287 | //! beyond the lifetime of the search itself. This is useful if complex logic needs to
|
287 | 288 | //! be performed on the value regardless of whether the value was just inserted.
|
288 | 289 | //!
|
289 | 290 | //! If an `Occupied(entry)` is yielded, then the key *was* found. In this case, the user
|
290 |
| -//! has several options: they can `get`, `set`, or `take` the value of the occupied |
| 291 | +//! has several options: they can `get`, `insert`, or `remove` the value of the occupied |
291 | 292 | //! entry. Additionally, they can convert the occupied entry into a mutable reference
|
292 |
| -//! to its value, providing symmetry to the vacant `set` case. |
| 293 | +//! to its value, providing symmetry to the vacant `insert` case. |
293 | 294 | //!
|
294 | 295 | //! ### Examples
|
295 | 296 | //!
|
|
329 | 330 | //! use std::collections::btree_map::{BTreeMap, Entry};
|
330 | 331 | //!
|
331 | 332 | //! // A client of the bar. They have an id and a blood alcohol level.
|
332 |
| -//! struct Person { id: u32, blood_alcohol: f32 }; |
| 333 | +//! struct Person { id: u32, blood_alcohol: f32 } |
333 | 334 | //!
|
334 | 335 | //! // All the orders made to the bar, by client id.
|
335 | 336 | //! let orders = vec![1,2,1,2,3,4,1,2,2,3,4,1,1,1];
|
|
0 commit comments