Giacomo Stevanato

Note that while restricting filters to dense components would fix this issue, it would prevent future optimizations to sparse only queries (e.g. `Query` could be optimized to iterate over only...

> If we limit the components you can register to ones with table storage, the unsoundness would be solved Note that this fix still leaves the possibility for future unsoundness...

An approach similar to `EntityWorldMut::take` + `EntityWorldMut::insert` could work, but I don't see a way to optimize it to avoid the archetype move, which is pretty costly.

Another reason why this should be avoided is that `OwningPtr` only owns the data, not the allocation, so the proposed conversion would have to leak the allocation. I would instead...

I finally took the time to do a couple of benchmarks. My machine is pretty noisy, so don't expect them to be very accurate. It does show some small percent...

> The for_each slowdowns are concerning. Might not be autovectorizing anymore. I would expect them to be mainly noise since the changes don't really affect the inner loop over tables,...

It's not entirely clear to me how this would fix the issue. If `HierarchyQueryExt` is changed to require `&mut World` you still won't be able to use it with a...

This should be made to work in a generic way with any `SystemParam`/with `SystemState`. Then multiple queries would be supported as `(Query, Query)` or `SystemState

> unsure if we can do anything more than multi-query AFAIK no `SystemParam` yet modifies the `World` structurally, also because I don't think the access mechanism allows to safely express...

Ah I see my mistake: I was assuming this is just about fetching the system parameter (which takes a `UnsafeWorldCell` and need to respect the access API), however there's also...