Run criteria should not be allowed to mutate the world #2841
Labels
A-ECS
Entities, components, systems, and events
C-Feature
A new feature, making something new possible
S-Needs-Design
This issue requires design work to think about how it would best be accomplished
What problem does this solve or what need does it fill?
Run criteria are currently implemented using ordinary systems, and evaluated in order.
However, run criteria should not be allowed to mutate the world state:
As far as I can tell, there are no valid use cases for run criteria mutating the world themselves.
What solution would you like?
Run criteria are no longer systems. Instead, they are system-like. Conceptually, they could be described as "pure systems", in analogy to pure functions.
Run criteria can read data from the world, but every run criteria parameter must satisfy
ReadOnlyFetch
.By enforcing this constraint, we can skip out on expensive coordination machinery (and complex ordering and side effect concerns) when checking run criteria. All run criteria then be evaluated in parallel, completely ignoring order.
What alternative(s) have you considered?
Enforce this with code hygiene or a lint.
Make this a special case of systems. However, specialization is not "yet" part of Rust, and this approach will fail due to conflicting trait impls.
Additional context
This should probably be tackled as part of the initiative in #2801.
The text was updated successfully, but these errors were encountered: