Better system chaining / piping

[Adamkob12]

What problem does this solve or what need does it fill?

There are many different methods to control the execution flow of a system set. I think many of them could be unified into an easy and intuitive API. For example, "piping" and "chaining" systems is essentially the same thing: you could look at "chaining" as piping () . Ideally, these two concepts should be merged into a nice and consistent API.

What solution would you like?

I think we can achieve a really nice looking API by utilizing the Shr (or Shl) traits.
For example:

Simple chaining

// Before:
(sys1, sys2, sys3).chain()

// After:
sys1 >> sys2 >> sys3

Simple piping

// Before:
sys1.pipe(sys2).pipe(sys3)

// After:
sys1 >> sys2 >> sys3

Complex chaining + piping

// Before:
(((sys1, sys2, sys3).chain(), sys4, sys5.pipe(sys6)), sys7).chain()

// After:
(sys1 >> sys2 >> sys3, sys4, sys5 >> sys6) >> sys7

What alternative(s) have you considered?

Keep the API as is

Additional context

• We can also use declarative macros. That would offer more flexibility, but it will be harder to implement and maintain (and it's not guaranteed to make the API feel better)
• This could open the gate for "1-N piping" (piping the output of a system into many systems)

[Adamkob12]

If this is acceptable, I would like to work on the implementation.

[hymm]

Not a fan of using operator overloading like this. This doesn't behave how I would think a right shift operator should work.

[alice-i-cecile]

Chaining and piping fundamentally don't work the same way. Piping is a "merging" of systems: they become one single unit, and are evaluated as a single system. Chaining is a set of .before / .after ordering; the systems retain their identity, their accesses stay disjoint and other systems can run in between them

For more context, consider checking out bevyengine/rfcs#46 (atomic sets, as an extension of that "join systems together" idea) and #8715, for the latest in several attempts to extend system piping to more complex arrangements.

[Adamkob12]

Not a fan of using operator overloading like this. This doesn't behave how I would think a right shift operator should work.

I'm not sure I completely understand. But would it help if the suggestion was optional, and everyone could choose whether to use 'chain' and 'pipe', or '>>'? After playing around with it I found it quite intuitive and easier on the eyes.

[Adamkob12]

Chaining and piping fundamentally don't work the same way. Piping is a "merging" of systems: they become one single unit, and are evaluated as a single system. Chaining is a set of .before / .after ordering; the systems retain their identity, their accesses stay disjoint and other systems can run in between them

I'm aware that chaining and piping is different internally. But in my opinion, the difference in implementation should not necessarily reflect a different API for each. Under the hood '>>' will 'chain' systems with no output/ input, and it will 'pipe' systems with.

What do you think about adding this as an option, and not as a replacement?

[SkiFire13]

Syntax wise I'm not sure the >> syntax is possible. Both sides of the operator generally have a function item type, which are not local to Bevy, so the Shr/Shl traits cannot be implemented.

[Adamkob12]

Syntax wise I'm not sure the >> syntax is possible. Both sides of the operator generally have a function item type, which are not local to Bevy, so the Shr/Shl traits cannot be implemented.

That's true. I didn't realize that.