This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
schedule_from
and continues_on
are flippedSection: 33.9.2 [exec.snd.expos] Status: New Submitter: Eric Niebler Opened: 2025-04-26 Last modified: 2025-04-27
Priority: Not Prioritized
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 withschedule_from
(33.9.12.5 [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 tocontinues_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.
continues_on
and schedule_from
are reversed.
continues_on(sndr, sch)
is defined as (33.9.12.4 [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.5 [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 changeget-domain-late
to treat schedule_from
as special, not continues_on
.
Proposed resolution:
This wording is relative to N5008.
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:
(14.1) — If
sender-for<Sndr,
iscontinues_on_tschedule_from_t>true
, thenreturn 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
algorithm works in tandem with
continues_onschedule_from(
schedule_fromcontinues_on33.9.12.5 [exec.schedule.from]33.9.12.4 [exec.continues.on]) to give scheduler authors a way to customize both how to transition onto () and off of (
continues_onschedule_from) a given execution context. Thus,
schedule_fromcontinues_onignores 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]
continues_onschedule_from[…]