Relaxed (if-needed) ordering constraints

[alice-i-cecile]

RENDERED

Extracted from #45.

Summary

If-needed ordering constraints allow for safer, non-blocking constraints betweeen groups of systems.
If they would have no effect, they're completely ignored.
If they have an effect, they behave identically to strict ordering constraints.

Motivation

The stageless rework (RFC #45) allows users to configure entire labels, creating ordering dependencies between entire subgraphs.
However, in many cases, pairs of systems ordered in this way have no logical connection between them (and do not even access the same data).

The current ordering, called strict ordering, will still force these pairs of systems to run according to the specified ordering, pointlessly restricting scheduling flexibility and thus performance.

[MiniaczQ]

Can there be a situation where 2 systems need a relative ordering if they share no common Params?
Perhaps strict ordering can be omitted between systems of such nature.

[alice-i-cecile]

Yes; interior mutability and transitive dependencies.

[MiniaczQ]

I was going to propose something similar after discord discussion of similar topic, so I'm glad I stumbled here.
Definitely a great idea to make this the default way of adding systems (I only thought of warning about too restrictive ordering).
The only thing that I'd change is the naming, which didn't immediately click for me.
I propose renaming:

• strict to forced, since it'd be forcing an ordering between 'unrelated' systems.
• if-needed to lax or relaxed, since it's not a binary problem whether the constraint exists, transitivity can keep the constraint, but change the systems involved.

[alice-i-cecile]

I like "relaxed" quite a bit: it's a good contrast to "strict", and much more approachable.

I don't think "forced" explains the concept any better: I personally think "strict" captures the essence a bit better: the idea is "yes, for real, I know better than you".

[JoJoJet]

My bikeshed opinion: how about "fixed" and "relaxed"? If someone explicitly declares an ordering between two systems, I think that by default we should adhere to that, so we shouldn't be using negative language like "strict" or "forced". In cases when a label is only there to clear up potential ambiguities, you could explicitly mark it as "relaxed" to allow for faster scheduling.

[alice-i-cecile]

Strict has a pretty standard (non-negative) meaning in math and computer science: it typically contrasts to relaxed, partial, or loose and has an implication of being the more maximal version of this. I'm not sure that it's immediately clear what a "fixed ordering constraint" does, while it feels like a "strict ordering constraint" is clearer.

I would be happy with "strong / weak ordering constraints" instead though. Is that clearer to you?

[JoJoJet]

Seems reasonable, "strict/relaxed" works. Definitely prefer it over "strong/weak".

[greaka]

Why are these systems compatible? Since you cannot reason about what apply_player_movement exactly does to Velocity, it should be treated as "reads and writes Velocity".
Imagine the following:

fn apply_player_movement(_: Res<&PlayerIntent>, velocity: Query<(&mut Velocity, With<Player>)>) {
  if velocity > 5 {
    // doesn't really matter what happens here,
    // it branches based on potentially stale data if this is considered spurious
  }
}