#[derive(Query)]

[entropylost]

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

Giant tuples within query (Query<(&Foo, &Bar, &mut Baz)>) is really annoying as then everything has to be referenced by .0, etc, and if I decide to add Entity to the list I have to shift everything.

Describe the solution would you like?

Make a derive macro #[derive(Query)] which implements HecsQuery for the structure in question; as such the structure can be used as a query.

Describe the alternative(s) you've considered?

None.

Additional context

This could also support Or by allowing deriving an enum.

[entropylost]

For example, I have the query Query<(&AI, Entity, &Health, &Transform, &Stats, &Unit)>, which is way too much in my opinion.

[Plecra]

I wonder how much overlap this has with #[derive(Bundle)]. Would it be helpful for the derive to be implemented in a way that allowed you to write this declaration?

#[derive(Bundle, Query)]
struct Enemy {
    behaviour: Ai,
    health: Health,
    transform: Transform,
    extra: Stats,
}

Looks like this has already bene mentioned in #9

[smokku]

Does it make sense to have Entity as a part of the bundle?

[entropylost]

Derive Bundle and derive query wouldn't work; queryies need references not the values.

[Plecra]

I assumed it would be possible to map T to &T... would something prevent that?

[entropylost]

That screws up mutable borrows, and doesn't really make sense (especially as it would have to generate a separate type).

[mvlabat]

@Plecra I think the only way to map T to &T is to introduce a new struct with a derive macro, which name would derive from the original one with some kind of suffix. This could work, but it would be a pain for IDEs and editors to understand this, and as @iMplode-nZ has pointed out, there doesn't seem to be an obvious way to express mutable borrows.

[mvlabat]

I'm also looking forward to seeing this feature in Bevy. Before stumbling upon on this issue, I've created #800 - this feature request covers both components and resources, and might give some additional idea about the motivation for the feature.

[mvlabat]

Does it make sense to have Entity as a part of the bundle?

@smokku, I think it makes perfect sense since Entity is queriable.

[smokku]

It makes sense for Query. My question is about Bundle.

[mvlabat]

@smokku right, I mean that everything that is queriable makes sense to be a part of a bundle. I don't think there's any reason not to support Entity, other than maybe some technical limitations (I don't know if there are any)

[memoryruins]

Ralith/hecs#110 was opened recently to add a #[derive(Query)] in hecs

[tigregalis]

Was this addressed by #798 ?

• SystemParam can now be derived. We now use this for DrawContext instead of a manual impl. You can use any types that impl SystemParam:

  #[derive(SystemParam)]
  struct MyParams<'a> {
    a: Res<'a, A>, 
    b: ResMut<'a, B>,
    commands: &'a mut Commands,
    #[system_param(ignore)]
    hello: bool // this will use Default
  }
  
  fn system(my_params: MyParams) {
    println!("{}", system.a);
  }

Edit: Sorry, never mind. This is for that inner param.

[entropylost]

I would say having it being called Query or HECSQuery is simpler. (maybe bevy_hecs::Query)?
Or alternatively we could just use the hecs derive.

[mvlabat]

Yeah, I'd say it's something worth backporting to bevy_hecs, instead of implementing it inside bevy_ecs