WorldQuery as associated type on trait / using WorldQueryGats

[derivator]

So I have the following code which compiles and works:

use bevy_ecs::prelude::*;
use bevy_ecs::query::{Fetch, WorldQuery, WorldQueryGats};


pub trait Foo: Component {
    /// Components that `FooReader` should query for alongside the one implementing this trait
    type Q: WorldQuery;
    /// Do some computation depending on this component and the components in `Self::Q`
    /// and then mutate `reader`. `data` is conceptually of type `Self::Q`, but
    /// the lifetimes differ because the impl block has no way to spell the correct lifetime.
    /// Introducing a lifetime parameter on `Foo` would allow the impl to specify lifetimes
    /// so that `Self::Q` is identical to the type for `data` spelled out here, but there's no way
    /// to promise to the compiler that all impls will actually do so
    fn read_me<'w>(&self, reader: &mut FooReader, data: <<<Self::Q as WorldQuery>::ReadOnly as WorldQueryGats<'w>>::Fetch as Fetch<'w>>::Item);
}

pub struct FooReader(Vec<u32>);
impl FooReader {
    /// Call `read_me` on all the `T`s and have them mutate this `FooReader`
    fn read_all<T: Foo>(&mut self, world: &World, query: &mut QueryState<(&T, T::Q)>)
    where
        Self: Sized,
    {
        query.for_each(world, |(t, data)| {
            t.read_me(self, data);
        })
    }
}
#[derive(Component)]
pub struct A(u32);
#[derive(Component)]
pub struct B(u32);
#[derive(Component)]
pub struct C(u32);

impl Foo for A {
    // Lifetimes are 'static because there's no way to specify the correct lifetime
    type Q = (&'static B, &'static C); 

    // Lifetime 'w here can actually be elided but I spell it out to show that the lifetimes don't match `Self::Q`
    fn read_me<'w>(&self, reader: &mut FooReader, data: (&'w B, &'w C)) {
        // compute A + B + C, store result in `reader`
        reader.0.push(self.0 + data.0.0 + data.1.0);
    }
}

My question is if this is idiomatic or if there's a better way, and if I'm "allowed" to specify the type of data as <<<Self::Q as WorldQuery>::ReadOnly as WorldQueryGats<'w>>::Fetch as Fetch<'w>>::Item.
By "allowed" I mean, is this expected to work in future releases? The docs for WorldQueryGats only say

A helper trait for WorldQuery that works around Rust’s lack of Generic Associated Types

so I assume if GATS are added to Rust, the API would change, but in general this is an intended use of the public API?

[nicopap]

It's part of the more "advanced" public API, I think it's legitimate to use it. There is a helper type alias called QueryItem which you can take advantage of:

pub type QueryItem<'w, Q> = <<Q as WorldQueryGats<'w>>::Fetch as Fetch<'w>>::Item;

It is likely that bevy will take advantage of GATs as soon as they are stabilized, and change the API. Which is fine, bevy explicitly states that it will make major API breaking changes in the near future.

[tim-blackbird]

There is a type alias for ReadOnly as well: ROQueryItem.

[derivator]

Thanks @nicopap! I was just wondering if something like that exists... I've probably even seen it a couple times in the docs but not really noticed it.
Maybe the docs for WorldQueryGats could mention QueryItem? Because that's where the compiler points you if you try to implement something like this naively, without taking care of the lifetimes.

The bevy docs also get bitten pretty hard by rust-lang/rust#15823, compare the docs for Query::get in bevy_ecs to bevy proper. In the latter, ROQueryItem is expanded to the full messy definition. I don't know if that can be fixed besides fixing the underlying issue though.

[nicopap]

@derivator I can only recommend creating and using a local copy of the doc by running cargo doc in your own game repository. This is not an issue for local docs.

You are right, QueryItem could probably be mentioned in WorldQueryGats.