4248. Late domain-based dispatching of schedule_from and continues_on are flipped

Section: 33.9.2 [exec.snd.expos] Status: New Submitter: Eric Niebler Opened: 2025-04-26 Last modified: 2025-06-12

Priority: 1

View other active issues in [exec.snd.expos].

View all other issues in [exec.snd.expos].

View all issues with New status.

Discussion:

The reason for having two different customization points for transitioning between two execution contexts is described in 33.9.2 [exec.snd.expos] bullet (14.1) Note 1, to wit:

[Note 1: The continues_on algorithm works in tandem with schedule_from (33.9.12.7 [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]

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 (33.9.12.6 [exec.continues.on]):

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 33.9.2 [exec.snd.expos] p14.1 says it does. And schedule_from(sch, sndr) is currently defined as (33.9.12.7 [exec.schedule.from]):

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.

[2025-06-12; Reflector poll]

Set priority to 1 after reflector poll.

"Names are a bit misleading but the change looks right."

Proposed resolution:

This wording is relative to N5008.

1. Modify 33.9.2 [exec.snd.expos] as indicated:

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

   -14- Effects: Equivalent to:

   1. (14.1) — If sender-for<Sndr, continues_on_tschedule_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_onschedule_from algorithm works in tandem with schedule_fromcontinues_on (33.9.12.7 [exec.schedule.from]33.9.12.6 [exec.continues.on]) to give scheduler authors a way to customize both how to transition onto (continues_onschedule_from) and off of (schedule_fromcontinues_on) a given execution context. Thus, continues_onschedule_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 continues_onschedule_from. That is why it is given special treatment here. — end note]

   2. […]