Hello list,

Right now [exec.sync.wait] item 1 says “`sync_wait` mandates that the input
sender has exactly one value completion signature.” This seems overly
restrictive for several reasons:
1. Teachability: Given `sync_wait(just())` evaluates to
`std::optional<std::tuple<>>`, where `std::nullopt` indicates stoppedness
and throwing indicates failure, a learner would expect that
`sync_wait(just_stopped()) == std::nullopt` and that
`sync_wait(just_error(e))` would have the same type but throw.

2. Main loop: In production code, I could see a `main()` function that ends
in `return async_wait(snd).has_value() ? 0 : 1;`, where `snd` is
essentially an infinite loop that can only fail or be stopped.
3. Genericity: By requiring exactly one value completion signature, that
makes the value channel special. Arguably it is special, but does it need
to be this special? And in the main-loop case, if a refactor makes `snd`
never return a value, users are forced to change the `retrurn` line.

Possible solutions:

   1.

   If there is no value channel, return as though the sender sends void (so
   `std::optional<std::tuple<>>`). This is basically what it already does for
   `sync_wait(just()) -> std::optional<std::tuple<>>` where that optional is
   never not engaged even though statically we could know that the sender is
   unstoppable.
   2.

   Return using an (unspecified?) unconstructible type in place of the
   tuple, so `sync_wait(just_stopped()) -> std::optional<__unconstructible>`.
   This has the advantage of statically exposing the fact that there will
   never be any value returned.


Of these, I prefer (a) because it has the advantage of
beginner-friendlyness and not being surprising. It is consistent with
`sync_wait(just())` which isn’t `noexcept` (even though the sender can’t
error) and returns optional even though it can’t be stopped. If advanced
users want (b), then they can easily write their own that propagates
non-error to `noexcept`, propagates non-stopping to non-optional (or an
optional-like that is statically always engaged), propagates error-only as
`[[noreturn]]`, or that, like the standard has it now, requires the sender
have a value completion.

As for `sync_wait_with_variant(just_stopped())`, I think
`std::optional<std::variant<>>` makes a lot of sense given `std::variant<>`
is an unconstructible type indicating no value channel.


Do you think this is a defect that should be addressed?

Cheers,
Ben