Shortcut for With and Without

[tguichaoua]

Objective

• Closes Support With<Bundle> rather than just With<Component> #9215

This PR implements a proposition to make With<(A, B, C)> and Without<(A, B, C)> a shortcut for (With<A>, With<B>, With<C>) and (Without<A>, Without<B>, Without<C>) to help reduce verbosity of queries.

With<Bundle> or Without<Bundle> are still disallowed as it's considered an anti-pattern.

Solution

Implements WorldQuery and ReadOnlyWorldQuery for Filter<(T0, T1, ...)> that delegate to <(Fitler<T0>, Filter<T1>, ...) as WorldQuery>, where Filter is With or Without.

---

Changelog

• Query filters like (With<A>, With<B>, With<C>) and (Without<A>, Without<B>, Without<C>) can be simplified into With<(A, B, C)> and Without<(A, B, C)> respectively.

[joseph-gio]

Code looks good to me.

This is a welcome addition -- I've always found it surprising that this didn't work already, it just feels natural to be able to filter multiple components at once like this.

[james7132]

This PR implements a proposition to make With<(A, B, C)> and Without<(A, B, C)> a shortcut for (With<A>, With<B>, With<C>) and (Without<A>, Without<B>, Without<C>) to help reduce verbosity of queries.

From my perspective, this would introduce inconsistent behavior in the Without case. In both the normal query and With cases, (A, B, C) means A AND B AND C, while Without<(A, B, C)> translates to NOT A AND NOT B AND NOT C instead of NOT (A AND B AND C). Applying De Morgan's law, Without<(A, B, C)> actually translates to Or<(Without<A>, Without<B>, Without<C>)>.

[james7132]

This macro and the two invocations adds yet another set of tuple pyramids, which can add a lot of additional code to compile. Can you check the difference in compile time for bevy_ecs before and after this change?

[tguichaoua]

With the changes, bevy_ecs took about half a second longer to compile.

rustc 1.71.0 (8ede3aae2 2023-07-12)
Host: x86_64-pc-windows-msvc
Target: x86_64-pc-windows-msvc

[tguichaoua]

This PR implements a proposition to make With<(A, B, C)> and Without<(A, B, C)> a shortcut for (With<A>, With<B>, With<C>) and (Without<A>, Without<B>, Without<C>) to help reduce verbosity of queries.

From my perspective, this would introduce inconsistent behavior in the Without case. In both the normal query and With cases, (A, B, C) means A AND B AND C, while Without<(A, B, C)> translates to NOT A AND NOT B AND NOT C instead of NOT (A AND B AND C). Applying De Morgan's law, Without<(A, B, C)> actually translates to Or<(Without<A>, Without<B>, Without<C>)>.

In terms of logic and since Without<T> is defined as Not<With<T>>, you're right.

But if we break this relation between Without<T> and With<T>, and we consider them as two different filters, we gains:

• consistency : for every Filter<T>, Filter<(A, B, C)> is a shortcut for (Filter<A>, Filter<B>, Filter<C>);
• ergonomy :
  • With<(A, B, C)> means "It contains all of A, B and C"
  • Without<(A, B, C)> means "It contains none of A, B or C"¹ (which is expressed as (Without<A>, Without<B>, Without<C>))

The only thing lost is that With<T> and Without<T> are complementary.
Are there use cases where this complementarity is used?

Without implementation comparison

let mut world = World::new();

let e1 = world.spawn(A(0)).id();
let e2 = world.spawn((A(0), B(0))).id();
let e3 = world.spawn((B(0), C(0))).id();
let e4 = world.spawn((A(0), B(0), C(0))).id();
let e5 = world.spawn((C(0), D(0))).id();

let with_a_b = world
    .query_filtered::<Entity, (With<A>, With<B>)>()
    .iter(&world)
    .collect::<HashSet<Entity>>();

let without_a_and_b = world
    .query_filtered::<Entity, (Without<A>, Without<B>)>()
    .iter(&world)
    .collect::<HashSet<Entity>>();

let without_a_or_b = world
    .query_filtered::<Entity, Or<(Without<A>, Without<B>)>>()
    .iter(&world)
    .collect::<HashSet<Entity>>();

assert_eq!(with_a_b, HashSet::from([e2, e4]));            // entities with both `A` and `B`
assert_eq!(without_a_and_b, HashSet::from([e5]));         // entities with none of `A` nor `B`
assert_eq!(without_a_or_b, HashSet::from([e1, e3, e5])); // entities that are not in `with_a_b` (complementarity)

Footnotes

1. this is just a personal feeling on how to translate Without<(A, B, C)> in plain text, any feedback is welcome. ↩

[tguichaoua]

I think CI is broken, it fails with the message

 method `clone_fetch` is not a member of trait `WorldQuery`

My last commit update the test function only. There is no reason for my previous commit to pass but not this one.

Also, I can build locally.

[Selene-Amanita]

I think it could be both argued that:

1. Without<(A,B)> would stand for Without<A>, Without<B> (current behavior of the PR), because you have two without in the filter tuple, you simply want to combine them into one, and that's the most common use case
2. Without<(A,B)> would stand for Or<(Without<A>, Without<B>)> because that the logical way of applying not(A and B), so that's what you would expect if you think about the coma as an "and", and also it would make more sense to simplify this notation rather than the notation in 1. because it's longer.

I see three options:

• we just allow to put a tuple in With, not Without
• we choose 1. or 2., I think personally it would make more sense to take 1.
• we separate without into:
  • Without that can not be used with a tuple inside
  • WithoutAny with 2. behavior
  • WithoutAll with 1. behavior (or WithNone)

With the third option we could also similarly have WithAny and WithAll. All of those could also be named:

• Any for WithAny
• All for WithAll
• None for WithoutAll
• NotAll for WithoutAny

I would be more in favor of this last option, and this last naming convention

[iiYese]

Applying De Morgan's law, Without<(A, B, C)> actually translates to Or<(Without<A>, Without<B>, Without<C>)>.

I don't see this as being the case. IMO With and Without with this change should be viewed as predicate functions that take a variable number of arguments. Ie. this PR has the most correct, expected and consistent behavior. Boolean algebra isn't applicable here.

This idea of using tuples to create var args is also in line with how it's used everywhere else in bevy.

EDIT:
After thinking about it more the problem here is that there aren't distinct mechanisms for expressing var args and logical AND which is unique to filters because () is implicitly AND. The question here is not "is this correct or is this correct". The question is does this mean var args? Or does this mean AND?

Making () be AND was a mistake and this discussion goes away in the presence of an explicit And<(...)> combinator. In Queries, Bundles, SystemsConfigs, etc. tuples just mean multiple items and do not have special meaning.

[maniwani]

Applying De Morgan's law, Without<(A, B, C)> actually translates to Or<(Without<A>, Without<B>, Without<C>)>.

Yeah, I first thought Without<(A, B, C)> meant "without any of A, B, C".

IMO With and Without with this change should be viewed as predicate functions that take a variable number of arguments. i.e. this PR has the most correct, expected and consistent behavior. Boolean algebra isn't applicable here.

It does apply. This shortcut to reduce "boilerplate" breaks predictable assumptions some users will make. We could decide to stop trying to apply boolean algebra if we think this shortcut is useful enough to outweigh that, but we still need to decide that first.

If this change goes through, subtle logic bugs that were not possible before will be. I think lots of users will confuse Without<(A, B)> and Or(Without<A>, Without<B>) even if we boldly highlight it in the docs.

(edit: I'm not sure how I feel about this. I think I'd prefer not making this change, but I don't have a strong opinion on it.)

Making tuples mean AND was a mistake.

🤔 I could get behind an explicit And. It feels weird to have Or but not And.

[B-Reif]

I’m in favor of deprecating the use of implicit-AND tuples and moving toward explicit And (as in #9347).

[iiYese]

Another option:

• Add Any<Bundle, Pred> + All<Bundle, Pred> APIs.

  // Has all
  All<(A, B, C), With>
  // Does not have atleast one of
  Any<(A, B, C), Without>
  // At least one of these were changed
  Any<(A, B, C), Changed>

• Keep implicit AND.
  ECS is very like prolog and I think leaning into that would be best. This is already the case and will become even more obvious when we add entity relations. It also makes for the most universal way to reason about everything mentioned in Make logical AND explicit in filters with an And<(..)> combinator #9347.

[janhohenheim]

Note from the future: variable tuple args mean OR in triggers now.

[BenjaminBrienen]

Mentioned issue is closed, 2 years old/stale PR, merge conflicts