Signature of OccupiedEntry::insert

[dtolnay]

• OccupiedEntry::insert for HashMap
• OccupiedEntry::insert for BTreeMap
• OccupiedEntry::insert for LInkedHashMap
• OccupiedEntry::insert for IndexMap

The first three all take &mut self while indexmap takes self by value. Is this intentional? I found this makes it complicated for a library to multiplex across different choices of underlying map type: serde-rs/json#418.

My workaround is:

mem::replace(occupied_entry.get_mut(), value)

[cuviper]

Seems like something we should fix. Most of the API tries to be consistent with HashMap, and I don't see a reason why this would need an exception.

[bluss]

@dtolnay thanks a lot for catching this before our 1.0