Run criteria multipiping

[Ratysz]

Objective

• Implement piping of results from an arbitrary amount (well, up to 16) of run criteria to enable constructing proper criteria combinators.
• Sneak in "Optional .system(), part 5 (criteria piping)", shhh.

Solution

• Rework RunCriteriaContainer to store a RunCriteriaTrait trait object instead of the single/piped enum.
• Implement pseudovariadics codegen for the aforementioned trait object and piping.
• Expand parallel_run_criteria test to cover the new cases; expand documentation of RunCriteria::pipe().

Relevant issues

• Combining multiple run criteria #1295
• Run criteria should be composable; states should act more like other run criteria #2233

---

Quick example:

stage.with_system_run_criteria(
    ("every second time", "every third time")
        .pipe(|input: In<(ShouldRun, ShouldRun)>| match input {
            In((ShouldRun::Yes, ShouldRun::Yes)) => ShouldRun::Yes,
            _ => ShouldRun::No,
        })
        .label("every sixth time"),
)

I'll see if I can do something about that double indirection (the RunCriteriaInner thing in the implementation). (Forgot how Rust works for a moment there.)

[mockersf]

wouldn't that be a join rather than a pipe ?

[Ratysz]

Hm, I can see it like that. Although, as per previous discussion, I think it's pretty important to highlight the, well, piping of outputs into an input, rather than the order of operations alone.

[Ratysz]

bors try

[bors]

try

Merge conflict.

[alice-i-cecile]

Nit: can't we just use expect here?

Nope, apparently this way dodges string formatting costs: https://stackoverflow.com/a/63291643/3234149

[alice-i-cecile]

Great code quality, as always. The multi-piping API is nice (and a very natural extension), the system yeet is 💯.

[alice-i-cecile]

Adding to 0.6 milestone for the optional .system aspects. If the rest of the PR is controversial, we can split this out.

[wilk10]

This is excellent and enables some nice use cases, thanks a lot!

[cart]

Removed from the 0.6 milestone in the interest of time. Pipes are pretty niche, so requiring .system() in those cases doesn't bother me.

[cart]

Pulling in bevyengine/rfcs#45 participants: @alice-i-cecile @DJMcNab @inodentry @maniwani @hymm
I haven't done a full review of the stageless RFC yet: how does "multipiping" play into those plans?

[alice-i-cecile]

I haven't done a full review of the stageless RFC yet: how does "multipiping" play into those plans?

The current plans there are that run criteria automatically compose with AND.

Run criteria can no longer loop, so this simple rule is sufficient (at least for a first attempt).

[cart]

Testing @bevyengine/ecs-team pings

[maniwani]

I haven't done a full review of the stageless RFC yet: how does "multipiping" play into those plans?

So in current Bevy, RC can be referenced by label (like any other system) and they're collectively evaluated at the beginning of each stage.

Both of those properties go away in the RFC. Instead, each system gets its own instances of any RC it's been assigned. And the new definition is that all of a system's RC must return true "just before" it runs. (RFC makes RC return bool and limits them to read-only access to make them easier to combine.)

Current plan is to have the executor evaluate all of a system's RC inside the main executor task, after that system becomes ready (none of its dependencies remain). If both system + all its RC can run, the RC is ran first. If all return true (this is the AND), only then do we spawn and signal the system task, otherwise we just mark the system as completed.

For toggling a group of systems, users can assign RC to labels (which conceptually map to sub-graphs in the overall system graph). When the executor encounters a ready system with "not-yet-seen" labels, it checks if system + all its RC + all not-yet-seen label RC can run. If so, the label RC is ran first. All systems with the labels whose RC returned false would be immediately marked as completed.

Edit: tl;dr direct RC piping goes away. That said, users can have a system writing some resource that later RC instances just read. We're hoping that the read-only access and lack of task overhead counterbalances the inability to share RC (except indirectly through labels).

[alice-i-cecile]

I'm going to close this out: I think it's increasingly unlikely that we go with this particular design and #4391 solves the underlying problem in a much more elegant way.

And with iyes_loopless out, there's much less need for an urgent solution.