`Entry`-style APIs for `Query`

[alice-i-cecile]

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

It is common to need to write code which operates on a component, or adds it if it exists.

Because of this, we have a wonderful (and under-appreciated) method: [EntityWorldMut::entry]. This mirrors the standard Rust convention: similarly methods exist on HashMap for example.

What solution would you like?

Entry<C: Component> QueryData type

This type would return an Entry-style wrapper over a Mut<C>. This could be converted to a Mut<C> (or a eldritch equivalent) using methods like .or_default(), allowing you to operate on the data as if it was always there.

In order for this to work smoothly, we need to somehow actually send the command to spawn / insert the data you just mutated after the system concludes. I think a Drop impl might be able to do the trick, although a persistent mutable reference to the command data inside of EntityCommands stored inside of the contained Query might work too, albeit with some level of pain due to the borrow checker.

What alternative(s) have you considered?

Leave it alone: you can just write branching code and take both Query and Commands.

Additional context

This was originally proposed by @ecoskey on Discord.

[urben1680]

Prior attempt: #19602

[Person-93]

In order for this to work smoothly, we need to somehow actually send the command to spawn / insert the data you just mutated after the system concludes. I think a Drop impl might be able to do the trick, although a persistent mutable reference to the command data inside of EntityCommands stored inside of the contained Query might work too, albeit with some level of pain due to the borrow checker.

Can the query insert the new components in its own implementation of SystemParam? It looks like the previous attempt was doing this.