[Merged by Bors] - Add marker traits to distinguish base sets from regular system sets #7863
Conversation
This file contains 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
JoJoJet
added
A-ECS
nicopap
approved these changes
Mar 2, 2023
TimJentzsch
approved these changes
Mar 2, 2023
alice-i-cecile
added
the
S-Ready-For-Final-Review
alice-i-cecile
approved these changes
Mar 2, 2023
There was a problem hiding this comment.
Much needed: I'm glad that we managed to get compile-time detection here and this is an elegant strategy that reduces code duplication.
FYI @cart, who tried to achieve this goal in initial implementations of base system sets.
bors r+
bors bot
pushed a commit
that referenced
this pull request
Mar 2, 2023
…7863) # Objective Base sets, added in #7466 are a special type of system set. Systems can only be added to base sets via `in_base_set`, while non-base sets can only be added via `in_set`. Unfortunately this is currently guarded by a runtime panic, which presents an unfortunate toe-stub when the wrong method is used. The delayed response between writing code and encountering the error (possibly hours) makes the distinction between base sets and other sets much more difficult to learn. ## Solution Add the marker traits `BaseSystemSet` and `FreeSystemSet`. `in_base_set` and `in_set` now respectively accept these traits, which moves the runtime panic to a compile time error. --- ## Changelog + Added the marker trait `BaseSystemSet`, which is distinguished from a `FreeSystemSet`. These are both subtraits of `SystemSet`. ## Migration Guide None if merged with 0.10
|
Pull request successfully merged into main. Build succeeded:
|
bors
bot
changed the title
|
This was a great idea / a good win! We might want to also remove the runtime validation as its redundant / will just take up space and compute time. |
|
I left the runtime checks since it's possible for someone to make a custom |
bors bot
pushed a commit
that referenced
this pull request
Mar 3, 2023
# Objective #7863 introduced a potential footgun. When trying to incorrectly add a user-defined type using `in_base_set`, the compiler will suggest that the user implement `BaseSystemSet` for their type. This is a reasonable-sounding suggestion, however this is not the correct way to make a base set, and will lead to a confusing panic message when a marker trait is implemented for the wrong type. ## Solution Rewrite the documentation for these traits, making it more clear that `BaseSystemSet` is a marker for types that are already base sets, and not a way to define a base set.
Shfty
pushed a commit
to shfty-rust/bevy
that referenced
this pull request
Mar 19, 2023
…evyengine#7863) # Objective Base sets, added in bevyengine#7466 are a special type of system set. Systems can only be added to base sets via `in_base_set`, while non-base sets can only be added via `in_set`. Unfortunately this is currently guarded by a runtime panic, which presents an unfortunate toe-stub when the wrong method is used. The delayed response between writing code and encountering the error (possibly hours) makes the distinction between base sets and other sets much more difficult to learn. ## Solution Add the marker traits `BaseSystemSet` and `FreeSystemSet`. `in_base_set` and `in_set` now respectively accept these traits, which moves the runtime panic to a compile time error. --- ## Changelog + Added the marker trait `BaseSystemSet`, which is distinguished from a `FreeSystemSet`. These are both subtraits of `SystemSet`. ## Migration Guide None if merged with 0.10
Shfty
pushed a commit
to shfty-rust/bevy
that referenced
this pull request
Mar 19, 2023
# Objective bevyengine#7863 introduced a potential footgun. When trying to incorrectly add a user-defined type using `in_base_set`, the compiler will suggest that the user implement `BaseSystemSet` for their type. This is a reasonable-sounding suggestion, however this is not the correct way to make a base set, and will lead to a confusing panic message when a marker trait is implemented for the wrong type. ## Solution Rewrite the documentation for these traits, making it more clear that `BaseSystemSet` is a marker for types that are already base sets, and not a way to define a base set.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Objective
Base sets, added in #7466 are a special type of system set. Systems can only be added to base sets via
in_base_set, while non-base sets can only be added viain_set. Unfortunately this is currently guarded by a runtime panic, which presents an unfortunate toe-stub when the wrong method is used. The delayed response between writing code and encountering the error (possibly hours) makes the distinction between base sets and other sets much more difficult to learn.Solution
Add the marker traits
BaseSystemSetandFreeSystemSet.in_base_setandin_setnow respectively accept these traits, which moves the runtime panic to a compile time error.Changelog
BaseSystemSet, which is distinguished from aFreeSystemSet. These are both subtraits ofSystemSet.Migration Guide
None if merged with 0.10