What problem does this solve or what need does it fill?
When working with queries, you sometimes need to access the data on multiple components at once. This is particularly frustrating if you require mutable access, due to Rust's borrow checking rules.
What solution would you like?
Add the Query::get_multiple(entities: HashSet<Entity>) -> HashMap<Entity, Result<[Elided](https://docs.rs/bevy/0.5.0/bevy/ecs/system/struct.Query.html#method.get_mut)>> method and the associated get_multiple_mut. By passing in a HashSet of entities, we can ensure that we never have mutable access to the entities at the same time.
Also add get_component analogues for this pattern.
What alternative(s) have you considered?
iter_combinations solves the common case, but other more bespoke access patterns certainly exist.
You can work around this by storing data, but that only works for Clone components.
@TheRawMeatball felt this should use a different API / impl:
it'd be more like a wrapper you put the query into
and then it'd pass out smart pointers wrappers of smart pointers
Additional context
#1470 may be easier to work around with this style of API.
It may make sense to use this implementation for iter_combinations in some way, but be mindful of perf as iter_combinations is likely to be used in tight loops for things like collision detection.
What problem does this solve or what need does it fill?
When working with queries, you sometimes need to access the data on multiple components at once. This is particularly frustrating if you require mutable access, due to Rust's borrow checking rules.
What solution would you like?
Add the
Query::get_multiple(entities: HashSet<Entity>) -> HashMap<Entity, Result<[Elided](https://docs.rs/bevy/0.5.0/bevy/ecs/system/struct.Query.html#method.get_mut)>>method and the associatedget_multiple_mut. By passing in a HashSet of entities, we can ensure that we never have mutable access to the entities at the same time.Also add
get_componentanalogues for this pattern.What alternative(s) have you considered?
iter_combinationssolves the common case, but other more bespoke access patterns certainly exist.You can work around this by storing data, but that only works for
Clonecomponents.@TheRawMeatball felt this should use a different API / impl:
Additional context
#1470 may be easier to work around with this style of API.
It may make sense to use this implementation for
iter_combinationsin some way, but be mindful of perf as iter_combinations is likely to be used in tight loops for things like collision detection.