-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
MovingPtr<'_,B: Bundle>
impls Bundle
#21443
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
Draft
janis-bhm
wants to merge
11
commits into
bevyengine:main
Choose a base branch
from
janis-bhm:ecs/movingptr-bundle-impl-bundle
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
MovingPtr<'_,B: Bundle>
impls Bundle
#21443
janis-bhm
wants to merge
11
commits into
bevyengine:main
from
janis-bhm:ecs/movingptr-bundle-impl-bundle
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It looks like your PR is a breaking change, but you didn't provide a migration guide. Please review the instructions for writing migration guides, then expand or revise the content in the migration guides directory to reflect your changes. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-ECS
Entities, components, systems, and events
C-Bug
An unexpected or incorrect behavior
C-Usability
A targeted quality-of-life change that makes Bevy easier to use
D-Unsafe
Touches with unsafe code in some way
M-Needs-Migration-Guide
A breaking change to Bevy's public API that needs to be noted in a migration guide
S-Needs-Review
Needs reviewer attention (from anyone!) to move forward
S-Needs-Testing
Testing must be done before this is safe to merge
X-Contentious
There are nontrivial implications that should be thought through
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(I messed up by renaming the branch and I couldn't figure out how to change the branch and reopen #20984)
relevant issue: #20976
Solution
In order to spawn bundles inside
MovingPtr
s alongside other bundles, we need to be able to nameMovingPtr
as a bundle, which the new associated typeName
onBundle
allows. This type is basically a canonicalized bundle name-type that allows types likeSpawnRelatedBundle
to appear to theBundles
as if they were the bundle they are wrapping:R::RelationshipTarget
. (I need to write tests for this).Other parts of the engine, like observers, rely on
Bundle
being'static
in order to pass around the type without being constrained by lifetimes, which is why I've renamedBundle
toBundleImpl
and madetrait Bundle: BundleImpl + 'static
.Not sure how much I like this personally.
Observers only use the associated trait functions of
Bundle
which shouldn't be affected by the lifetime of the type implementingBundle
(I think).An alternative would be to enforce
Bundle::Name
to impl Bundle itself (which it does, since it's just a tuple of bundles) and have the same components/component order asSelf
so thatBundle
s methods are available'static
(though usingDynamicBundle
this way would certainly be unsafe). That could allow types carryingBundles
in phantom datas to use the associated functions for component order and ids.Alternative Solutions
@james7132 pointed out the typeid crate, which is already in the dependency graph, and which allows getting
TypeId
s from non-static types, notably at the cost of dynamic dispatch. This could allow for a simple trait method that returns the type id rather than using the associated typeName
.Note:
As far as I can tell, rustc can inline the dynamic dispatch here into a static call to
core::any::TypeId::of
, meaning there is potentially no added cost to usingtypeid
.Click to expand
disassembly: