Rename Q type parameter to D when referring to WorldQueryData

[Nilirad]

Objective

Since #10776 split WorldQuery to WorldQueryData and WorldQueryFilter, it should be clear that the query is actually composed of two parts. It is not factually correct to call "query" only the data part. Therefore I suggest to rename the Q parameter to D in Query and related items.

As far as I know, there shouldn't be breaking changes from renaming generic type parameters.

Solution

I used a combination of rust-analyzer go to reference and Ctrl-Fing various patterns to catch as many cases as possible. Hopefully I got them all. Feel free to check if you're concerned of me having missed some.

Notes

This and #10779 have many lines in common, so merging one will cause a lot of merge conflicts to the other.

[ItsDoot]

I would even go as far as to recommend using full Data and Filter names for the generic parameters, at least on the Query struct definition: pub struct Query<Data, Filter> {} to make it abundantly clear what each of them mean.

[Nilirad]

I would even go as far as to recommend using full Data and Filter names for the generic parameters, at least on the Query struct definition: pub struct Query<Data, Filter> {} to make it abundantly clear what each of them mean.

Honestly, I would too, however the convention at the moment is single letter naming.

[alice-i-cecile]

I'm in favor of this direction. I think we should merge the other PR first though, since it's publicly breaking.

[rlidwka]

Honestly, I would too, however the convention at the moment is single letter naming.

Always prefer readability over conventions.

impl<Marker, In, F> Condition<Marker, In> for F {}
impl<A, B, Func> ReadOnlySystem for CombinatorSystem {}
impl<Input, Out, Func: Send + Sync + 'static> ExclusiveSystemParamFunction for Func {}
impl<Param: SystemParam> SystemState<Param> {}

[Nilirad]

Honestly, I would too, however the convention at the moment is single letter naming.

Always prefer readability over conventions.

impl<Marker, In, F> Condition<Marker, In> for F {}
impl<A, B, Func> ReadOnlySystem for CombinatorSystem {}
impl<Input, Out, Func: Send + Sync + 'static> ExclusiveSystemParamFunction for Func {}
impl<Param: SystemParam> SystemState<Param> {}

That's more common than I thought. What do you think @alice-i-cecile? Should we go right now with full names for type parameters (Data and Filter)?

[alice-i-cecile]

I think we should stick to D and F for now to reduce controversiality. I suspect that the docs / type signatures will be much clearer now that we have good supertraits with clear names.