-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
Support arbitrary optional SystemParam
types in systems with a blanket impl SystemParam for Option<S: SystemParam>
#12634
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
Comments
What does |
The idea would be that for some system param, these would just always return |
5 tasks
github-merge-queue bot
pushed a commit
that referenced
this issue
May 7, 2025
# Objective Provide a generic `impl SystemParam for Option<P>` that uses system parameter validation. This immediately gives useful impls for params like `EventReader` and `GizmosState` that are defined in terms of `Res`. It also allows third-party system parameters to be usable with `Option`, which was previously impossible due to orphan rules. Note that this is a behavior change for `Option<Single>`. It currently fails validation if there are multiple matching entities, but with this change it will pass validation and produce `None`. Also provide an impl for `Result<P, SystemParamValidationError>`. This allows systems to inspect the error if necessary, either for bubbling it up or for checking the `skipped` flag. Fixes #12634 Fixes #14949 Related to #18516 ## Solution Add generic `SystemParam` impls for `Option` and `Result`, and remove the impls for specific types. Update documentation and `fallible_params` example with the new semantics for `Option<Single>`.
andrewzhurov
pushed a commit
to andrewzhurov/bevy
that referenced
this issue
May 17, 2025
# Objective Provide a generic `impl SystemParam for Option<P>` that uses system parameter validation. This immediately gives useful impls for params like `EventReader` and `GizmosState` that are defined in terms of `Res`. It also allows third-party system parameters to be usable with `Option`, which was previously impossible due to orphan rules. Note that this is a behavior change for `Option<Single>`. It currently fails validation if there are multiple matching entities, but with this change it will pass validation and produce `None`. Also provide an impl for `Result<P, SystemParamValidationError>`. This allows systems to inspect the error if necessary, either for bubbling it up or for checking the `skipped` flag. Fixes bevyengine#12634 Fixes bevyengine#14949 Related to bevyengine#18516 ## Solution Add generic `SystemParam` impls for `Option` and `Result`, and remove the impls for specific types. Update documentation and `fallible_params` example with the new semantics for `Option<Single>`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What problem does this solve or what need does it fill?
The
Option<Res<T>>
implementation is very convenient to improve robustness when a resource may or may not exist.We currently have special-cased impls for this for
Res
,ResMut
,NonSend
andNonsendMut
.Other system parameters (like
EventWriter
) are not supported. This is particularly frustrating for third-party system param, as orphan rules prevent users from writing their own.What solution would you like?
Replacing the existing manual implementations with a blanket impl for all
SystemParam
.What alternative(s) have you considered?
Add manual impls for all of Bevy's first-party system param. This is more boilerplate, doesn't help external system param types, and doesn't play nice with generic code.
Note that some system param (like
Entities
) will always exist, so this approach does reduce the footgun potential.Additional context
Raised on Discord.
The text was updated successfully, but these errors were encountered: