Proposed resolution:

This wording is relative to N5001.

1. Modify [exec.syn] as indicated:

   
     template<class Sndr, class Rcvr>
       requires sender_to<Sndr, Rcvr>
       using connect_result_t =
         decltype(connect(declval<Sndr>(), declval<Rcvr>()));
   

[ 2025-02-07; Reflector poll ]

Set priority to 1 after reflector poll.

Imported from cplusplus/sender-receiver #320.

Since turning `execution::connect(sndr, rcvr)`'s constraints to a mandates, the `connect` customization point is now unconstrained.

But there is at least one place in the algorithms ([exec.let]) that is using `connect_result_t` in an immediate context of a function template with the expectation that connect_result_t<Sndr, Rcvr> will be well-formed only when `Sndr` and `Rcvr` can actually be connected. with the current definition, connect_result_t<Sndr, Rcvr> could very well cause a hard error; it will never cuase a substitution failure.

The solution is to constrain the `connect_result_t` alias template. Just as completion_signatures_of_t<Sndr, Env> is constrained with sender_in<Sndr, Env>, so too should connect_result_t<Sndr, Rcvr> be constrained with sender_to<Sndr, Rcvr>.

For reference, the `sender_to` concept is defined as follows:

template<class Sndr, class Rcvr>
    concept sender_to =
      sender_in<Sndr, env_of_t<Rcvr>> &&
      receiver_of<Rcvr, completion_signatures_of_t<Sndr, env_of_t<Rcvr>>> &&
      requires (Sndr&& sndr, Rcvr&& rcvr) {
        connect(std::forward<Sndr>(sndr), std::forward<Rcvr>(rcvr));
      };