As soon as possible and as late as possible system ordering

[alice-i-cecile]

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

In many cases, users don't particularly care when a given system runs: they just have a vague sense of "early" or "late".

Specifying this within a single stage involves a lot of upkeep and busy work as you need to constantly check and resolve ambiguities.

What solution would you like?

Add another pair of methods to match .before and .after:

• as_soon_as_possible: runs the system as soon as possible, while respecting any explicit constraints given
• as_late_as_possible runs the system as late as possible, while respecting any explicit contraints given

Under the hood, what this does is inserts a before / after ordering between this system and any other systems that it would be ambiguous with.

Cases where the other system is also ASAP / ALAP remain ambiguous.

What alternative(s) have you considered?

1. Use asap and alap as method names. ASAP is a common abbreviation, but ALAP is not. Both are quite hard to parse in lower-case, especially for users that are not native English speakers. Autocomplete is a thing, and it's important to make sure that users don't accidentally typo or misread ASAP vs. ALAP due to the massive difference in effect and difficulty debugging.

Additional context

Raised in #4166 (comment) in the context of ordering exclusive systems.

[MiniaczQ]

Reminds me of the top-most window problem, except you don't really care if it stays on top after the insertion?
So another asap would be put before the previous asap.
Seems reasonable for final-user interface, but not too sound for crates, since the order of addition is ambiguous (decided by the create user).
Also heavily depends on what said system would do.

[alice-i-cecile]

So another asap would be put before the previous asap.

Yeah, I'd strongly prefer to avoid this: we removed insertion order system ordering for good reasons.

[alice-i-cecile]

The notion of default labels introduced in #4224 should make implementing this quite straightforward: just assign every system a univsersal label, then use a standard before / after ordering (and remove the universal label from the ASAP system).

[alice-i-cecile]

#4728 implements a somewhat messy workaround for this (and the challenges around system ordering addressed in #4391) in order to stabilize our measurement of elapsed time.

[Aceeri]

Could use first and last instead of asap and alap potentially.

[alice-i-cecile]

That's a much better naming scheme 😂

[ItsDoot]

Under the hood, what this does is inserts a before / after ordering between this system and any other systems that it would be ambiguous with.

In the context of today, I don't think we should add a way to implicitly resolve system race conditions / ambiguities. Our current setup of writing out ordering constraints (especially with (system_a, system_b).chain() which was added since this issue was created) and being explicit about opting out of these race conditions with ambiguous_with should be ample enough. Adding implicit resolutions would only serve to confuse.