Skip to content

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

Closed
alice-i-cecile opened this issue Mar 21, 2024 · 3 comments · Fixed by #18766
Labels
A-ECS Entities, components, systems, and events C-Feature A new feature, making something new possible

Comments

@alice-i-cecile
Copy link
Member

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 and NonsendMut.

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.

@alice-i-cecile alice-i-cecile added C-Feature A new feature, making something new possible A-ECS Entities, components, systems, and events labels Mar 21, 2024
@msvbg
Copy link
Contributor

msvbg commented Mar 21, 2024

What does Option<Query<...>> mean? I'm not sure this makes sense all the time.

@alice-i-cecile
Copy link
Member Author

alice-i-cecile commented Mar 21, 2024

#7162 and #8196 attempt to tackle a similar space, through the addition of an additional FallibleSystemParam trait that allows for users to bypass the orphan rule.

@alice-i-cecile
Copy link
Member Author

What does Option<Query<...>> mean? I'm not sure this makes sense all the time.

The idea would be that for some system param, these would just always return Some. It is a drawback of this design though.

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
Labels
A-ECS Entities, components, systems, and events C-Feature A new feature, making something new possible
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants