Document the behaviour of BTreeMap::extend - #158069
Conversation
rustbot
added
S-waiting-on-review
|
r? @joboet rustbot has assigned @joboet. Use Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
|
I added the same docs to |
|
|
||
| #[stable(feature = "rust1", since = "1.0.0")] | ||
| impl<K: Ord, V, A: Allocator + Clone> Extend<(K, V)> for BTreeMap<K, V, A> { | ||
| /// Add all elements from `iter` to this map by calling [`BTreeMap::insert`] |
There was a problem hiding this comment.
I would avoid promising that insert is called since that is an implementation detail that could change. It could say:
Inserts each entry into the map. Existing entries with the same key are replaced.
There was a problem hiding this comment.
It can't change in a way that makes it not semantically equivalent to calling insert. I could say Add all elements from iter to this map, as if insert was called for each element or something... but that seems a bit awkward and pedantic.
I think duplicating the insert documentation is not as good because you lose information. For example with your version you don't get this:
The key is not updated, though; this matters for types that can be == without being identical. See the module-level documentation for more.
It was unclear from the existing documentation how duplicate elements would be handled.
|
Sorry for not getting back sooner. This looks reasonable, but I'll reassign to someone from libs-api just as a cautionary measure. r? libs-api |
rustbot
added
the
T-libs-api
7 participants
It was unclear from the existing documentation how duplicate elements would be handled.
No AI was used for this PR.