Add immutable map accessors to OccupiedEntry and VacantEntry

[apasel422]

Without these, it is not possible to inspect other keys in the map while deciding how to process the entry, forcing the user to either perform unnecessary work before calling entry or performing multiple map lookups for the entry key.

For example:

fn some_expensive_operation(...) -> bool { ... }

let mut map: HashMap<K, V> = ...;

// old way, with two lookups for `key`
if !map.contains_key(key) && some_expensive_operation(map.get(other_key)) {
    map.insert(key, val);
}

// old way, with expensive operation done unnecessarily when `key` is
// already present
if some_expensive_operation(map.get(other_key)) {
    if let VacantEntry(e) = map.entry(key) {
        e.insert(val);
    }
}

// new way, with one lookup for `key`
if let VacantEntry(e) = map.entry(key) {
  if some_expensive_operation(e.map().get(other_key)) {
    e.insert(val);
  }
}

We do not provide accessors returning a mutable reference to the map because doing so would make it possible to invalidate the entry itself.

[clarfonthey]

This feels sound and reasonable to add, but I'll defer to others on whether that's actually the case.

I would be interested in some more specifics on why you're looking to do this, since this doesn't quite feel like the best way of going about this, but is probably fine. Maybe an entry form of get_many_mut might help.

[apasel422]

Maybe an entry form of get_many_mut might help.

That would be fine too.

I would be interested in some more specifics on why you're looking to do this

While deciding whether to insert a new entry into a map, I need to do as many as four other lookups, each accompanied by some additional, potentially expensive processing on the corresponding values, if they are present at all. Right now I just do two lookups for the to-be-inserted key (contains_key followed by insert) rather than using the entry API due to the inability to access the map (immutably in this case) while an entry is outstanding.

[clarfonthey]

I guess that my confusion lies in why you specifically need the different things being checked to all exist within the map as separate entries, rather than all lumped together in a single entry, if you want to access them all at once.

[Amanieu]

Could these be renamed to hash_map to avoid confusion with the very commonly used map method?

Also I can see a use case for into_hash_map which discards the entry and returns the original mutable reference that the entry was constructed from.

Maybe an entry form of get_many_mut might help.

That won't work since an invariant of the entry API is that only one entry may exist at any time. Otherwise methods on one entry would invalidate the others.

[Amanieu]

Also could you add these to:

• Entry, EntryRef, VacantEntryRef
• The entry types for HashSet and HashTable.

[apasel422]

• The entry types for HashSet and HashTable.

Is it possible to do this for HashSet without unsafe? hash_set::OccupiedEntry has a reference to hash_map::OccupiedEntry, but HashSet isn't just a type alias for HashMap.

[Amanieu]

Actually the API as it is will certainly cause problems in the future when we want to rewrite HashMap on top of HashTable for the same reason we can't support HashSet directly: HashTable's ExtractIf can only provide a reference to the HashTable.

Perhaps the API could be re-considered: instead of a returning a reference the the map, there could be a method which explicitly performs a lookup.

[apasel422]

Perhaps the API could be re-considered: instead of a returning a reference the the map, there could be a method which explicitly performs a lookup.

This makes sense, though it's unfortunate that each method of interest would have to be explicitly exposed here. I will update this PR with that approach shortly, exposing only get for now.