Run criteria should not be allowed to mutate the world

[alice-i-cecile]

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:

• this can cause surprising side effects, as the run criteria itself may change the world
• this forces us to care about the order they are executed in
• this reduces type safety, as users can accidentally place run criteria where they intend to use a system and so on

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.

[TheRawMeatball]

As far as I can tell, there are no valid use cases for run criteria mutating the world themselves.

States currently rely on this.

[alice-i-cecile]

States currently rely on this.

Right, that shouldn't surprise me. So I suppose this gets tossed onto the pile of hard schedule-adjacent problems in #2801.

[maniwani]

Resolved by #7267.