Iterate ALL Entities in world (get EntityRef/EntityMut)

[Moulberry]

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

There are cases where direct access to EntityRef/EntityMut is needed in an iterating context

What solution would you like?

An archetype-based solution, ideally we could have a &EntityRef or &mut EntityMut in queries, which would automatically imply exclusive world access thinking. (#5496 (comment))

What alternative(s) have you considered?

Iterating Entity (the ID) and calling World::entity. This solution works, but it is unintuitive and suffers from worse performance than a built-in solution for iterating EntityRef/EntityMut

Additional context

Original discussion: #5496

[alice-i-cecile]

Blocked on #4166. This work will require us to fully unify exclusive and ordinary systems.

[james7132]

#6843 should add support to get an iterator of EntityRef over all entities given a World, however getting an Iterator of EntityMut is going to be highly unsound without LendingIterator to ensure only one EntityMut is valid at any given time.

[jakobhellermann]

however getting an Iterator of EntityMut is going to be highly unsound without LendingIterator to ensure only one EntityMut is valid at any given time.

This is just because we currently store a &mut World in EntityMut, right? In theory nothing prevents us from having two EntityMuts that refer to different entities that are alive at the same time?

[jakobhellermann]

In theory nothing prevents us from having two EntityMuts that refer to different entities that are alive at the same time?

Correction: only if we remove EntityRef::world and EntityMut::into_world_mut/world_scope/world_mut/world.

[james7132]

This is just because we currently store a &mut World in EntityMut, right? In theory nothing prevents us from having two EntityMuts that refer to different entities that are alive at the same time?

Due to the use of swap_remove and entity locations being updated, structural mutations (adding/removing components) to entities via EntityMut can and will invalidate the locations in other EntityRefs/EntityMuts and the metadata used to make the original iterator.

We'd likely need a mutable version of EntityRef that disallows structural mutations.