Introduce QuerySingle<Q, F> family of system parameters
#15264
Comments
MiniaczQ
added
C-Feature
|
I'll be happy to implement it if someone gives me some directions |
alice-i-cecile
added
A-ECS
|
So I quite like this idea from an ergonomics standpoint, and would use it in my own personal projects. I'm loathe to expose more panicking APIs though, see #14275. I'd be interested in seeing |
|
Until #14275 gets resolved I feel like we should stick to the existing convention. |
|
I'm fine with that. I still think that this suggestion is controversial, independent of #14275, because of the impact on new learners / style due to introducing a redundant method to do the same thing. |
|
@alice-i-cecile imo we should not introduce more |
This is exactly the problem I have with #14275, keep the discussion there and unless there is a consensus for dealing with this, don't bother other issues, it's very disruptive. |
|
@MiniaczQ alright, sorry! |
alice-i-cecile
added
X-Contentious
|
I'm happy to consider this idea unblocked due to the ideas in #15625. Once that's fully implemented, this should be recommended as the default way to work with singleton queries and used consistently through our examples. |
MiniaczQ
changed the title
Res-style system params equivalents for Query::singleSingle<Q, F> family of system parameters
MiniaczQ
changed the title
Single<Q, F> family of system parametersQuerySingle<Q, F> family of system parameters
alice-i-cecile
added
S-Ready-For-Implementation
# Objective The goal of this PR is to introduce `SystemParam` validation in order to reduce runtime panics. Fixes #15265 ## Solution `SystemParam` now has a new method `validate_param(...) -> bool`, which takes immutable variants of `get_param` arguments. The returned value indicates whether the parameter can be acquired from the world. If parameters cannot be acquired for a system, it won't be executed, similarly to run conditions. This reduces panics when using params like `Res`, `ResMut`, etc. as well as allows for new, ergonomic params like #15264 or #15302. Param validation happens at the level of executors. All validation happens directly before executing a system, in case of normal systems they are skipped, in case of conditions they return false. Warning about system skipping is primitive and subject to change in subsequent PRs. ## Testing Two executor tests check that all executors: - skip systems which have invalid parameters: - piped systems get skipped together, - dependent systems still run correctly, - skip systems with invalid run conditions: - system conditions have invalid parameters, - system set conditions have invalid parameters.
# Objective Add the following system params: - `QuerySingle<D, F>` - Valid if only one matching entity exists, - `Option<QuerySingle<D, F>>` - Valid if zero or one matching entity exists. As @chescock pointed out, we don't need `Mut` variants. Fixes: #15264 ## Solution Implement the type and both variants of system params. Also implement `ReadOnlySystemParam` for readonly queries. Added a new ECS example `fallible_params` which showcases `SingleQuery` usage. In the future we might want to add `NonEmptyQuery`, `NonEmptyEventReader` and `Res` to it (or maybe just stop at mentioning it). ## Testing Tested with the example. There is a lot of warning spam so we might want to implement #15391.
# Objective Add the following system params: - `QuerySingle<D, F>` - Valid if only one matching entity exists, - `Option<QuerySingle<D, F>>` - Valid if zero or one matching entity exists. As @chescock pointed out, we don't need `Mut` variants. Fixes: bevyengine#15264 ## Solution Implement the type and both variants of system params. Also implement `ReadOnlySystemParam` for readonly queries. Added a new ECS example `fallible_params` which showcases `SingleQuery` usage. In the future we might want to add `NonEmptyQuery`, `NonEmptyEventReader` and `Res` to it (or maybe just stop at mentioning it). ## Testing Tested with the example. There is a lot of warning spam so we might want to implement bevyengine#15391.
What problem does this solve or what need does it fill?
Following #15276 we should expose new system params that benefit from no panics.
Specifically, we should support entities that act as resources.
We can provide system parameters that are equivalents of
Query::singlefamily of methods.What solution would you like?
Add the following system parameters:
QuerySingle<Q, F>- valid with exactly one resultOption<QuerySingle<Q, F>>- valid with zero or one resultThe text was updated successfully, but these errors were encountered: