late domain-based dispatching of `schedule_from` and `continues_on` are flipped

[ericniebler]

The reason for having two different customization points for transitioning between two execution contexts is described in [exec.snd.expos]/p14.1, to wit:

The continues_on algorithm works in tandem with schedule_from ([exec.schedule.from]) to give scheduler authors a way to customize both how to transition onto (continues_on) and off of (schedule_from) a given execution context. Thus, continues_on ignores the domain of the predecessor and uses the domain of the destination scheduler to select a customization, a property that is unique to continues_on.

The exposition-only get-domain-late function treats continues_on senders specially to make sure the correct domain (that of the destination scheduler) is used to find customizations at connect time.

However, customizations are also searched for early when the sender is first constructed. And here the dispatching of continues_on and schedule_from are reversed.

continues_on( sndr, sch ) is defined as:

transform_sender(get-domain-early(sndr), make-sender(continues_on, sch, sndr))

which is using the domain of the predecessor rather than ignoring it as [exec.snd.expos]/p14.1] says it does. And schedule_from( sch, sndr ) is currently defined as:

transform_sender(
  query-or-default(get_domain, sch, default_domain()),
  make-sender(schedule_from, sch, sndr))

which is using the domain of the destination scheduler to find customizations. The logic for determining the domain to use for early customization of these two algorithms are opposite what they are for late customization. This is a bug. They should be consistent.

"Lazy" customization (at connect time) was added to P2300 later in the process, and this inconsistency was a mistake on my part. The correct thing to do is to change get-domain-late to treat schedule_from as special, not continues_on.

Proposed Resolution

Change [exec.snd.expos] p14 as follows:

     template<class Sndr, class Env>
       constexpr auto get-domain-late(const Sndr& sndr, const Env& env) noexcept;

 14.   Effects: Equivalent to:

-14.1  - If sender-for<Sndr, continues_on_t> is true, then
+14.1  - If sender-for<Sndr, schedule_from_t> is true, then

           return Domain();

         where Domain is the type of the following expression:

           [] {
             auto [_, sch, _] = sndr;
             return query-or-default(get_domain, sch, default_domain());
           }();

-        [Note 1: The continues_on algorithm works in tandem with schedule_from 
-        ([exec.schedule.from]) to give scheduler authors a way to customize both
-        how to transition onto (continues_on) and off of (schedule_from) a given
-        execution context. Thus, continues_on ignores the domain of the
-        predecessor and uses the domain of the destination scheduler to select a 
-        customization, a property that is unique to continues_on. That is why it
-        is given special treatment here. — end note]
+        [Note 1: The schedule_from algorithm works in tandem with continues_on 
+        ([exec.continues.on]) to give scheduler authors a way to customize both
+        how to transition onto (schedule_from) and off of (continues_on) a given
+        execution context. Thus, schedule_from ignores the domain of the
+        predecessor and uses the domain of the destination scheduler to select a 
+        customization, a property that is unique to schedule_from. That is why it
+        is given special treatment here. — end note]

[griwes]

Unless there was a change in the design that I missed, the spec is currently correct, and it is [exec.snd.expos]/p14.1 that has this backward. It should say continue_on allows customizing the transition off of a resource, and schedule_from alllws customizing the transition onto a resource.

Eric: this comment is no longer relevant