Tracking Issue for map_many_mut

[Urgau]

Feature gate: #![feature(map_many_mut)]

This is a tracking issue for the HashMap::get_disjoint{,_unchecked}_mut functions (previously get_many_mut and get_many_unchecked_mut).

Attempts to get mutable references to N values in the map at once.

Public API

// in HashMap

pub fn get_disjoint_mut<Q: ?Sized, const N: usize>(
    &mut self,
    ks: [&Q; N]
) -> [Option<&'_ mut V>; N]
where
    K: Borrow<Q>,
    Q: Hash + Eq;

pub unsafe fn get_disjoint_unchecked_mut<Q: ?Sized, const N: usize>(
    &mut self,
    ks: [&Q; N],
) -> [Option<&'_ mut V>; N]
where
    K: Borrow<Q>,
    Q: Hash + Eq;

Steps / History

• Implementation: Expose get_many_mut and get_many_unchecked_mut to HashMap #94647 and Change signature of get_many_mut APIs hashbrown#562
• Final comment period (FCP) Tracking Issue for map_many_mut #97601 (comment)
• Rename to get_disjoint_mut Stabilize map_many_mut feature #136152
• Stabilization PR Stabilize map_many_mut feature #136152

Unresolved Questions

• Should the return type be instead Result<[Option<&mut V>; N], DuplicateKeys>? Tracking Issue for map_many_mut #97601 (comment) and Tracking Issue for map_many_mut #97601 (comment)
  Tracking Issue for map_many_mut #97601 (comment)
• Having instead a entry-like API? Tracking Issue for map_many_mut #97601 (comment)
  Tracking Issue for map_many_mut #97601 (comment)
• Naming
  • map_disjoint_mut, see Tracking Issue for map_many_mut #97601 (comment)

[ibraheemdev]

Would it be better for this to return Result<[Option<&mut V>; N], DuplicateKeys>?

[Urgau]

Would it be better for this to return Result<[Option<&mut V>; N], DuplicateKeys>?

I don't think so, returning a Result<_, DuplicateKeys> would different from any other get methods on HashMap; they all return Option<_> of something; And returning a individual Option for every entry would completely change the semantic of the function and make things more difficult for peoples who wants all or nothing to achieve it.

[Arnavion]

And returning a individual Option for every entry would completely change the semantic of the function and make things more difficult for peoples who wants all or nothing to achieve it.

Sure, but the current implementation makes things more difficult for people who want to do multiple lookups in parallel and then do some mutations based on which keys exist and don't exist.

Returning [Option<&mut>] would not only provide strictly more information, but can be converted to Option<[&mut]> using result.try_map(std::convert::identity) (as suggested by AstrallyForged on IRC).

---

If I follow the history correctly, the libstd implementation returns Option<[&mut]> because hashbrown's does. hashbrown's implementation originally returned [Result<&mut>] but this was then changed to Option<[&mut]> to align with libstd's [T]::get_many_mut. So perhaps we need to start there.

[workingjubilee]

Bikesheddy note: this is very similar to the notion of a "gather" (a la Simd::gather_*) and that term is used extensively in similar interfaces (though it is also called something like "indexed vector load" in some cases).

[forrestli74]

This seems very restrictive on the number of elements at the same time. Would be nice to have a version that supports Vec or Iterator of some sort. We don't have to support the general form now, but should think about how to design the API that adding general form is easy.