Support With<Bundle> rather than just With<Component>

[ItsDoot]

What problem does this solve or what need does it fill?

Now that all Components are Bundles, it seems like this could be done, in theory.
It would potentially reduce Query type complexity:

pub fn my_system(Query<&Name, (With<Foo>, With<Bar>, With<Baz>)>) {}
// vs
pub fn my_system(Query<&Name, With<(Foo, Bar, Baz)>>) {}

What solution would you like?

Implement With<T: Bundle> and Without<T: Bundle>, rather than With<T: Component>.

What alternative(s) have you considered?

Continue to work under status quo.

[IceSentry]

Here's some prior discussion on the subject #2620 and #2252

[alice-i-cecile]

This is definitely feasible, and should be easy to implement.

However, whether it's a good idea is hotly contested. Querying for "all entities with this bundle" is a common pattern in beginners coming from more OOP backgrounds, but tends to push towards less idiomatic, less behavior-first system design.

[fgrust]

I just started contribution to bevy, so my question might be a fool. :)

How to bundle in the following case. or should we skip this case?

pub fn my_system(Query<&Name, (With<Foo>, Without<Bar>)>) {}

[alice-i-cecile]

That wouldn't be able to be expressed using bundles :)

[tguichaoua]

What if instead of With<T: Bundle>, we have With<T: TupleOfComponents>¹?

TupleOfComponents is a marker trait implemented for single component and for tuple where each members is an component.

So With<(A, B, C)> becomes a shortcut for (With<A>, With<B>, With<C>) but With<MyBundle> is still disallowed.

Footnotes

1. There is certainly a better name than TupleOfComponents 😅 ↩

[JMS55]

Agree with With<Bundle> being an anti-pattern. With<(A, B, C)> or With<A, B, C> would be nice though.

[CraigBuilds]

This is definitely feasible, and should be easy to implement.

However, whether it's a good idea is hotly contested. Querying for "all entities with this bundle" is a common pattern in beginners coming from more OOP backgrounds, but tends to push towards less idiomatic, less behavior-first system design.

While this is true, it would still be nice as an option for rapid prototyping or very simple games, where modularity isn't as important. It also might help beginners transition by letting them use a more OOP style approach, and then they can refactor later once they realize they want to share behavior across all entities with specific components.

It should be fairly easy to refactor game code that is written with Bundle Queries, and split it into smaller systems for each component.

[blueforesticarus]

This is definitely feasible, and should be easy to implement.
However, whether it's a good idea is hotly contested. Querying for "all entities with this bundle" is a common pattern in beginners coming from more OOP backgrounds, but tends to push towards less idiomatic, less behavior-first system design.

While this is true, it would still be nice as an option for rapid prototyping or very simple games, where modularity isn't as important. It also might help beginners transition by letting them use a more OOP style approach, and then they can refactor later once they realize they want to share behavior across all entities with specific components.

It should be fairly easy to refactor game code that is written with Bundle Queries, and split it into smaller systems for each component.

I am having trouble thinking of a case where With<Bundle> is useful, since you still need to spell all out the components you need access too. Anytime you might be tempted to do something like With<MonsterBundle> you could almost certainly do With<Monster>, since your entity needs something identifying it as a monster (and if it doesn't then With would be a footgun anyway).

However, if bundle Queries were re-evaluated, then we would also want With<Bundle> for consistency.

[ItsDoot]

Closing out in favor of #15327 as it better centralizes information, arguments, and the context of today.