-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking Issue for map_many_mut #97601
Comments
Would it be better for this to return |
I don't think so, returning a |
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 If I follow the history correctly, the libstd implementation returns |
Use get_many_mut to reduce the cost of setting up check cfg values This PR use the newly added [`get_many_mut`](rust-lang#97601) function in [`HashMap`](https://doc.rust-lang.org/nightly/std/collections/hash_map/struct.HashMap.html#method.get_many_mut) to reduce the cost of setting up the initial check cfg values. cc `@petrochenkov`
Bikesheddy note: this is very similar to the notion of a "gather" (a la |
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. |
Are there any performance benefits to this other than eliminating a for loop caller-side? Can someone explain the motivation or a use-case for this, given that the code this replaces is rather short and to-the-point? |
@mqudsi It's currently impossible in safe code to get simultaneous mutable references to different values in a |
What about BTreeMap ? Would it be possible to have |
Can it be done at all? |
Rather than returning references to values, could this be an entry-based API instead? That would forgo the questions about people wanting to potentially make multiple lookups without them necessarily failing if some of them are missing. The current proposed function could easily be built on top of an entry-based API, but vice-versa is not possible. |
Does it work to have multiple |
Store programs in a `hashbrown::HashMap` and expose `get_many_mut`. We can revisit this dependency when rust-lang/rust#97601 is resolved.
I implemented a similar thing in this pull request: rust-lang/hashbrown#408 |
I don't see how that does what was requested. As far as I can tell based on that PR, your changes still require a |
I assume they are waiting for this to reach stable for HashMaps before bringing it to BTreeMap. But if you just want something that works https://github.com/DrAlta/rust_quality_of_life.git implements .get_many_mut() for BTreeMap in the GetManyMut trait Thou it doesn't go poking around the innards of the BTreeMap it just iters over it and returns the wanted bits. |
Feature gate:
#![feature(map_many_mut)]
This is a tracking issue for the
HashMap::get_many{,_unchecked}_mut
functions.Attempts to get mutable references to
N
values in the map at once.Public API
Steps / History
get_many_mut
andget_many_unchecked_mut
to HashMap #94647Unresolved Questions
Result<[Option<&mut V>; N], DuplicateKeys>
? Tracking Issue for map_many_mut #97601 (comment) and Tracking Issue for map_many_mut #97601 (comment)The text was updated successfully, but these errors were encountered: