the preconditions on `run_loop::run()` are too strict

[ericniebler]

problem

the precondition on run_loop::run() is that the state is starting. given that run_loop::finish() puts the loop in the finishing state, the implication is that one cannot call finish() before calling run().

However, in most cases sync_wait is calling finish() on its run_loop before calling run(), violating this precondition. sync_wait does the following:

run_loop loop;
auto op = connect(sndr, sync_wait_receiver{&loop});
start(op);

loop.run();

if sndr completes synchronously, the sync_wait_receiver will call finish() on the loop before loop.run() is called, violating run's precondition.

proposed resolution

the precondition on run_loop::run should be:

1. Precondition: state is starting or finishing.

[lewissbaker]

I don't think that the proposed resolution is sufficient as this doesn't prevent the case where run() has previously been called and has returned.

Assuming we want to preserve this restriction (i.e. you can only call run() once), we probably want to instead:

• add a fourth state named "finished"
• update the effects of the pop-front() method to transition the state to "finished" if it detects that the state is "finishing" and the count is zero.
• update the pre-condition on run() to require that state is either "starting" or "finishing"
  i.e. is not "running" (preventing concurrent/overlapping calls to run()) and is not "finished" (preventing a subsequent call to run() after run() has already returned).

[lewissbaker]

A resolution to this issue has been proposed in https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3396r0.html

[lewissbaker]

The proposed resolution was adopted in the Wroclaw meeting.
See https://wg21.link/P3396R1.