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.
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
Add Immutable
Component
Support #16372base: main
Are you sure you want to change the base?
Add Immutable
Component
Support #16372Changes from 18 commits
e822fe0
9d00974
fdd3b35
d895c9a
24619f9
3ab5e97
ac328b1
cae92e5
ef1802c
d71fae0
4050f62
9511f8c
d837843
c353a74
462bbe8
e49dd27
2ac50cf
07f0892
42c531b
72c660d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I considered just adding an
immutable: bool
parameter to the existingnew_with_layout
, but this avoids another breaking change in the API.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.
I haven't added immutability to
Resource
s in this PR to keep the scope contained. I suspect it would basically just be a duplication of some of the infrastructure added for immutableComponent
s anyway, so once this PR is merged a followup should be straight-forward. However, withoutResource
-hooks, I'm not sure how useful it'd be.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.
I'm a little concerned about putting these in the prelude, since they're such generic terms. If any other area of Bevy needs to use similar terms, I think it'd make sense to move these mutability markers into their own module, independent of
component
(perhapschange_detection
?).Happy to remove them from the prelude if anyone has concerns. They're still publicly accessible regardless.
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.
This is the consequence of changes made to the entry API for components. Ideally, we would return
Mut<T>
when callingor_default()
on a mutable component, and&T
on an immutable component (and likewise for other entry methods). The problem is that would require specialisation, since the Rust compiler has no way of knowing thatComponent<Mutability = Mutable>
andComponent<Mutability = Immutable>
are mutually exclusive traits.Since we already have the
OccupiedEntry
type, I decided to return that for all relevant operations instead, since it already has methods to either get a im/mutable reference to the underlying component. The alternatives would either be to not allow the entry API for immutable components (bad), or duplicate all the methods (or_default_immutable()
, etc.)