Replace try_query

[ElliottjPierce]

Objective

Readonly queries should not need to mutate a world, not even to initialize it. Currently the try_query api exists to remedy this, but it requires all component ids, etc to be created ahead of time. This is not idea.

Solution

Make all WorldQuery just take &World to initialize. Now instead of needing try_query, users can just call query.

Testing

No new tests were added, though the existing ones did catch some bugs.

Migration Guide

WorldQuery::init_state now takes &World instead of &mut World. Additionally, it is now explicitly unsafe to rely on "magic" values in WorldQuery::init_state. For example, queries can no longer access resources or entities during initialization. This was possible before but was an anti-pattern since it tied the query results to when the query was created instead of when it is queried.

Additionally, Bundle::get_component_ids now takes ComponentsQueuedRegistrator instead of &Components and outputs ComponentIds instead of Option<ComponentId>.

[Victoronz]

I agree that that &mut World parameter is bad, but how does this PR avoid the same issue #13442 ran into?
This will break bevy-trait-query, which was deemed bad enough for that aforementioned change to be reverted in #13804.
This was tracked in issue #13358 (not sure why this was closed).

[ElliottjPierce]

I agree that that &mut World parameter is bad, but how does this PR avoid the same issue #13442 ran into? This will break bevy-trait-query, which was deemed bad enough for that aforementioned change to be reverted in #13804. This was tracked in issue #13358 (not sure why this was closed).

I didn't realize that. Yikes. Looking at the source, I think bevy-trait-query could still work here with some statics. The path where it is initialized is already marked as cold, so I doubt moving from a resource to a static would hurt performance.
But I just glanced at it. @RobWalt (bevy-trait-query author), do you think you can still make your crate work with this change? If not, we should definitely hold off here.

If we can't make this work with bevy-trait-query, we'll need to delay until components as entities and in house trait queries are implemented.

[Victoronz]

Note that bevy-trait-query is no longer the only user.
#16810 has adopted this pattern too, and #16843 enabled registering resource access to allow that to be sound.

I think removing the &mut World parameter will still be possible and desirable, but has to wait on proper Resources-as-Entities, was the conclusion when this matter was last discussed AFAIK.

[ElliottjPierce]

Note that bevy-trait-query is no longer the only user. #16810 has adopted this pattern too, and #16843 enabled registering resource access to allow that to be sound.

Yeah, using resources in fetch is fine. We just don't insert them on init_state. All this really does IMO is loose some ergonomics. Users have to add the resource manually, but then everything works fine.

I think removing the &mut World parameter will still be possible and desirable, but has to wait on proper Resources-as-Entities, was the conclusion when this matter was last discussed AFAIK.

Ok. I don't mind waiting for that, and components as entities, etc. This was supper easy to do, so revisiting it shouldn't be a problem.

I'm still convinced we can do this now, with pretty much no cost, but I understand the argument for holding off. I'll leave the timing here up to y'all.