Allow filters to take a `Bundle` instead of a singular `Component`, and make the conjunction behavior configurable

[ItsDoot]

• This issue exists as an evolution of the context surrounding Support With<Bundle> rather than just With<Component> #9215

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

With the merging of #14791, bevy itself is moving away from the usage of Bundle structs as a means of adding many components to an entity at once, and recommends (but doesn't require that) ecosystem crates follow suit. Therefore, Bundles are more free to be used in other cases with less of a worry about introducing footguns, since they are being phased out from common usage (but not completely removed).

The most immediate helpful place Bundles would find usage in is filters:

// Why should we have to write all of this:
Query<Entity, (With<A>, With<B>, With<C>)>
// When we should be able to write this:
Query<Entity, With<(A, B, C)>>

// And if we need to `OR` them:
Query<Entity, Or<(With<A>, With<B>, With<C>)>>
// We should be able to do:
Query<Entity, With<(A, B, C), Any>>

What solution would you like?

These filters:

struct With<T: Component>;
struct Without<T: Component>;
struct Changed<T: Component>;
struct Added<T: Component>;

Become:

struct With<B: Bundle, Join = All>;
struct Without<B: Bundle, Join = All>;
struct Changed<B: Bundle, Join = All>;
struct Added<B: Bundle, Join = All>;

The additional Join generic parameter specifies how the tuple conjunction is performed:

• All: With<(A, B, C), All> means With<A> AND With<B> AND With<C>
• Any: With<(A, B, C), Any> means With<A> OR With<B> OR With<C>

We should determine if the default conjunction for Without should be Any instead of All.

Note: std::any::Any already exists. We should try to find an alternative naming scheme that doesn't clash with std types or pre-existing bevy types, but we may have to resort to doing so anyways if no better alternative is found.

What alternative(s) have you considered?

Bundle tuples only

To reduce controversy, #9255 proposed implementing With<B: Bundle> and other filters only for Bundles made of tuples. I believe this to no longer be necessary as Bundles are being phased out in favor of required components, so it's believed that developers will have less of a draw towards thinking in terms of Bundles (which would have been a poor-man's way of doing OOP).

Conjunction-first

Previously suggested is a flipping of the filter type and conjunction type:

Any<(A, B, C), With>
Any<(A, B, C), Without>
All<(A, B, C), With>
// ...

However that ran into issues with HKTs (higher kinded types), and is verbose in the single-component case.

Additional context

• Issue where it was originally removed: Anti-feature request: remove WithBundle #2620
• Related issue regarding bundles in queries: Component Bundle Queries #2252
• Previous issue: Support With<Bundle> rather than just With<Component> #9215
• PR originating from previous issue: Shortcut for With and Without #9255
• Recent discussion on discord

[ItsDoot]

I expect this still to be controversial, but hopefully less so within the context we have today, and with (hopefully) all information centralized.

[tguichaoua]

I pretty like the idea of having a join mode on the filters to choose between "and" and "or".
But I think it's regretable we loose the fluent syntax with With<(A, B, C), All>.

What about having the join mode before the tuple ?

• Filter<T> for single component (the current behaviour of filters)
• Filter<AllOf, (A, B, C)> for A and B and C
• Filter<AnyOf, (A, B, C)> for A or B or C

With this fluent syntax we can "translate" With<AllOf, (A, B, C)> as "with all of A and B and C" or With<AnyOf, (A, B, C)> as "with any of A or B or C".

I make a POC here.

---

When you're saying "bundle" you mean structures that implement Bundle or tuples of components ?
Because if I understand correctly #14437, bundle structures are about to be deprecated.

[iiYese]

Having the conjunction as the first param makes the trivial case (single component) more verbose & is a breaking change. You can't do what you're suggesting because that requires specialization or negative trait bounds. Bundles aren't going to be deprecated at most they're going to be repurposed.

[tguichaoua]

Having the conjunction as the first param makes the trivial case (single component) more verbose & is a breaking change.

I want to keep Filter<T> for the single component case.

You can't do what you're suggesting because that requires specialization or negative trait bounds.

I don't get where specialization or negative bounds are needed. If you look at the POC, only one parameter of the filter is generic and the other one is fixed.

[iiYese]

I don't get where specialization or negative bounds are needed

Ah ok you don't need it if you just have impls for each conjecture instead of a trait for conjectures. That would work & it wouldn't break existing filters.

[13ros27]

Another possible way of configuring the conjunction behaviour could be With<AnyOf<(C1, C2)>>? This saves the issue of collision with core::any::Any and instead just reuses the existing AnyOf filter. I guess if it was decided Without defaults to AnyOf then we would also need a new AllOf type. I think this is also potentially clearer because it reads left to right as With any of C1 or C2.

As an aside I'm not sure this will work to take a Bundle (although taking Component tuples is definitely nice to have) because it would need IS_DENSE so would have to either add more information to Bundle or take a super trait, but it would also then have to use Vec<ComponentId> for its State, even in cases where it could be just a ComponentId or [ComponentId; 2].