-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate the rest of the engine to UnsafeWorldCell
#8833
Migrate the rest of the engine to UnsafeWorldCell
#8833
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Each of these commits makes sense to me. Pretty mechanical stuff.
Very happy to see validate_world get a more sensible API, and even happier to finally purge our code base of this pattern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look good to me.
I do wonder how we should balance the tradeoff between not having similar copies of methods for &World
and UnsafeWorldCell
vs not exposing people to implementation details.
For example in the render code, self.cameras.update_archetypes(world.as_unsafe_world_cell())
is unfortunate because it is actually used in a few places outside of just bevy_ecs internals.
Maybe it would be worth it to have update_archetypes(&World)
and update_archetypes_unsafe_world_cell(UnsafeWorldCell<'_>)
here?
Anyways, thanks for actually finishing the migration, I hope we can get this into 0.11.
IMO the ideal way of doing this would be to have You're right though, just adding |
# Objective We've done a lot of work to remove the pattern of a `&World` with interior mutability (#6404, #8833). However, this pattern still persists within `bevy_ecs` via the `unsafe_world` method. ## Solution * Make `unsafe_world` private. Adjust any callsites to use `UnsafeWorldCell` for interior mutability. * Add `UnsafeWorldCell::removed_components`, since it is always safe to access the removed components collection through `UnsafeWorldCell`. ## Future Work Remove/hide `UnsafeWorldCell::world_metadata`, once we have provided safe ways of accessing all world metadata. --- ## Changelog + Added `UnsafeWorldCell::removed_components`, which provides read-only access to a world's collection of removed components.
# Objective We've done a lot of work to remove the pattern of a `&World` with interior mutability (bevyengine#6404, bevyengine#8833). However, this pattern still persists within `bevy_ecs` via the `unsafe_world` method. ## Solution * Make `unsafe_world` private. Adjust any callsites to use `UnsafeWorldCell` for interior mutability. * Add `UnsafeWorldCell::removed_components`, since it is always safe to access the removed components collection through `UnsafeWorldCell`. ## Future Work Remove/hide `UnsafeWorldCell::world_metadata`, once we have provided safe ways of accessing all world metadata. --- ## Changelog + Added `UnsafeWorldCell::removed_components`, which provides read-only access to a world's collection of removed components.
# Objective We've done a lot of work to remove the pattern of a `&World` with interior mutability (bevyengine#6404, bevyengine#8833). However, this pattern still persists within `bevy_ecs` via the `unsafe_world` method. ## Solution * Make `unsafe_world` private. Adjust any callsites to use `UnsafeWorldCell` for interior mutability. * Add `UnsafeWorldCell::removed_components`, since it is always safe to access the removed components collection through `UnsafeWorldCell`. ## Future Work Remove/hide `UnsafeWorldCell::world_metadata`, once we have provided safe ways of accessing all world metadata. --- ## Changelog + Added `UnsafeWorldCell::removed_components`, which provides read-only access to a world's collection of removed components.
# Objective We've done a lot of work to remove the pattern of a `&World` with interior mutability (bevyengine#6404, bevyengine#8833). However, this pattern still persists within `bevy_ecs` via the `unsafe_world` method. ## Solution * Make `unsafe_world` private. Adjust any callsites to use `UnsafeWorldCell` for interior mutability. * Add `UnsafeWorldCell::removed_components`, since it is always safe to access the removed components collection through `UnsafeWorldCell`. ## Future Work Remove/hide `UnsafeWorldCell::world_metadata`, once we have provided safe ways of accessing all world metadata. --- ## Changelog + Added `UnsafeWorldCell::removed_components`, which provides read-only access to a world's collection of removed components.
# Objective We've done a lot of work to remove the pattern of a `&World` with interior mutability (bevyengine#6404, bevyengine#8833). However, this pattern still persists within `bevy_ecs` via the `unsafe_world` method. ## Solution * Make `unsafe_world` private. Adjust any callsites to use `UnsafeWorldCell` for interior mutability. * Add `UnsafeWorldCell::removed_components`, since it is always safe to access the removed components collection through `UnsafeWorldCell`. ## Future Work Remove/hide `UnsafeWorldCell::world_metadata`, once we have provided safe ways of accessing all world metadata. --- ## Changelog + Added `UnsafeWorldCell::removed_components`, which provides read-only access to a world's collection of removed components.
# Objective We've done a lot of work to remove the pattern of a `&World` with interior mutability (bevyengine#6404, bevyengine#8833). However, this pattern still persists within `bevy_ecs` via the `unsafe_world` method. ## Solution * Make `unsafe_world` private. Adjust any callsites to use `UnsafeWorldCell` for interior mutability. * Add `UnsafeWorldCell::removed_components`, since it is always safe to access the removed components collection through `UnsafeWorldCell`. ## Future Work Remove/hide `UnsafeWorldCell::world_metadata`, once we have provided safe ways of accessing all world metadata. --- ## Changelog + Added `UnsafeWorldCell::removed_components`, which provides read-only access to a world's collection of removed components.
Objective
Follow-up to #6404 and #8292.
Mutating the world through a shared reference is surprising, and it makes the meaning of
&World
unclear: sometimes it gives read-only access to the entire world, and sometimes it gives interior mutable access to only part of it.This is an up-to-date version of #6972.
Solution
Use
UnsafeWorldCell
for all interior mutability. Now,&World
always gives you read-only access to the entire world.Changelog
TODO - do we still care about changelogs?
Migration Guide
Mutating any world data using
&World
is now considered unsound -- the typeUnsafeWorldCell
must be used to achieve interior mutability. The following methods now acceptUnsafeWorldCell
instead of&World
:QueryState
:get_unchecked
,iter_unchecked
,iter_combinations_unchecked
,for_each_unchecked
,get_single_unchecked
,get_single_unchecked_manual
.SystemState
:get_unchecked_manual
The methods
QueryState::validate_world
andSystemState::matches_world
now take aWorldId
instead of&World
:The methods
QueryState::update_archetypes
andSystemState::update_archetypes
now takeUnsafeWorldCell
instead of&World
: