EntityQuery in idiomatic foreach

[frank lodge]

I often find myself wanting to use an EntityQuery in the idiomatic foreach Query, both as a way to step down into using it—similar to the transition to IJobEntity and then IJobChunk—but also to use certain elements that the query has, like IsEmpty, while not losing the high level code that the foreach gives you.

Is this on the radar, and if so, is anything coming to this effect?

[potent mulch]

No future plans, however would love to hear your thoughts on how such an API could look? 😄

[frank lodge]

That, I am unsure about. Because I understand that the foreach API does use generics to enforce the foreach element to match the query, (and even make it nicely codable) but passing an EntityQuery like:

foreach((A a, B b, C c) in SystemAPI.Query(_query))

Doesn't... there's nothing that binds one to the other.

Once an EntityQuery is created there's nothing that ties it to its members as far as the type system is concerned, eg. ToComponentDataArray<T> can throw exceptions if the T isn't in there.
So I honestly have no clue about how to do it, but it's something I want to do fairly often!

It would certainly be nice if generics could be inferred better and you didn't have to specify so much on the right hand side of a statement when there's multiple arguments 😦

[frank lodge]

My main use case is:
I want to use a simple query and there is an EntityCommandBuffer or something similar that I don't want to allocate if that query is not iterated.
I can't check whether the query is empty without creating a whole EntityQuery, and if I do that then it's no longer simple.

I think something like this would be great:

[BurstCompile]
public void OnUpdate(ref SystemState state)
{
    QueryEnumerableWithEntity<A,B,C> query = SystemAPI.Query<A, B, C>().WithEntityAccess();

    if (query.IsEmpty)
        return;

    EntityCommandBuffer ecb = new(Allocator.Temp);

    foreach ((A, B, C, Entity) example in query)
    {
        ecb.DoThing();
    }
    
    ecb.Playback(state.EntityManager);
}

So I probably came at it from the wrong direction when I said EntityQuery, it's probably more about having a more flexible and extensive API related to QueryEnumerable. Noting that I have no idea the kind of pain there is with the codegen, but the above example seems a small departure from what's currently there in comparison to my original thought.

[potent mulch]

Thx that's great feedback! 😄