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.

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.

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

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> {}

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)?

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.