constraints on user customizations of standard sender algorithms are incorrectly specified

[ericniebler]

[exec.snd.general]/p1 reads:

Subclauses [exec.factories] and [exec.adapt] define customizable algorithms that return senders. Each algorithm has a default implementation. Let sndr be the result of an invocation of such an algorithm or an object equal to the result ([concepts.equality]), and let Sndr be decltype((sndr)). Let rcvr be a receiver of type Rcvr with associated environment env of type Env such that sender_to<Sndr, Rcvr> is true. For the default implementation of the algorithm that produced sndr, connecting sndr to rcvr and starting the resulting operation state ([exec.async.ops]) necessarily results in the potential evaluation ([basic.def.odr]) of a set of completion operations whose first argument is a subexpression equal to rcvr. Let Sigs be a pack of completion signatures corresponding to this set of completion operations. Then the type of the expression get_completion_signatures(sndr, env) is a specialization of the class template completion_signatures ([exec.util.cmplsig]), the set of whose template arguments is Sigs. If a user-provided implementation of the algorithm that produced sndr is selected instead of the default, any completion signature that is in the set of types denoted by completion_signatures_of_t<Sndr, Env> and that is not part of Sigs shall correspond to error or stopped completion operations, unless otherwise specified.

The emphasized sentence is the problem. Since P2300 got lazy customization, the expression get_completion_signatures(snd, env) could dispatch to a customization. We should define a low-level exposition-only get-completion-signatures function that does the same as get_completion_signatures except without the sender transformation. Then we can express get_completion_signatures in terms of that.

[jwakely]

Created https://cplusplus.github.io/LWG/issue4199