Named Queries

[lizelive]

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

The most simple of systems require a lot of ugly boiler plate code such as:

1. a for loop
2. destructing operations
3. hard to read queries
4. hard to debug

What solution would you like?

#[derive(Query)]
pub struct PointMassQuery{
    position: &mut Position,
    momentum: &Momentum,
    mass: &Mass
}

pub fn newtons_first_law(point_mass: PointMassQuerry, time: Res<Time>) {
    point_mass.position += time.delta_seconds() * point_mass.momentum / point_mass.mass;
}

fn system_with_queryable(q: Query<PointMassQuery>) {}

What alternative(s) have you considered?

#2252 but that requires all param to be mutable to be useful. it is possible to make a macro to generate an all inclusive named query for early development to address this use case.
The old school for-each sytanx but that is not very flexible

Additional context

Figuring this out will make the relation system way cleaner and more usable.

[cart]

I think this is actually multiple orthogonal requests:

Named Queries

Named queries are already possible in a number of ways:

Type Aliases

pub type PointMassFetch<'a> = (&'a mut Position, &'a Momentum, &'a Mass);
fn newtons_first_law(query: Query<PointMassFetch>, time: Res<Time>) {
}

pub type PointMassQuery<'a> = Query<'a, 'a, (&'a mut Position, &'a Momentum, &'a Mass)>;
fn newtons_first_law(query: PointMassQuery, time: Res<Time>) {
}

We are also currently experimenting with "lifetimeless fetch impls" in the new renderer, which would look like this:

pub type PointMassFetch = (Write<Position>, Read<Momentum>, Read<Mass>);
fn newtons_first_law(query: Query<PointMassFetch>, time: Res<Time>) {
}

SystemParam derives

#[derive(SystemParam)]
struct PointMassQuery<'a> {
    query: Query<(&'a mut Position, &'a Momentum, &'a Mass)>,
}

Fetch Derives

Some people would prefer to access query results with pre-defined field names instead of typing them out on the "left hand side" in the returned tuple. This is a relatively straightforward derive impl.

#[derive(Fetch)]
pub struct PointMassFetch {
    position: &mut Position,
    momentum: &Momentum,
    mass: &Mass
}


pub fn newtons_first_law(point_mass: Query<PointMassFetch>, time: Res<Time>) {
}

Single-entity "for-each" systems

Bring back for-each systems by allowing Fetch alongside system parameters. This will be a divisive topic (that deserves its own issue) because they were removed (for good reasons) in #798.

[Nilirad]

We are also currently experimenting with "lifetimeless fetch impls" in the new renderer, which would look like this:

pub type PointMassFetch = (Write<Position>, Read<Momentum>, Read<Mass>);
fn newtons_first_law(query: Query<PointMassFetch>, time: Res<Time>) {
}

Would it be virtually possible to have a Removed<T> fetch such that it retrieves a component that has just been removed? I think it could be the best solution for #2148.

[tigregalis]

I think this is actually multiple orthogonal requests:

Named Queries

Fetch Derives

This really needs to be documented in the book. Is it documented in the book?

[Nilirad]

@tigregalis I gave a glance at the WIP new book and it looks that named queries are not currently documented. @alice-i-cecile what do you think about adding query type aliases and/or #[derive(SystemParam)] as patterns for named queries?

Fetch derives are not merged yet, but they can also be documented somewhere once they are.

[alice-i-cecile]

Yep, I'm on board with mentioning those in the ECS chapter! Feel free to leave a note on that PR; or make a PR to my branch to add them.