Remove WorldCell

[alice-i-cecile]

Objective

• WorldCell is not fully featured: see Expand WorldCell to support queries #1555.
• As a result, it does not fully behave like a Cell (a runtime borrow-checked API to split borrows arbitrarily).
• Making it fully-featured is a questionable idea: see discussion in World cell queries rfcs#42 on how this promotes very panic-prone, fragile and hard-to-reason about code that is easy to write.

Solution

• Remove WorldCell completely, rather than keeping a half-working implementation around.
• Users should use SystemState or resource_scope as needed.
• As other clear use cases arise that cannot be comfortably tackled with the existing API, add additional, less error-prone methods on World.

Notes

In the places where this was used:

• several places were exclusive systems that did not need to be exclusive
• a couple usages were trivially replaced with a resource_scope
• other usages were trivially replaced with a SystemState
• some were apparently completely unnecessary (assorted pipeline FromWorld impls)
• one (winit_runner_with) was straightforward but rather verbose, and reflective of generally not-great code quality (it should be reusable but isn't, and is rather unstructured)

[alice-i-cecile]

@bevyengine/ecs-team; this is fundamentally a design decision. RFC #42 seems fairly doomed (a decision I support), but if it's doomed we should close it and remove the half-working WorldCell API.

As a point in favor of this removal, this API was never used internally.

[cart]

As a point in favor of this removal, this API was never used internally.

This isn't true :)

[alice-i-cecile]

Ah, my search for WorldCell missed it. Let me try fixing those...

[cart]

Pretty sure they can all be replaced with SystemState or resource_scope.
What WorldCell really enables is "arbitrary nesting of non-conflicting contexts with arbitrary ad-hoc borrows". Bevy doesn't use that pattern internally except for the RenderGraph resource_scope, but I can see why some users might want it. We might want it if we want to support Entitas-style event handlers.

[alice-i-cecile]

What WorldCell really enables is "arbitrary nesting of non-conflicting contexts with arbitrary ad-hoc borrows"

I agree.

This is a risky pattern, and non-trivial uses of this are likely to lead to complex runtime panics whenever surrounding code is changed. IMO the ideas discussed in #2192 are a much better way to accomplish the same goals.

[alice-i-cecile]

It's a bit frustrating not to have a better solution for #2192 yet; the extremely complex system state constructed in winit_runner_with would particularly benefit from the caching and complexity management. Looking at the code, I actually think it may be cleanest to just create / store / run a little schedule on the App to push the information from winit into the various event resources. This would also make winit_runner much more reusable / hackable.

Overall, that refactor was quite painless, even for extremely complex uses of WorldCell. And now the system state can be cached and the borrow checker rules are upheld at compile time.

[TheRawMeatball]

We might want it if we want to support Entitas-style event handlers.

I personally think requiring &mut World and adding hooks would be a better way to support this.

[TheRawMeatball]

I agree with the idea, but the winit runner can be done better imo.

[aevyrie]

Please ping me when this is ready to merge, assuming it happens after #3974. I want to double check that everything still behaves as expected. 🙂

[alice-i-cecile]

Please ping me when this is ready to merge

Will do! From my perspective, this is ready-to-merge; it's just waiting on a final decision from Cart.

[aevyrie]

Got it! We'll just have to be mindful if/when this and #3974 are merged that we don't accidentally break anything in the merging process. We don't have an effective way to automatically test the window updating just yet.

[alice-i-cecile]

Closing in favor of the dramatically less controversial #5109. I still think this should be done, but the code-quality changes should be ported over ASAP anyways.

[james7132]

Our internal uses of World::cell outside of tests is now at 0. It might be a good time to revisit this now that we have UnsafeWorldCell and DeferredWorld.