1 Background

In the current Working Draft, 33 [exec] has sender algorithms that are customizable. While the sender/receiver concepts and the algorithms themselves have been stable for several years now, the customization mechanism has seen a fair bit of recent churn. [P3718R0] is the latest effort to shore up the mechanism. Unfortunately, there are gaps in its proposed resolution. This paper details those gaps.

The problem and its solution are easy to describe, but the changes are not trivial. The fix has been implemented once, and another independent implementation is in progress at the time of writing. This paper proposes to fix the issue for C++26. Should the fix be deemed too risky, this paper also offers guidance on how to remove the ability to customize sender algorithms for C++26 in a way that permits us to add it back in C++29.

2 The problem with P3718

[P3718R0] identifies real problems with the status quo of sender algorithm customization. It proposes using information from the sender about where it will complete during “early” customization, which happens when a sender algorithm constructs and returns a sender; and it proposes using information from the receiver about where the operation will start during “late” customization, when the sender and the receiver are connected.

The problem with this separation of responsibilities is:

A simple example is the just() sender; it completes inline wherever it is started. The information about where a sender will start is not known during early customization, when the sender is being asked for this information.

And even if we knew where the sender will start, there is no generic interface for asking a sender where it will complete given where it will start. There currently is no such API, which is the whole problem in a nutshell.

2.1 An illustrative example

This section illustrates the above problem by walking through the algorithm selection process proposed by P3718. Consider the following example:

namespace ex = std::execution;
auto sndr = ex::starts_on(gpu, ex::just()) | ex::then(fn);
std::this_thread::sync_wait(std::move(sndr));

… where gpu is a scheduler that runs work (unsurprisingly) on a GPU.

fn will execute on the GPU, so a GPU implementation of then should be used. By the proposed resolution of P3718, algorithm customization proceeds as follows:

• During early customization, when starts_on(gpu, just()) | then(fn) is executing, the then CPO asks the starts_on(gpu, just()) sender where it will complete as if by:

  auto& [_, fn, child1] = *this; // *this is a then sender
                                 // child1 is a starts_on sender
  auto dom1 = ex::get_domain(ex::get_env(child1));

• The starts_on sender will in turn ask the just() sender, as if by:

  auto& [_, sch, child2] = *this;  // *this is a starts_on sender
                                   // child2 is a just sender
  auto dom2 = ex::get_domain(ex::get_env(child2));

  As discussed, the just() sender doesn’t know where it will complete until it knows where it will be started, but that information is not yet available. As a result, dom2 ends up as default_domain, which is then reported as the domain for the starts_on sender. That’s incorrect. The starts_on sender will complete on the GPU.

• The then CPO uses default_domain to find an implementation of the then algorithm, which will find the default implementation. As a result, the then CPO returns an ordinary then sender.

• When that then sender is connected to sync_wait’s receiver, late customization happens. connect asks sync_wait’s receiver where the then sender will be started. It does that with the query get_domain(get_env(rcvr)). sync_wait starts operations on the current thread, so the get_domain query will return default_domain. As with early customization, late customization will also not find a GPU implementation.

The end result of all of this is that a default (which is effectively a CPU) implementation will be used to evaluate the then algorithm on the GPU. That is a bad state of affairs.

3 Solutions considered

Here is a list of possible ways to address this problem for C++26, sorted in descending awfulness.

3.1 Remove all of the C++26 std::execution additions

Although the safest option, I hope most agree that such a drastic step is not warranted by this issue. Pulling the sender abstraction and everything that depends on it would result in the removal of:

• The sender/receiver-related concepts and customization points, without which the ecosystem will have no shared async abstraction, and which will set back the adoption of structured concurrency three years.

• The sender algorithms, which capture common async patterns and make them reusable,

• execution::counting_scope and execution::simple_counting_scope, and related features for incremental adoption of structured concurrency,

• execution::parallel_scheduler and all of its related APIs, and

• execution::task and execution::task_scheduler (C++26 will still not have a standard coroutine task type <heavy sigh>).

This option should only be considered if all the other options are determined to have unacceptable risk.

3.2 Remove all of the customizable sender algorithms

This option would keep all of the above library components with the exception of the customizable sender algorithms:

• then, upon_error, upon_stopped
• let_value, let_error, let_stopped
• bulk, bulk_chunked, bulk_unchunked
• starts_on, continues_on, on
• when_all, when_all_with_variant
• stopped_as_optional, stopped_as_error
• into_variant
• sync_wait
• affine_on

This would leave users with no easy standard way to start work on a given execution context, or transition to another execution context, or to execute work in parallel, or to wait for work to finish.

In fact, without the bulk algorithms, we leave no way for the parallel_scheduler to execute work in parallel!

While still delivering a standard async abstraction with minimal risk, the loss of the algorithms would make it just an abstraction. Like coroutines, adoption of senders as an async lingua franca will be hampered by lack of standard library support.

3.3 Remove sender algorithm customization

In this option, we ship everything currently in the Working Draft but remove the ability to customize the algorithms. This gives us a free hand to design a better customization mechanism for C++29 – provided we have confidence that those new customization hooks can be added without break existing behavior.

This option is not as low-risk as it may seem. Firstly, it is difficult to be confident that algorithm customization can be added back without breaking code. Improved customization hooks have been implemented, and wording for the removal has been written, to the best of the author’s ability, such that that the new hooks can be standardized without breaking changes.

Secondly, algorithm customizability is a load-bearing feature. Taking it out is not hard but it isn’t trivial either. Customizability is used by the parallel_scheduler to accelerate the bulk family of algorithms. Although the task_scheduler does not currently customize bulk, it should. Some design work is necessary before algorithm customization can be removed.

The section Removing algorithm customization describes the effects and possible remedies of the removal option.

3.4 Ship everything as-is and fix algorithm customization in a DR

This option is not as reckless as it sounds. We have a fix and the fix has been implemented in a working and publicly available execution library (CCCL). It would not be the first time the Committee shipped a standard with known defects, and the DR process exists for just this purpose.

One potential problem is that, as DRs go, this one would be large-ish. I do not know if this presents a problem procedurally. If it does, then fixing the problem now would make more sense. Any future DRs are likely to be smaller.

3.5 Fix algorithm customization now

This is the option this paper proposes. The fix is easy to describe:

That is done by passing the receiver’s environment when asking the sender for its completion domain. Instead of get_domain(get_env(sndr)), the query would be get_domain(get_env(sndr), get_env(rcvr)) (but with a query other than get_domain, read on).

That change has some ripple effects, the biggest of which is that the receiver is not known during early customization. Therefore, early customization is irreparably broken and must be removed.

There are other ripples from the proposed change. They are described in full detail in section Fixing algorithm customization.

There are risks with trying to fix the problem now. It is a design change happening uncomfortably close to the release of C++26. One mitigating factor is that it is unlikely that the fix would make things more broken than they already are. If there are lingering problems, they could be fixed with the usual DR process.

This fix has been implemented in NVIDIA’s CCCL library. At the time of writing a second implementation is being developed independently for stdexec, the std::execution reference implementation with an eye to having a few months deployment experience prior to the upcoming London meeting.

4 Fixing algorithm customization

Selecting the right implementation of an algorithm requires requires two things:

1. Identifying the starting and completing domain of the algorithm’s async operation, and

2. Using that information to select the preferred implementation for the algorithm that operation represents.

Let’s take these two separately.

4.1 Determining the starting and completing domains

As described in Fix algorithm customization now, so-called “early” customization, which determines the return type of then(sndr, fn) for example, is irreparably broken. It needs the sender to know where it will complete, which it can’t in general.

So the first step is to remove early customization. There is no plan to add it back later.

That leaves “late” customization, which is performed by the connect customization point. The receiver, which is an extension of caller, knows where the operation will start. If the sender is given this information – that is, if the sender is told where it will start – it can accurately report where it will complete. This is the key insight.

When connect queries a sender’s attributes for its completion domain, it should pass the receiver’s environment. That way a sender has all available information when computing its completion domain.

4.1.1 get_completion_domain

It is sometimes the case that a sender’s value and error completions can happen on different domains. For example, imagine trying to schedule work on a GPU. If it succeeds, you are in the GPU domain, Bob’s your uncle. If scheduling fails, however, the error cannot be reported on the GPU because we failed to make it there!

So asking a sender for a singular completion domain is not flexible enough.

When asking for a completion scheduler, we have three queries, one for each completion disposition: get_completion_scheduler<set_[value|error|stopped]_t>. Similarly, we should have three separate queries for a sender’s completion domain: get_completion_domain<set_[value|error|stopped]_t>.

The addition of the completion domain queries creates a nice symmetry as shown in the table below (with additions in green):

For a sender sndr and an environment env, we can get the sender’s completion domain as follows:

auto completion_domain = get_completion_domain<set_value_t>(get_env(sndr), env);

A sender like just() would implement this query as follows:

struct just_attrs
{
  auto query(get_completion_domain_t<set_value_t>, const auto& env) const noexcept
  {
    // an inline sender completes where it starts. the domain of the environment is where
    // the sender will start, so return that.
    return get_domain(env);
  }
  //...
};

template<class... Values>
struct just_sender
{
  //...
  auto get_env() const noexcept
  {
    return just_attrs{};
  }
  //...
};

Just as the get_completion_domain queries accept an optional env argument, so too should the get_completion_scheduler queries.

4.2 Algorithm dispatching in connect

With the addition of the get_completion_domain<*> queries that can accept the receiver’s environment, connect can now know the starting and completing domains of the async operation it is constructing. When passed arguments sndr and rcvr, the starting domain is:

// Get the operation's starting domain:
auto starting_domain = get_domain(get_env(rcvr));

To get the completion domain (when the operation completes successfully):

// Get the operation's completion domain for the value channel:
auto completion_domain = get_completion_domain<set_value_t>(get_env(sndr), get_env(rcvr));

Now connect has all the information it needs to select the correct algorithm implementation. Great!

But this presents the connect function with a dilemma: how does it use two domains to pick one algorithm implementation?

Consider that the starting domain might want a say in how start works, and the completing domain might want a say in how set_value works. So should we let the starting domain customize start and the completing domain customize set_value?

No. start and set_value are bookends around an async operation; they must match. Often set_value needs state that is set up in start. Customizing the two independently is madness.

4.2.1 Solving the double-dispatch problem

The solution is to use sender transforms. Each domain can apply its transform in turn. I do not have reason to believe the order matters, but it is important that when asked to transform a sender, a domain knows whether it is the “starting” domain or the “completing” domain.

Here is how a domain might customize bulk when it is the completing domain:

struct thread_pool_domain
{
  template<sender-for<bulk_t> Sndr, class Env>
  auto transform_sender(set_value_t, Sndr&& sndr, const Env& env) const
  {
    //...
  }
};

Since it has set_value_t as its first argument, this transform is only applied when thread_pool_domain is an operation’s completion domain. Had the first argument been start_t, the transform would only be used when thread_pool_domain is a starting domain.

4.2.2 transform_sender

In this proposed design, the connect CPO does a few things:

1. Determines the starting and completing domains,

2. Applies the completing domain’s transform (if any),

3. Applies the starting domain’s transform (if any) to the resulting sender,

4. Connnects the twice-transformed sender to the receiver.

The first three steps are doing something different than connecting a sender and receiver, so it makes sense to factor them out into their own utility. As it so happens we already have such a utility: transform_sender.

The proposal requires some changes to how transform_sender operates. This new transform_sender still accepts a sender and an environment, but it no longer accepts a domain. It computes the two domains and applies the two transforms, recursing if a transform changes the type of the sender.

A possible implementation of transform_sender is listed in Appendix A: Listing for updated transform_sender.

With the definition of transform_sender in Appendix A, connect(sndr, rcvr) is equivalent to transform_sender(sndr, get_env(rcvr)).connect(rcvr) (except rcvr is evaluated only once).

4.3 Revisiting the problematic example

Let’s see how this new approach addresses the problems noted in the motivating example above. The troublesome code is:

namespace ex = std::execution;
auto sndr = ex::starts_on(gpu, ex::just()) | ex::then(fn);
std::this_thread::sync_wait(std::move(sndr));

An illustrative example describes how the current design and the “fixed” one proposed in [P3718R0] go off the rails while determining the domain in which the function fn will execute, causing it to use a CPU implementation instead of a GPU one.

In the new design, when the then sender is being connected to sync_wait’s receiver, the starting domain will still be the default_domain, but when asking the sender where it will complete, the answer will be different. Let’s see how:

• When asked for its completion domain, the then sender will ask the starts_on sender where it will complete, as if by:

  auto& [_, fn, child1] = *this; // *this is a then sender
                                 // child1 is a starts_on sender
  auto dom1 = ex::get_completion_domain<ex::set_value_t>(ex::get_env(child1), ex::get_env(rcvr));

• In turn, the starts_on sender asks the just sender where it will complete, telling it where it will start. (This is the new bit.) It looks like:

  auto& [_, sch, child2] = *this;  // *this is a starts_on sender
                                   // child2 is a just sender
  // ask for the scheduler's completion domain:
  auto sch_dom = ex::get_completion_domain<ex::set_value_t>(sch, get_env(rcvr));
  // construct an env that reflects the fact that child2 will be started on sch:
  auto env2 = ex::env{ex::prop{ex::get_scheduler, sch},
                      ex::prop{ex::get_domain, sch_dom},
                      ex::get_env(rcvr)};
  // pass the new env when asking child2 for its completion domain:
  auto dom2 = ex::get_completion_domain<ex::set_value_t>(ex::get_env(child2), env2);

• The just sender, when asked where it will complete, will respond with the domain on which it is started. In other words, get_completion_domain<set_value_t>(get_env(just()), env2) will return get_domain(env2), which is sch_dom.

• Having correctly determined that the then sender will start on the default domain and complete on the GPU domain, connect can select the right implementation for the then algorithm. It does that by calling:

  return ex::transform_sender(forward<Sndr>(sndr), ex::get_env(rcvr)).connect(forward<Rcvr>(rcvr));

  The transform_sender call will execute the following (simplified):

  ex::default_domain().transform_sender(
    ex::start,
    gpu_domain().transform_sender(ex::set_value, sndr, ex::get_env(rcvr)),
    ex::get_env(rcvr))

  where gpu_domain is the domain of the gpu scheduler. The default_domain does not apply any transformation to then senders, so this expression reduces to:

  gpu_domain().transform_sender(ex::set_value, sndr, ex::get_env(rcvr))

  So, in the new customization scheme, the GPU domain gets a crack at transforming the then sender before it is connected to a receiver, as it should.

4.4 Customizing continues_on and schedule_from

One of the uglier parts of the current algorithm customization design is that it needs special case handling for the continues_on and schedule_from algorithms. The proposed design gives us an opportunity to clean this up significantly.

4.4.1 Background

In order to transition between two execution contexts, each of which may know nothing about the other, it is necessary to do it in two steps: a transition from a context to the default domain, and a transition from the default domain to another context. A scheduler can customize either or both of these two steps by customizing the continues_on and schedule_from algorithms.

The customization of continues_on is found using the completion domain of sndr, making it the sanctioned way to transition off of a context. schedule_from finds its customization using the domain of sch, making it useful for transitioning onto a context.

When not customized, connecting the sender continues_on(sndr, sch) performs a switcheroo and connects schedule_from(sch, sndr) instead. In that way, both the source and destination contexts get a say in how the execution transfer is mediated.

What if a domain wants to customize continues_on? Asking continues_on(sndr, sch) for its completion domain will yield the domain of sch, but continues_on wants to use the completion domain of sndr. The usual transform_sender mechanism does not seem to cut it.

This is handled in the current draft wording by making continues_on a special case in transform_sender. In [P3718R0], the special casing is replaced with a get_domain_override attribute query, by which the continues_on sender can force transform_sender to use a different domain.

Both of these solutions are hacks.

4.4.2 A simplification

A better way to solve this problem is to divide responsibilities differently between continues_on and schedule_from. Suppose that only continues_on transfers execution, and schedule_from does nothing and only exists so it can be customized. The continues_on customization point would look like:

constexpr pipeable-adaptor continues_on =
  []<class Sndr, class Sch>(this auto self, Sndr&& sndr, Sch sch)
  {
    return make-sender(self, sch, schedule_from(forward<Sndr>(sndr)));
  };

The schedule_from customization point would look like this:

constexpr auto schedule_from =
  []<class Sndr>(this auto self, Sndr&& sndr)
  {
    return make-sender(self, {}, forward<Sndr>(sndr));
  };

Semantically, schedule_from(sndr) is equivalent to sndr. Crucially, that means that schedule_from(sndr) has the same completion domain as sndr. And that makes schedule_from a great way to customize how to transition off of an execution context.

On the other hand, continues_on(sndr, sch) completes on the domain of sch, making it a great way to customize how to transition onto an execution context.

By splitting continues_on and schedule_from in this way, we obviate the need for any special cases or domain overrides. The usual transform_sender mechanism is sufficient.

In the CCCL project, I have implemented this design and ported my CUDA stream scheduler to use it. I needed to customize schedule_from for the CUDA stream scheduler to mediate the execution transfer from the GPU back to the CPU. Besides the bulk algorithms, schedule_from is the only algorithm the GPU scheduler needs to customize.

4.5 inline_scheduler improvements

The suggestion above to extend the get_completion_scheduler<*> query presents an intriguing possibility for the inline_scheduler: the ability for it to report the scheduler on which its scheduling operations complete!

Consider the sender schedule(inline_scheduler()). Ask it where it completes today and it will say, “I complete on the inline_scheduler.”, which isn’t terribly useful. However, if you ask it, “Where will you complete – and by the way you will be started on the parallel_scheduler?”, now that sender can report that it will complete on the parallel_scheduler.

The result is that code that uses the inline_scheduler will no longer cause the actual scheduler to be hidden.

This realization is the motivation behind the change to strike the get_completion_scheduler<set_value_t>(get_env(schedule(sch))) requirement from the scheduler concept. We want that expression to be ill-formed for the inline_scheduler. Instead, we want the following query to be well-formed:

get_completion_scheduler<set_value_t>(get_env(schedule(inline_scheduler())), get_env(rcvr))

That expression should be equivalent to get_scheduler(get_env(rcvr)), which says that the sender of inline_scheduler completes wherever it is started.

4.6 Indeterminate domains

When computing completion domains, it is sometimes the case that an operation can complete on domain A or domain B for a given disposition (value, error, or stopped). Imagine such a sender with an indeterminate completion domain for set_value. How does algorithm customization work in that case?

First, we recognize that very few algorithms will ever be customized; a given domain may only customize a handful. Given sndr | then(fn), there is no difficulty picking the implementation for then even if sndr can complete successfully on either domain A or B, provided neither domain customizes then.

That insight makes it advantageous for a sender to report all the domains on which it might complete for a particular completion channel. It can do that with a new domain type: indeterminate_domain<Domains...>, which looks like this:

template<class... Domains>
struct indeterminate_domain
{
  template<class Tag, class Sndr, class Env>
  static constexpr auto transform_sender(Tag, Sndr&& sndr, const Env& env)
  {
    // Mandates: for all D in Domains, the expression
    // D().transform_sender(Tag(), forward<Sndr>(sndr), env) is either ill-formed or else
    // has the same type as
    // default_domain().transform_sender(Tag(), forward<Sndr>(sndr), env)
    return default_domain().transform_sender(Tag(), forward<Sndr>(sndr), env);
  }
};

Given an environment e, a sender like when_all(sndrs...) would have a value completion domain of

COMMON-DOMAIN(COMPL-DOMAIN(set_value_t, sndrs, e)...)

where:

• COMPL-DOMAIN(T, S, E) is the type of get_completion_domain<T>(get_env(S), E) if that expression is well-formed, or indeterminate_domain<>() otherwise, and

• COMMON-DOMAIN(Ds...) is common_type_t<Ds...> if that expression is well-formed, and indeterminate_domain<Ds...> otherwise.

The final piece is to specialize common_type such that indeterminate_domain<As...> and indeterminate_domain<Bs...> have a common type of indeterminate_domain<As..., Bs...>, and such that common_type_t<indeterminate_domain<As...>, D> is indeterminate_domain<As..., D>.

4.7 The procedure for the fix

The steps for fixing algorithm customization are detailed below.

1. Remove the uses of transform_sender in the sender adaptor algorithm customization points (33.9.12 [exec.adapt]). Directly return the result of calling make-sender rather than passing it to transform_sender.

2. Remove the exposition-only helpers:

   • completion-domain (33.9.2 [exec.snd.expos]/8-9),
   • get-domain-early (33.9.2 [exec.snd.expos]/13), and
   • get-domain-late (33.9.2 [exec.snd.expos]/14).

3. Add the get_completion_domain queries:

   • get_completion_domain<set_value_t>
   • get_completion_domain<set_error_t>
   • get_completion_domain<set_stopped_t>

4. Change the get_completion_scheduler queries to accept an optional environment argument.

5. Make the get_domain(env) query smarter by falling back to the current scheduler’s domain if env.query(get_domain) is ill-formed, and falling back further to default_domain() if env does not have a current scheduler.

6. Restore the ability of env<...>::query to accept additional arguments.

7. Rename the current schedule_from algorithm to continues_on and change it to return make-sender(continues_on, sch, schedule_from(sndr)), where schedule_from is a new algorithm such that schedule_from(sndr) is equivalent to make-sender(schedule_from, {}, sndr).

8. Remove the (unused) transform_env function and the transform_env members of the sender algorithm CPOs and from default_domain.

9. Change transform_sender from transform_sender(Domain, Sndr, Env...) to transform_sender(Sndr, Env). Have it compute the sender’s starting and completing domains and apply their transforms to Sndr as shown in Appendix A: Listing for updated transform_sender.

10. Update the usages of transform_sender in connect and get_completion_signatures to reflect its new signature.

11. For the transform_sender member functions in the sender algorithm CPOs, add set_value_t, in the front of their parameter list. Parameterize the transform_sender member in default_domain with a leading Tag parameter.

12. Add a class template indeterminate_domain<Domains...> as described in Indeterminate domains.

13. Update the attributes of the sender algorithms to properly report their completion schedulers and completion domains given an optional env argument. Also update the inline_scheduler and its schedule-sender to compute their completion scheduler and domain from the extra env argument.

14. From the scheduler concept, replace the required expression

    { auto(get_completion_scheduler<set_value_t>(get_env(schedule(std::forward<Sch>(sch))))) }
        -> same_as<remove_cvref_t<Sch>>;

    with a semantic requirement that if the above expression is well-formed – which it is for the parallel_scheduler, the task_scheduler, and run_loop’s scheduler – then it shall compare equal to sch. (See inline_scheduler improvements for the motivation behind these changes.)

15. Simplify the on algorithm, which no longer needs to use write_env to make child operations aware of the current scheduler and domain.

4.8 Proposed wording, option 1: Fix algorithm customization

[ Editor's note: Introduce the notion of “execution domains” by changing 33.3 [exec.async.ops#1] as follows: ]

[ Editor's note: In 33.4 [execution.syn], make the following changes: ]

… as before …

namespace std::execution {
  // [exec.queries], queries
  struct get_domain_t { unspecified };
  struct get_scheduler_t { unspecified };
  struct get_delegation_scheduler_t { unspecified };
  struct get_forward_progress_guarantee_t { unspecified };
  template<class CPO>
    struct get_completion_scheduler_t { unspecified };
  template<class CPO>
    struct get_completion_domain_t { unspecified };
  struct get_await_completion_adaptor_t { unspecified };

  inline constexpr get_domain_t get_domain{};
  inline constexpr get_scheduler_t get_scheduler{};
  inline constexpr get_delegation_scheduler_t get_delegation_scheduler{};
  enum class forward_progress_guarantee;
  inline constexpr get_forward_progress_guarantee_t get_forward_progress_guarantee{};
  template<class CPO>
    constexpr get_completion_scheduler_t<CPO> get_completion_scheduler{};
  template<class CPO>
    constexpr get_completion_domain_t<CPO> get_completion_domain{};
  inline constexpr get_await_completion_adaptor_t get_await_completion_adaptor{};

  struct get_env_t { unspecified };
  inline constexpr get_env_t get_env{};

  template<class T>
    using env_of_t = decltype(get_env(declval<T>()));

  // [exec.prop], class template prop
  template<class QueryTag, class ValueType>
    struct prop;

  // [exec.env], class template env
  template<queryable... Envs>
    struct env;

  // [exec.domain.indeterminate], execution domains
  template<class... Domains>
    struct indeterminate_domain;

  // [exec.domain.default], execution domains
  struct default_domain;

… as before …

  template<sender Sndr>
    using tag_of_t = see below;

  // [exec.snd.transform], sender transformations
  template<class Domain, sender Sndr, queryable… Env>
      requires (sizeof...(Env) <= 1)
    constexpr sender decltype(auto) transform_sender(
      Domain dom, Sndr&& sndr, const Env&... env) noexcept(see below);

  // [exec.snd.transform.env], environment transformations
  template<class Domain, sender Sndr, queryable Env>
    constexpr queryable decltype(auto) transform_env(
      Domain dom, Sndr&& sndr, Env&& env) noexcept;

  // [exec.snd.apply], sender algorithm application
  template<class Domain, class Tag, sender Sndr, class... Args>
    constexpr decltype(auto) apply_sender(
      Domain dom, Tag, Sndr&& sndr, Args&&... args) noexcept(see below);

  // [exec.connect], the connect sender algorithm
  struct connect_t;
  inline constexpr connect_t connect{};

… as before …

[ Editor's note: Before subsection 33.5.1 [exec.fwd.env], insert a new subsection with stable name [exec.queries.expos] as follows: ]

[ Editor's note: Change [exec.get.domain] as follows: ]

execution​::​get_domain [exec.get.domain]

1. get_domain asks a queryable object for its associated execution domain tag.

2. The name get_domain denotes a query object. For a subexpression env, get_domain(env) is expression-equivalent to MANDATE-NOTHROW(D()), where D is the type of the first of the following expressions that is well-formed [ Editor's note: Reformatted as a list. ]

   • (2.1) MANDATE-NOTHROW(auto(AS-CONST(env).query(get_domain))

   • (2.2) get_completion_domain<set_value_t>(get_scheduler(env), HIDE-SCHED(env))

   • (2.3) default_domain()

3. forwarding_query(execution​::​get_domain) is a core constant expression and has value true.

[ Editor's note: Change subsection 33.5.6 [exec.get.scheduler] as follows: ]

1. get_scheduler asks a queryable object for its associated scheduler.

2. The name get_scheduler denotes a query object. For a subexpression env, get_scheduler(env) is expression-equivalent to

   get_completion_scheduler<set_value_t>(MANDATE-NOTHROW(AS-CONST(env).query(get_scheduler)), HIDE-SCHED(env))

   Mandates: If the expression above is well-formed, its type satisfies scheduler.

3. forwarding_query(execution​::​get_scheduler) is a core constant expression and has value true.

[ Editor's note: Change subsection 33.5.9 [exec.get.compl.sched] as follows: ]

execution​::​get_completion_scheduler [exec.get.compl.sched]

1. get_completion_scheduler<completion-tag> obtains the completion scheduler associated with a completion tag from a sender’s attributes.

2. For subexpression sch1 and pack envs, let sch2 be TRY-QUERY(sch, get_completion_scheduler<set_value_t>, envs...) and let QUERY-RECURSE(sch1, envs...) be expression-equivalent to QUERY-RECURSE(sch2, envs...) if that expression is well-formed and sch1 and sch2 have different types or compare unequal; otherwise, sch.

3. The name get_completion_scheduler denotes a query object template. For a subexpression q and pack envs, the expression get_completion_scheduler<completion-tag>(q, envs...) is ill-formed if completion-tag is not one of set_value_t, set_error_t, or set_stopped_t. Otherwise, get_completion_scheduler<completion-tag>(q, envs...) is expression-equivalent to

   MANDATE-NOTHROW(AS-CONST(q).query(get_completion_scheduler<completion-tag>))

   • (3.1) MANDATE-NOTHROW(RECURSE-QUERY(TRY-QUERY(q, get_completion_scheduler<completion-tag>, envs...), envs...)) if that expression is well-formed.

   • (3.2) Otherwise, auto(q) if the type of q satisfies scheduler and sizeof...(envs) != 0 is true.

   • (3.3) Otherwise, get_completion_scheduler<completion-tag>(q, envs...) is ill-formed.

   Mandates: If the expression above get_completion_scheduler<completion-tag>(q, envs...) is well-formed, its type satisfies scheduler.

4. For a type Tag, subexpression sndr, and pack env, let CS be completion_signatures_of_t<decay_t<decltype((sndr))>, decltype((env))...>. If both get_completion_scheduler<Tag>(get_env(sndr), env...) and CS are well-formed and CS().count-of(Tag()) == 0 is true, the program is ill-formed.

5. Let completion-fn be a completion function ([exec.async.ops]); let completion-tag be the associated completion tag of completion-fn; let args and envs be a packs of subexpressions; and let sndr be a subexpression such that sender<decltype((sndr))> is true and get_completion_scheduler<completion-tag>(get_env(sndr), envs...) is well-formed and denotes a scheduler sch. If an asynchronous operation created by connecting sndr with a receiver rcvr causes the evaluation of completion-fn(rcvr, args...), the behavior is undefined unless the evaluation happens on an execution agent that belongs to sch’s associated execution resource.

6. The expression forwarding_query(get_completion_scheduler<completion-tag>) is a core constant expression and has value true.

[ Editor's note: After subsection 33.5.9 [exec.get.compl.sched], add a new subsection with stable name [exec.get.compl.domain] as follows. ]

[ Editor's note: In 33.6 [exec.sched], change paragraphs 1, 5, and 6 as follows: ]

1. The scheduler concept defines the requirements of a scheduler type (33.3 [exec.async.ops]). schedule is a customization point object that accepts a scheduler. A valid invocation of schedule is a schedule-expression.

   namespace std::execution {
     template<class Sch>
       concept scheduler =
         derived_from<typename remove_cvref_t<Sch>::scheduler_concept, scheduler_t> &&
         queryable<Sch> &&
         requires(Sch&& sch) {
           { schedule(std::forward<Sch>(sch)) } -> sender;
           { auto(get_completion_scheduler<set_value_t>(
               get_env(schedule(std::forward<Sch>(sch))))) }
                 -> same_as<remove_cvref_t<Sch>>;
         } &&
         equality_comparable<remove_cvref_t<Sch>> &&
         copyable<remove_cvref_t<Sch>>;
   }

… as before …

5. For a given scheduler expression sch, if the expression get_completion_scheduler<set_value_t>(get_env(schedule(sch))) is well-formed, it shall compare equal to sch.

6. For a given scheduler expression sch and pack of subexpressions env, if the expression get_completion_domain<completion-tag>(sch, env...) is well-formed, then the expression get_completion_domain<completion-tag>(get_env(schedule(sch)), env...) is also well-formed and has the same type.

5. For a given scheduler expression sch and pack of subexpressions env, if the expression get_completion_scheduler<completion-tag>(sch, env...) is well-formed, then the expression get_completion_scheduler<completion-tag>(get_env(schedule(sch)), env...) is also well-formed and has the same type and value.

[ Editor's note: Change 33.9.2 [exec.snd.expos] paragraph 3 as follows: ]

3. For a query object q and, a subexpression v, and a pack of subexpressions as, MAKE-ENV(q, v) is an expression env whose type satisfies queryable such that the result of env.query(q, as...) has a value equal to v (18.2 [concepts.equality]). Unless otherwise stated, the object to which env.query(q, as...) refers remains valid while env remains valid.

[ Editor's note: Before 33.9.2 [exec.snd.expos] paragraph 6, add two new paragraph as follows: ]

6. For a pack of subexpressions domains, COMMON-DOMAIN(domains...) is expression-equivalent to common_type_t<decltype(auto(domains))...>() if that expression is well-formed, and indeterminate_domain<Ds...>() otherwise, where Ds is the pack of types consisting of decltype(auto(domains))... with duplicate types removed.

7. For type Tag, subexpression, sndr and pack env, COMPL-DOMAIN(Tag, sndr, env) is expression-equivalent to D() where D is the type of get_completion_domain<Tag>(get_env(sndr), env...) if that expression is well-formed or if sizeof...(env) == 0 is true, and indeterminate_domain() otherwise.

[ Editor's note: Replace 33.9.2 [exec.snd.expos] paragraph 6 about SCHED-ATTRS and SCHED-ENV with the following paragraphs: ]

8. For unqualified type Tag and subexpressions sch, sndr, and pack as, SCHED-ATTRS(sch, sndr) is an expression o whose type satisfies queryable such that o.query(Tag(), as...) is expression-equivalent to:

   • (8.1) Tag()(sch, as...) if Tag is a specialization of get_completion_scheduler_t or get_completion_domain_t and either of the following is true:

     • (8.1.1) The template parameter of Tag is set_value_t, or

     • (8.1.2) never-completes-with<Sndr, completion-tag, decltype(as)...> is true, where completion-tag is the template parameter of Tag, and Sndr is decay_t<decltype((sndr))>.

   • (8.2) D() if Tag is get_completion_domain_t<completion-tag>, where D is the type of the expression

     COMMON-DOMAIN(COMPL-DOMAIN(completion-tag, sndr, as...),
                   COMPL-DOMAIN(completion-tag, schedule(sch), FWD-ENV(as)...))

   • (8.3) Otherwise, FWD-ENV(get_env(sndr)).query(Tag(), as...) if either of the following is true:

     • (8.3.1) Tag is not a specialization of get_completion_scheduler_t or get_completion_domain_t, or

     • (8.3.2) never-completes-with<schedule_result_t<decltype((sch))>, completion-tag, decltype(as)...> is true, where completion-tag is the template parameter of Tag.

   • (8.4) Otherwise, the expression o.query(Tag(), as...) is ill-formed.

9. For a scheduler sch, SCHED-ENV(sch) is an expression o whose type satisfies queryable such that

   • (9.1) o.query(get_scheduler) is a prvalue with the same type and value as sch,

   • (9.2) o.query(get_domain) is expression-equivalent to sch.query(get_domain) if that expression is well-formed, and default_domain() otherwise.

[ Editor's note: Remove the prototype of the exposition-only completion-domain function just before 33.9.2 [exec.snd.expos] paragraph 8, and with it remove paragraphs 8 and 9, which specify the function’s behavior. ]

[ Editor's note: Remove 33.9.2 [exec.snd.expos] paragraphs 13 and 14 and the prototypes for the get-domain-early and get-domain-late functions. ]

[ Editor's note: After 33.9.2 [exec.snd.expos] paragraph 47 (not-a-sender), add the following new paragraph ]

48. struct not-a-scheduler {
      using scheduler_concept = scheduler_t;
    
      constexpr auto schedule() const noexcept {
        return not-a-sender();
      }
    };

[ Editor's note: Add the following new paragraphs after 33.9.2 [exec.snd.expos] paragraph 50 as follows: ]

51. template<class Sndr, class SetTag, class... Env>
      concept never-completes-with = requires {
        requires (0 == get_completion_signatures<Sndr, Env...>().count-of(SetTag()));
      };

template<class Fn, class Default, class... Args>
  constexpr auto call-with-default(Fn&& fn, Default&& value, Args&&... args) noexcept(see below);

52. Let e be the expression std::forward<Fn>(fn)(std::forward<Args>(args)...) if that expression is well-formed; otherwise, it is static_cast<Default>(std​::​forward<Default>(value)).

53. Returns: e.

54. Remarks: The expression in the noexcept clause is noexcept(e).

55. template<class Tag>
      struct inline-attrs {
        see below
      };

56. For a subexpression env, inline-attrs<Tag>{}.query(get_completion_scheduler<Tag>, env) is expression-equivalent to get_scheduler(env).

57. For a subexpression env, inline-attrs<Tag>{}.query(get_completion_domain<Tag>, env) is expression-equivalent to get_domain(env).

[ Editor's note: Add a new subsection before [exec.domain.default] with stable name [exec.domain.indeterminate] as follows: ]

33.9.? execution::indeterminate_domain [exec.domain.indeterminate]

namespace std::execution {
  template<class... Domains>
    struct indeterminate_domain {
      indeterminate_domain() = default;
      constexpr indeterminate_domain(auto&&) noexcept {}

      template<class Tag, sender Sndr, queryable Env>
        static constexpr sender decltype(auto) transform_sender(Tag, Sndr&& sndr, const Env& env)
          noexcept(see below);
    };
}

template<class Tag, sender Sndr, queryable Env>
  static constexpr sender decltype(auto) transform_sender(Tag, Sndr&& sndr, const Env& env)
    noexcept(see below);

2. Mandates: For each type D in Domains..., the expression D().transform_sender(Tag(), std::forward<Sndr>(sndr), env) is either ill-formed or has the same decayed type as default_domain().transform_sender(Tag(), std::forward<Sndr>(sndr), env).

3. Returns: default_domain().transform_sender(Tag(), std::forward<Sndr>(sndr), env)

4. Remarks: For a pack of types Ds, common_type_t<indeterminate_domain<Domains...>, indeterminate_domain<Ds...>> is indeterminate_domain<Us...> where Us is the pack of types in Domains..., Ds... except with duplicate types removed. For a type D that is not a specialization of indeterminate_domain, common_type_t<indeterminate_domain<Domains...>, D> is D if sizeof...(Domains) == 0 is true, and common_type_t<indeterminate_domain<Domains...>, indeterminate_domain<D>> otherwise.

[ Editor's note: Change 33.9.5 [exec.domain.default] as follows: ]

33.9.5 execution​::​default_domain [exec.domain.default]

namespace std::execution {
  struct default_domain {
    template<class Tag, sender Sndr, queryable... Env>
        requires (sizeof...(Env) <= 1)
      static constexpr sender decltype(auto) transform_sender(Tag, Sndr&& sndr, const Env&... env)
        noexcept(see below);

    template<sender Sndr, queryable Env>
      static constexpr queryable decltype(auto) transform_env(Sndr&& sndr, Env&& env) noexcept;

    template<class Tag, sender Sndr, class... Args>
      static constexpr decltype(auto) apply_sender(Tag, Sndr&& sndr, Args&&... args)
        noexcept(see below);
  };
}

template<class Tag, sender Sndr, queryable... Env>
    requires (sizeof...(Env) <= 1)
  static constexpr sender decltype(auto) transform_sender(Tag, Sndr&& sndr, const Env&... env)
    noexcept(see below);

2. Let e be the expression

   tag_of_t<Sndr>().transform_sender(Tag(),std::forward<Sndr>(sndr), env...)

   if that expression is well-formed; otherwise, static_cast<Sndr>(std​::​forward<Sndr>(sndr)). [ Editor's note: See https://cplusplus.github.io/LWG/issue4368 ]

3. Returns: e.

4. Remarks: The exception specification is equivalent to noexcept(e).

template<sender Sndr, queryable Env>
  constexpr queryable decltype(auto) transform_env(Sndr&& sndr, Env&& env) noexcept;

5. Let e be the expression

   tag_of_t<Sndr>().transform_env(std::forward<Sndr>(sndr), std::forward<Env>(env))

   if that expression is well-formed; otherwise, FWD-ENV(std​::​forward<Env>(env)).

6. Mandates: noexcept(e) is true.

7. Returns: e.

template<class Tag, sender Sndr, class... Args>
constexpr decltype(auto) apply_sender(Tag, Sndr&& sndr, Args&&... args)
  noexcept(see below);

8. Let e be the expression

   Tag().apply_sender(std::forward<Sndr>(sndr), std::forward<Args>(args)...)

9. Constraints: e is a well-formed expression.

10. Returns: e.

11. Remarks: The exception specification is equivalent to noexcept(e).

[ Editor's note: Change 33.9.6 [exec.snd.transform] as follows: ]

execution::transform_sender [exec.snd.transform]

namespace std::execution {
  template<class Domain, sender Sndr, queryable... Env>
      requires (sizeof...(Env) <= 1)
    constexpr sender decltype(auto) transform_sender(Domain dom, Sndr&& sndr, const Env&... env)
      noexcept(see below);
}

1. For a subexpression s, let domain-for(start, s) be D() where D is the decayed type of get_domain(env) if that expressions that is well-formed, and default_domain otherwise.

2. Let domain-for(set_value, s) be D() where D is the decayed type of get_completion_domain<set_value_t>(get_env(sndr), env) if that is well-formed, and default_domain otherwise.

3. Let transformed-sndr(dom, tag, s) be the expression

   dom.transform_sender(std::forward<Sndr>(sndr), env...)
   dom.transform_sender(tag, s, env)

   if that expression is well-formed; otherwise,

   default_domain().transform_sender(std::forward<Sndr>(sndr), env...)
   default_domain().transform_sender(tag, s, env)

   Let final-sndr transform-recurse(dom, tag, s) be the expression transformed-sndr(dom, tag, s) if transformed-sndr(dom, tag, s) and sndr s have the same type ignoring cv-qualifiers; otherwise, it is the expression transform_sender(dom, transformed-sndr, env...) transform-recurse(dom2, tag, s2) where s2 is transformed-sender(dom, tag, s) and d2 is domain-for(tag, s2).

   Let tmp-sndr be the expression

   transform-recurse(domain-for(set_value, sndr), set_value, sndr)

   and let final-sndr be the expression

   transform-recurse(domain-for(start, tmp-sndr), start, tmp-sndr)

4. Returns: final-sndr.

5. Remarks: The exception specification is equivalent to noexcept(final-sndr).

[ Editor's note: Remove section 33.9.7 [exec.snd.transform.env]. ]

[ Editor's note: Change 33.9.9 [exec.getcomplsigs] paragraph 1 as follows: ]

template<class Sndr, class... Env>
  consteval auto get_completion_signatures() -> valid-completion-signatures auto;

1. Let except be an rvalue subexpression of an unspecified class type Except such that move_constructible<Except> && derived_from<Except, exception> is true. Let CHECKED-COMPLSIGS(e) be e if e is a core constant expression whose type satisfies valid-completion-signatures; otherwise, it is the following expression: (e, throw except, completion_signatures()) Let get-complsigs<Sndr, Env...>() be expression-equivalent to remove_reference_t<Sndr>​::​template get_completion_signatures<Sndr, Env...>(). Let NewSndr be Sndr if sizeof...(Env) == 0 is true; otherwise, decltype(s) where s is the following expression:

   transform_sender(
     get-domain-late(declval<Sndr>(), declval<Env>()...),
     declval<Sndr>(),
     declval<Env>()...)

[ Editor's note: Change 33.9.10 [exec.connect] paragraph 2 as follows: ]

2. The name connect denotes a customization point object. For subexpressions sndr and rcvr, let Sndr be decltype((sndr)) and Rcvr be decltype((rcvr)), let new_sndr be the expression

   transform_sender(decltype(get-domain-late(sndr, get_env(rcvr))){}, sndr, get_env(rcvr))

   and let DS and DR be decay_t<decltype((new_sndr))> and decay_t<Rcvr>, respectively.

[ Editor's note: Remove 33.9.11.1 [exec.schedule] paragraph 4 as follows: ]

4. If the expression

   get_completion_scheduler<set_value_t>(get_env(sch.schedule())) == sch

   is ill-formed or evaluates to false, the behavior of calling schedule(sch) is undefined.

[ Editor's note: Change 33.9.11.2 [exec.just] paragraph 2 as follows: ]

2. The names just, just_error, and just_stopped denote customization point objects. Let just-cpo be one of just, just_error, or just_stopped. For a pack of subexpressions ts, let Ts be the pack of types decltype((ts)). The expression just-cpo(ts...) is ill-formed if

   • (2.1) (movable-value<Ts> &&...) is false, or

   • (2.2) just-cpo is just_error and sizeof...(ts) == 1 is false, or

   • (2.3) just-cpo is just_stopped and sizeof...(ts) == 0 is false.

   Otherwise, it is expression-equivalent to make-sender(just-cpo, product-type{ts...}).

   For just, just_error, and just_stopped, let set-cpo be set_value, set_error, and set_stopped, respectively. The exposition-only class template impls-for (33.9.2 [exec.snd.expos]) is specialized for just-cpo as follows:

   namespace std::execution {
     template<>
     struct impls-for<decayed-typeof<just-cpo>> : default-impls {
       static constexpr auto get-attrs =
         [](const auto& data) noexcept -> inline-attrs<decayed-typeof<set-cpo>> {
           return {};
         };
   
       static constexpr auto start =
         [](auto& state, auto& rcvr) noexcept -> void {
           auto& [...ts] = state;
           set-cpo(std::move(rcvr), std::move(ts)...);
         };
     };
   }

[ Editor's note: Change 33.9.11.3 [exec.read.env] paragraph 3 as follows: ]

3. The exposition-only class template impls-for (33.9.2 [exec.snd.expos]) is specialized for read_env as follows:

   namespace std::execution {
     template<>
     struct impls-for<decayed-typeof<read_env>> : default-impls {
       static constexpr auto get-attrs =
         [](const auto& data) noexcept -> inline-attrs<set_value_t> {
           return {};
         };
   
       static constexpr auto start =
         [](auto query, auto& rcvr) noexcept -> void {
           TRY-SET-VALUE(rcvr, query(get_env(rcvr)));
         };
     };
   
     template<class Sndr, class Env>
       static consteval void check-types();
   }

[ Editor's note: Change 33.9.12.5 [exec.starts.on] paragraphs 3 and 4, and insert a new paragraph 5 as follows: ]

3. Otherwise, the expression starts_on(sch, sndr) is expression-equivalent to:

   transform_sender(
     query-with-default(get_domain, sch, default_domain()),
     make-sender(starts_on, sch, sndr))

   except that sch is evaluated only once.

4. Let out_sndr and env be subexpressions such that OutSndr is decltype((out_sndr)). If sender-for<OutSndr, starts_on_t> is false, then the expressions starts_on.transform_env(out_sndr, env) and starts_on.transform_sender(set_value,out_sndr, env) areis ill-formed; otherwise

   • (4.1) starts_on.transform_env(out_sndr, env) is equivalent to:

   auto&& [_, sch, _] = out_sndr;
   return JOIN-ENV(SCHED-ENV(sch), FWD-ENV(env));

   • (4.2) starts_on.transform_sender(set_value,out_sndr, env) is equivalent to:

   auto&& [_, sch, sndr] = out_sndr;
   return let_value(
     schedule(sch),
     continues_on(just(), sch),
     [sndr = std::forward_like<OutSndr>(sndr)]() mutable
       noexcept(is_nothrow_move_constructible_v<decay_t<OutSndr>>) {
       return std::move(sndr);
     });

5. The exposition-only class template impls-for is specialized for starts_on_t as follows:

   namespace std::execution {
     template<>
     struct impls-for<starts_on_t> : default-impls {
       static constexpr auto get-attrs =
         [](const auto& sch, const auto& child) noexcept -> decltype(auto) {
           return see below;
         };
     };
   }

   For subexpressions sch and child and pack of subexpressions env, let sch2 be get_completion_scheduler<set_value_t>(sch, env...), and let env2 be the pack JOIN-ENV(SCHED-ENV(sch2), env). impls-for<starts_on_t>::get-attrs(sch, child) returns an object attrs such that

   • (5.1) attrs.query(get_completion_scheduler<completion-tag>, env...) is expression-equivalent to get_completion_scheduler<completion-tag>(get_env(child), env2...).

   • (5.2) attrs.query(get_completion_domain<completion-tag>, env...) is expression-equivalent to get_completion_domain<completion-tag>(get_env(child), env2...).

   • (5.3) For a subexpression q and pack args, attrs.query(q, args...) is expression-equivalent to FWD-ENV(get_env(child)).query(q, args...) where the type of q is not a specialization of either get_completion_scheduler_t or get_completion_domain_t.

[ Editor's note: Remove subsection 33.9.12.6 [exec.continues.on] ]

[ Editor's note: Change stable name 33.9.12.7 [exec.schedule.from] to [exec.continues.on], and change the subsection as follows: ]

33.9.12.76 execution::schedule_fromcontinues_on [exec.schedule.from.continues.on]

1. schedule_fromcontinues_on schedules work dependent on the completion of a sender onto a scheduler’s associated execution resource.

   [Note 1: schedule_from is not meant to be used in user code; it is used in the implementation of continues_on. — end note]

2. The name schedule_fromcontinues_on denotes a customization point object. For some subexpressions sch and sndr, let Sch be decltype((sch)) and Sndr be decltype((sndr)). If Sch does not satisfy scheduler, or Sndr does not satisfy sender, schedule_from(sch, sndr)continues_on(sndr, sch) is ill-formed.

3. Otherwise, the expression schedule_from(sch, sndr)continues_on(sndr, sch) is expression-equivalent to: make-sender(continues_on, sch, schedule_from(sndr))

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

   except that sch is evaluated only once.

4. The exposition-only class template impls-for (33.9.1 [exec.snd.general]) is specialized for schedule_from_tcontinues_on_t as follows:

   namespace std::execution {
      template<>
      struct impls-for<schedule_from_tcontinues_on_t> : default-impls {
         static constexpr auto get-attrs = see below;
         static constexpr auto get-state = see below;
         static constexpr auto complete = see below;
   
         template<class Sndr, class... Env>
           static consteval void check-types();
      };
   }

5. The member impls-for<schedule_from_tcontinues_on_t>​::​get-attrs is initialized with a callable object equivalent to the following lambda:

   [](const auto& data, const auto& child) noexcept -> decltype(auto) {
     return JOIN-ENV(SCHED-ATTRS(data), FWD-ENV(get_env(child)));
     return SCHED-ATTRS(data, child);
   }

6. The member impls-for<schedule_from_tcontinues_on_t>​::​get-state is initialized with a callable object equivalent to the following lambda:

   … as before …

… as before …

12. The member impls-for<schedule_from_tcontinues_on_t>​::complete is initialized with a callable object equivalent to the following lambda:

    … as before …

13. Let out_sndr be a subexpression denoting a sender returned from schedule_from(sch, sndr)continues_on(sndr, sch) or one equal to such, and let OutSndr be the type decltype((out_sndr)). Let out_rcvr be … as before …

[ Editor's note: After 33.9.12.6 [exec.continues.on], add a new subsection with stable name [exec.schedule.from] as follows: ]

execution::schedule_from [exec.schedule.from]

1. schedule_from offers scheduler authors a way to customize how to transition off of their schedulers’ associated execution contexts.

   [ Note:  schedule_from is not meant to be used in user code; it is used in the implementation of continues_on. — end note ]

2. The name schedule_from denotes a customization point object. For some subexpression sndr, if decltype(sndr) does not satisfy sender, schedule_from(sndr) is ill-formed.

3. Otherwise, the expression schedule_from(sndr) is expression-equivalent to make-sender(schedule_from, {}, sndr).

[ Editor's note: Change 33.9.12.8 [exec.on] as follows: ]

execution::on [exec.on]

1. The on sender adaptor has two forms … as before …

2. The name on denotes a … as before …

3. Otherwise, if decltype((sndr)) satisfies sender, the expression on(sch, sndr) is expression-equivalent to:

   transform_sender(
     query-with-default(get_domain, sch, default_domain()),
     make-sender(on, sch, sndr))

   except that sch is evaluated only once.

4. For subexpressions sndr, sch, and closure, if

   • (4.1) decltype((sch)) does not satisfy scheduler, or
   • (4.2) decltype((sndr)) does not satisfy sender, or
   • (4.3) closure is not a pipeable sender adaptor closure object (33.9.12.2 [exec.adapt.obj]),

   the expression on(sndr, sch, closure) is ill-formed; otherwise, it is expression-equivalent to:

   transform_sender(
     get-domain-early(sndr),
     make-sender(on, product-type{sch, closure}, sndr))

   except that sndr is evaluated only once.

5. Let out_sndr and env be subexpressions, let OutSndr be decltype((out_sndr)), and let Env be decltype((env)). If sender-for<OutSndr, on_t> is false, then the expressions on.transform_env(out_sndr, env) and on.transform_sender(set_value,out_sndr, env) areis ill-formed.

6. Otherwise: Let not-a-scheduler be an unspecified empty class type.

7. The expression on.transform_env(out_sndr, env) has effects equivalent to:

   auto&& [_, data, _] = out_sndr;
   if constexpr (scheduler<decltype(data)>) {
     return JOIN-ENV(SCHED-ENV(std::forward_like<OutSndr>(data)), FWD-ENV(std::forward<Env>(env)));
   } else {
     return std::forward<Env>(env);
   }

8. Otherwise, Tthe expression on.transform_sender(set_value,out_sndr, env) has effects equivalent to:

   auto&& [_, data, child] = out_sndr;
   if constexpr (scheduler<decltype(data)>) {
     auto orig_sch =
       query-with-default(get_scheduler, env, not-a-scheduler());
   
     if constexpr (same_as<decltype(orig_sch), not-a-scheduler>) {
       return not-a-sender{};
     } else {
       return continues_on(
         starts_on(std::forward_like<OutSndr>(data), std::forward_like<OutSndr>(child)),
         std::move(orig_sch));
     }
   } else {
     auto& [sch, closure] = data;
     auto orig_sch = query-with-default(
       get_completion_scheduler<set_value_t>,
       get_env(child),
       query-with-default(get_scheduler, env, not-a-scheduler()));
   
     if constexpr (same_as<decltype(orig_sch), not-a-scheduler>) {
       return not-a-sender{};
     } else {
       return write_env(
         continues_on(
           std::forward_like<OutSndr>(closure)(
             continues_on(
               write_env(std::forward_like<OutSndr>(child), SCHED-ENV(orig_sch)),
               sch)),
           orig_sch),
         SCHED-ENV(sch));
     }
   }

   auto&& [_, data, child] = out_sndr;
   if constexpr (scheduler<decltype(data)>) {
     auto orig_sch =
       call-with-default(get_scheduler, not-a-scheduler(), env);
   
     return continues_on(
       starts_on(std::forward_like<OutSndr>(data), std::forward_like<OutSndr>(child)),
       std::move(orig_sch));
   } else {
     auto& [sch, closure] = data;
     auto orig_sch = call-with-default(
       get_completion_scheduler<set_value_t>, not-a-scheduler(), get_env(child), env);
   
     return continues_on(
       std::forward_like<OutSndr>(closure)(continues_on(std::forward_like<OutSndr>(child), sch)),
       orig_sch);
   }

9. The exposition-only class template impls-for (33.9.2 [exec.snd.expos]) is specialized for on_t as follows:

   namespace std::execution {
     template<>
     struct impls-for<on_t> : default-impls {
       static constexpr auto get-attrs =
         [](const auto& data, const auto& child) noexcept {
           return see below;
         };
     };
   }

   Given a pack of subexpressions env, let Env be the pack decltype(env), let Data be the decayed type of data, let sndr be a const lvalue reference to the basic-sender object that owns the objects to which data and child refer, and let new_attrs be a queryable object equal to get_env(on.transform_sender(set_value, sndr_copy, env...)) where sndr_copy is a hypothetical non-const object equal to sndr. The above lambda returns an object attrs such that, for a query object q and pack of subexpressions as, attrs.query(q, as...) is ill-formed if new_attrs.query(q, as...) is ill-formed; otherwise, it has the same type and value as new_attrs.query(q, as...).

   Recommended practice: Implementations should compute the results of queries without actually calling on_t::transform_sender.

[ Editor's note: Change 33.9.12.9 [exec.then] paragraphs 3 and 4 and add a new paragraph as follows: ]

3. Otherwise, the expression then-cpo(sndr, f) is expression-equivalent to:

   transform_sender(get-domain-early(sndr), make-sender(then-cpo, f, sndr))

   except that sndr is evaluated only once.

4. For then, upon_error, and upon_stopped, let set-cpo be set_value, set_error, and set_stopped, respectively. The exposition-only class template impls-for (33.9.2 [exec.snd.expos]) is specialized for then-cpo as follows:

   namespace std::execution {
     template<>
     struct impls-for<decayed-typeof<then-cpo>> : default-impls {
       static constexpr auto get-attrs =
         [](const auto& data, const auto& child) { return see below; };
   
       static constexpr auto complete = … as before …;
   
       template<class Sndr, class... Env>
         static consteval void check-types();
     };
   }

5. Let q be a query object and let as be a pack of subexpressions. For subexpressions child and fn, impls-for<decayed-typeof<then-cpo>>::get-attrs(fn, child) returns an object o whose type satisfies queryable such that o.query(q, as...) is expression-equivalent to:

   • (5.1) D() if q is get_completion_domain<set_value_t>, where D is the type of the expression

     COMMON-DOMAIN(COMPL-DOMAIN(decayed-typeof<set-cpo>, child, FWD-ENV(as)...),
                   COMPL-DOMAIN(set_value_t, child, FWD-ENV(as)...))

   • (5.2) D() if q is get_completion_domain<set_error_t> and gather-signatures<decayed-typeof<set-cpo>, CS, is-nothrow, conjunction>::value is false, where CS is completion_signatures_of_t<decay_t<decltype((child))>, FWD-ENV-T(decltype((as)))...>; is-nothrow is an alias template such that for a pack of types Ts, is-nothrow<Ts...> is is_nothrow_invocable<decay_t<decltype((fn))>, Ts...>; and D is the type of the expression

     COMMON-DOMAIN(COMPL-DOMAIN(decayed-typeof<set-cpo>, child, FWD-ENV(as)...),
                   COMPL-DOMAIN(set_error_t, child, FWD-ENV(as)...))

   • (5.3) Otherwise, FWD-ENV(get_env(child)).query(q, as...) if either of the following is true:

     • (5.2.1) q is get_completion_scheduler<set_value_t> and set-cpo is set_value, or

     • (5.2.2) q is not get_completion_domain<decayed-typeof<set-cpo>> or get_completion_scheduler<decayed-typeof<set-cpo>>.

   • (5.4) Otherwise, o.query(q, as...) is ill-formed.

[ Editor's note: Change 33.9.12.10 [exec.let] as follows: ]

1. let_value, let_error, and let_stopped … as before …

2. For let_value, let_error, and let_stopped, let set-cpo be set_value, set_error, and set_stopped, respectively. Let the expression let-cpo be one of let_value, let_error, or let_stopped. For a subexpressions sndr and env, let let-env(sndr, env) be expression-equivalent to the first well-formed expression below:

   • (2.1) SCHED-ENV(get_completion_scheduler<decayed-typeof<set-cpo>>(get_env(sndr), FWD-ENV(env)))
   • (2.2) MAKE-ENV(get_domain, get_domain(get_env(sndr)))
   • (2.2) MAKE-ENV(get_domain, get_completion_domain<decayed-typeof<set-cpo>>(get_env(sndr), FWD-ENV(env)))
   • (2.3) (void(sndr), env<>{})

3. The names let_value, let_error, and let_stopped denote … as before …

4. Otherwise, the expression let-cpo(sndr, f) is expression-equivalent to:

   transform_sender(get-domain-early(sndr), make-sender(let-cpo, f, sndr))

   except that sndr is evaluated only once.

5. The exposition-only class template impls-for (33.9.2 [exec.snd.expos]) is specialized for let-cpo as follows:

   namespace std::execution {
     template<class State, class Rcvr, class... Args>
     void let-bind(State& state, Rcvr& rcvr, Args&&... args);      // exposition only
   
     template<>
     struct impls-for<decayed-typeof<let-cpo>> : default-impls {
       static constexpr auto get-attrs = see below;
       static constexpr auto get-state = see below;
       static constexpr auto complete = see below;
   
       template<class Sndr, class... Env>
         static consteval void check-types();
     };
   }

6. Let receiver2 denote the following exposition-only class template:

   namespace std::execution {
     template<class Rcvr, class Env>
     struct receiver2 {
       … as before …
     };
   }

   Invocation of the function receiver2​::​get_env returns an object e such that

   • (6.1) decltype(e) models queryable and

   • (6.2) given a query object q and pack of subexpressions as, the expression e.query(q, as...) is expression-equivalent to env.query(q, as...) if that expression is valid; otherwise, if the type of q satisfies forwarding-query, e.query(q, as...) is expression-equivalent to get_env(rcvr).query(q, as...); otherwise, e.query(q, as...) is ill-formed.

7. Effects: Equivalent to:

   … as before …

   where env-t is the pack decltype(let-cpo.transform_env(declval<Sndr>(), declval<Env>())) decltype(JOIN-ENV(let-env(declval<child-type<Sndr>>(), declval<Env>()), FWD-ENV(declval<Env>()))).

8. impls-for<decayed-typeof<let-cpo>>::get-attrs is initialized with a callable object equivalent to the following:

   [](const auto& fn, const auto& child) {
     return see below;
   }

   Let SetCPO be the decayed type of set-cpo, let Fn be the decayed type of fn, and let Sndrs be a pack of the parameters of the tuple specialization named by gather-signatures<SetCPO, CS, invoke-result, tuple>, where CS is completion_signatures_of_t<decay_t<decltype((child))>, FWD-ENV-T(decltype((as)))...> and invoke-result is an alias template such that invoke-result<Ts...> is invoke_result_t<Fn, Ts...> for a pack Ts. The lambda above returns an object o whose type satisfies queryable such that, for a query object q and pack of subexpressions as, let let_env be the pack JOIN-ENV(let-env(child, as), FWD-ENV(as)). Then o.query(q, as...) is as follows:

   • (8.1) If q is get_completion_domain<SetCPO>, o.query(q, as...) is expression-equivalent to D() where D is the type of the expression:

     COMMON-DOMAIN(COMPL-DOMAIN(SetCPO, declval<Sndrs>(), let_env...)...)

   • (8.2) Otherwise, if q is get_completion_domain<set_error_t> and gather-signatures<SetCPO, CS, is-nothrow, conjunction>::value is well-formed and false, o.query(q, as...) is ill-formed if sizeof...(as) == 0 is true; otherwise it is expression-equivalent to D(), where is-nothrow is the alias template

     template<class... Ts>
       using is-nothrow = bool_constant<
         (noexcept(auto(declval<Ts>())) &&...) &&
         noexcept(connect(invoke(declval<Fn>(), declval<decay_t<Ts>&>()...),
                          receiver-archetype()))>;

     where receiver-archetype is an empty class type such that receiver_of<receiver-archetype, U> is true for any specialization of completion_signatures U and such that the type of receiver-archetype().get_env() is decltype((as...[0])) [ Editor's note: This assumes the adoption of [P3388R2], forwarded to LWG during the Kona 2025 meeting. ]; and where D is the type of the following expression:

     COMMON-DOMAIN(COMPL-DOMAIN(SetCPO, child, FWD-ENV(as)...),
                   COMPL-DOMAIN(set_error_t, child, FWD-ENV(as)...),
                   COMPL-DOMAIN(set_error_t, declval<Sndrs>(), let_env...)...)

   • (8.3) Otherwise, if q is get_completion_domain<set_error_t> or get_completion_domain<set_stopped_t>, let Tag be the template parameter of the type of q. Then o.query(q, as...) is D() where D() is the type of the following expression:

     COMMON-DOMAIN(COMPL-DOMAIN(Tag, child, FWD-ENV(as)...),
                   COMPL-DOMAIN(Tag, declval<Sndrs>(), let_env...)...)

8. impls-for<decayed-typeof<let-cpo>>::get-state is initialized with a callable object equivalent to the following:

   []<class Sndr, class Rcvr>(Sndr&& sndr, Rcvr& rcvr) requires see below {
     auto& [_, fn, child] = sndr;
     using fn_t = decay_t<decltype(fn)>;
     using env_t = decltype(let-env(child, get_env(rcvr)));
     using args_variant_t = see below;
     using ops2_variant_t = see below;
   
     struct state-type {
       fn_t fn;                    // exposition only
       env_t env;                  // exposition only
       args_variant_t args;        // exposition only
       ops2_variant_t ops2;        // exposition only
     };
     return state-type{allocator-aware-forward(std::forward_like<Sndr>(fn), rcvr),
                       let-env(child, get_env(rcvr)), {}, {}};
   }

[ Editor's note: leave paragraphs 9-13 unchanged ]

14. Let sndr and env be subexpressions, and let Sndr be decltype((sndr)). If sender-for<Sndr, decayed-typeof<let-cpo>> is false, then the expression let-cpo.transform_env(sndr, env) is ill-formed. Otherwise, it is equal to:

    auto& [_, _, child] = sndr;
    return JOIN-ENV(let-env(child), FWD-ENV(env));

15. Let the subexpression out_sndr denote … as before …

[ Editor's note: Change 33.9.12.11 [exec.bulk] paragraph 3 and 4 as follows: ]

3. Otherwise, the expression bulk-algo(sndr, policy, shape, f) is expression-equivalent to:

   transform_sender(get-domain-early(sndr), make-sender(
      bulk-algo, product-type<see below, Shape, Func>{policy, shape, f}, sndr))

   except that sndr is evaluated only once.

   The first template argument of product-type is Policy if Policy models copy_constructible, and const Policy& otherwise.

4. Let sndr and env be subexpressions such that Sndr is decltype((sndr)). If sender-for<Sndr, bulk_t> is false, then the expression bulk.transform_sender(set_value, sndr, env) is ill-formed; otherwise, it is equivalent to:

   auto [_, data, child] = sndr;
   auto& [policy, shape, f] = data;
   auto new_f = [func = std::move(f)](Shape begin, Shape end, auto&&... vs)
       noexcept(noexcept(f(begin, vs...))) {
     while (begin != end) func(begin++, vs...);
   }
   return bulk_chunked(std::move(child), policy, shape, std::move(new_f));

   [ Note: This causes the bulk(sndr, policy, shape, f) sender to be expressed in terms of bulk_chunked(sndr, policy, shape, f) when it is connected to a receiver whose execution domain does not customize bulk. — end note ]

[ Editor's note: Change 33.9.12.12 [exec.when.all] paragraphs 2 and 3 as follows: ]

2. The names when_all and when_all_with_variant denote customization point objects. Let sndrs be a pack of subexpressions, and let Sndrs be a pack of the types decltype((sndrs))... , and let CD be the type common_type_t<decltype(get-domain-early(sndrs))...>. Let CD2 be CD if CD is well-formed, and default_domain otherwise. The expressions when_all(sndrs...) and when_all_with_variant(sndrs...) are ill-formed if any of the following is true:

   • (2.1) sizeof...(sndrs) is 0, or

   • (2.2) (sender<Sndrs> && ...) is false.

3. The expression when_all(sndrs...) is expression-equivalent to:

   transform_sender(CD2(), make-sender(when_all, {}, sndrs...))

[ Editor's note: Change 33.9.12.12 [exec.when.all] paragraphs 9 and 10 as follows: ]

template<class Sndr, class... Env>
  static consteval void check-types();

7. Let Is be the pack of integral template arguments of the integer_sequence specialization denoted by indices-for<Sndr>.

8. Effects: Equivalent to: … as before …

9. Throws: Any exception thrown as a result of evaluating the Effects, or an exception of an unspecified type derived from exception when CD is ill-formed.

10. The member impls-for<when_all_t>​::​get-attrs is initialized with a callable object equivalent to the following lambda expression:

    [](auto&&, auto&&... child) noexcept {
      if constexpr (same_as<CD, default_domain>) {
        return env<>();
      } else {
        return MAKE-ENV(get_domain, CD());
      }
      return see below;
    }

    Let WHEN-ALL-DOMAIN(Tag, env...) be the expression COMMON-DOMAIN(COMPL-DOMAIN(Tag, child, env...)...). The lambda expression above returns an object attrs such that

    • (10.1) attrs.query(get_completion_domain<set_value_t>, env...) is expression-equivalent to WHEN-ALL-DOMAIN(set_value_t, env...).

    • (10.2) attrs.query(get_completion_domain<set_error_t>, env...) is expression-equivalent to:

      COMMON-DOMAIN(WHEN-ALL-DOMAIN(set_value_t, env...),
                    WHEN-ALL-DOMAIN(set_error_t, env...),
                    WHEN-ALL-DOMAIN(set_stopped_t, env...))

    • (10.3) attrs.query(get_completion_domain<set_stopped_t>, env...) is expression-equivalent to: [ Editor's note: This assumes the adoption of P3887R0?, which was forwarded to LWG at the Kona 2025 meeting. ]

      COMMON-DOMAIN(WHEN-ALL-DOMAIN(set_value_t, env...),
                    WHEN-ALL-DOMAIN(set_stopped_t, env...))

[ Editor's note: Change 33.9.12.12 [exec.when.all] paragraphs 19 and 20 as follows: ]

19. The expression when_all_with_variant(sndrs...) is expression-equivalent to:

    transform_sender(CD2(), make-sender(when_all_with_variant, {}, sndrs...));

20. Given subexpressions sndr and env, if sender-for<decltype((sndr)), when_all_with_variant_t> is false, then the expression when_all_with_variant.transform_sender(set_value, sndr, env) is ill-formed; otherwise, it is equivalent to:

    auto&& [_, _, ...child] = sndr;
    return when_all(into_variant(std::forward_like<decltype((sndr))>(child))...);

    [ Note: This causes the when_all_with_variant(sndrs...) sender to become when_all(into_variant(sndrs)...) when it is connected with a receiver whose execution domain does not customize when_all_with_variant. — end note ]

[ Editor's note: Change 33.9.12.13 [exec.into.variant] paragraph 3 as follows: ]

3. Otherwise, the expression into_variant(sndr) is expression-equivalent to:

   transform_sender(get-domain-early(sndr),
                    make-sender(into_variant, {}, sndr));

[ Editor's note: Change 33.9.12.14 [exec.stopped.opt] paragrpah 2-4 as follows: ]

2. The name stopped_as_optional denotes a pipeable sender adaptor object. For a subexpression sndr, let Sndr be decltype((sndr)). The expression stopped_as_optional(sndr) is expression-equivalent to:

   transform_sender(get-domain-early(sndr),
                    make-sender(stopped_as_optional, {}, sndr))

   except that sndr is only evaluated once.

3. The exposition-only class template impls-for (33.9.2 [exec.snd.expos]) is specialized for stopped_as_optional_t as follows:

   namespace std::execution {
     template<>
     struct impls-for<stopped_as_optional_t> : default-impls {
       static constexpr auto get-attrs =
         [](const auto&, const auto& child) noexcept -> decltype(auto) {
           see below
         };
   
       template<class Sndr, class... Env>
         static consteval void check-types() {
           … as before …
         }
     };
   }

   where unspecified-exception is a type derived from exception.

4. For subexpressions ign and child, pack of subexpressions as, and query object q, impls-for<stopped_as_optional_t>::get-attrs(ign, child) returns an object o such that o.query(q, as...) is expression-equivalent to:

   • (4.1) D() if q is get_completion_domain<set_value_t>, where D is the type of the expression

     COMMON-DOMAIN(COMPL-DOMAIN(set_value_t, child, FWD-ENV(as)...),
                   COMPL-DOMAIN(set_stopped_t, child, FWD-ENV(as)...))

   • (4.2) FWD-ENV(get_env(child)).query(q, as...) if q is not get_completion_domain<set_stopped_t>, get_completion_scheduler<set_value_t>, or get_completion_scheduler<set_stopped_t>.

   • (4.3) Otherwise, o.query(q, as...) is ill-formed.

5. Let sndr and env be subexpressions such that Sndr is decltype((sndr)) and Env is decltype((env)). If sender-for<Sndr, stopped_as_optional_t> is false then the expression stopped_as_optional.transform_sender(set_value, sndr, env) is ill-formed; otherwise, if sender_in<child-type<Sndr>, FWD-ENV-T(Env)> is false, the expression stopped_as_optional.transform_sender(set_value, sndr, env) is equivalent to not-a-sender(); otherwise, it is equivalent to:

   auto&& [_, _, child] = sndr;
   using V = single-sender-value-type<child-type<Sndr>, FWD-ENV-T(Env)>;
   return let_stopped(
     then(std::forward_like<Sndr>(child),
          []<class... Ts>(Ts&&... ts) noexcept(is_nothrow_constructible_v<V, Ts...>) {
            return optional<V>(in_place, std::forward<Ts>(ts)...);
          }),
     []() noexcept { return just(optional<V>()); });

[ Editor's note: Change 33.9.12.15 [exec.stopped.err] paragraphs 2-3 as follows: ]

2. The name stopped_as_error denotes a pipeable sender adaptor object. For some subexpressions sndr and err, let Sndr be decltype((sndr)) and let Err be decltype((err)). If the type Sndr does not satisfy sender or if the type Err does not satisfy movable-value, stopped_as_error(sndr, err) is ill-formed. Otherwise, the expression stopped_as_error(sndr, err) is expression-equivalent to:

   transform_sender(get-domain-early(sndr), make-sender(stopped_as_error, err, sndr))

   except that sndr is only evaluated once.

3. The exposition-only class template impls-for (33.9.2 [exec.snd.expos]) is specialized for stopped_as_error_t as follows:

   namespace std::execution {
     template<>
     struct impls-for<stopped_as_error_t> : default-impls {
       static constexpr auto get-attrs =
         [](const auto&, const auto& child) noexcept -> decltype(auto) {
           see below
         };
     };
   }

4. For subexpressions ign and child, pack of subexpressions as, and query object q, impls-for<stopped_as_error_t>::get-attrs(ign, child) returns an object o such that o.query(q, as...) is expression-equivalent to:

   • (4.1) D() if q is get_completion_domain<set_error_t>, where D is the type of the expression

     COMMON-DOMAIN(COMPL-DOMAIN(set_error_t, child, FWD-ENV(as)...),
                   COMPL-DOMAIN(set_stopped_t, child, FWD-ENV(as)...))

   • (4.2) FWD-ENV(get_env(child)).query(q, as...) if q is not get_completion_domain<set_stopped_t>, get_completion_scheduler<set_error_t>, or get_completion_scheduler<set_stopped_t>.

   • (4.3) Otherwise, o.query(q, as...) is ill-formed.

5. Let sndr and env be subexpressions such that Sndr is decltype((sndr)) and Env is decltype((env)). If sender-for<Sndr, stopped_as_error_t> is false, then the expression stopped_as_error.transform_sender(set_value, sndr, env) is ill-formed; otherwise, it is equivalent to:

   auto&& [_, err, child] = sndr;
   using E = decltype(auto(err));
   return let_stopped(
     std::forward_like<Sndr>(child),
     [err = std::forward_like<Sndr>(err)]() mutable noexcept(is_nothrow_move_constructible_v<E>) {
       return just_error(std::move(err));
     });

[ Editor's note: Change 33.9.12.16 [exec.associate] paragraph 10 as follows: ]

10. The name associate denotes a pipeable sender adaptor object. For subexpressions sndr and token:

    • (10.1) If decltype((sndr)) does not satisfy sender, or remove_cvref_t<decltype((token))> does not satisfy scope_token, then associate(sndr, token) is ill-formed.

    • (10.2) Otherwise, the expression associate(sndr, token) is expression-equivalent to:

      transform_sender(get-domain-early(sndr),
                       make-sender(associate, associate-data(token, sndr)))

      except that sndr is evaluated only once.

[ Editor's note: Change 33.9.13.1 [exec.sync.wait] paragraphs 4-9 as follows: ]

4. The name this_thread​::​sync_wait denotes a customization point object. For a subexpression sndr, let Sndr be decltype((sndr)). The expression this_thread​::​sync_wait(sndr) is expression-equivalent to the following, except that sndr is evaluated only once:

   run_loop loop;
   sync-wait-env env{&loop};
   auto domain = get_completion_domain<set_value_t>(get_env(sndr), env);
   return apply_sender(get-domain-early(sndr)domain, sync_wait, sndr, env);

   Mandates:

   • (4.1) sender_in<Sndr, sync-wait-env> is true.

   • (4.2) The type sync-wait-result-type<Sndr> is well-formed.

   • (4.3) same_as<decltype(e), sync-wait-result-type<Sndr>> is true, where e is the apply_sender expression above.

5. Let sync-wait-state and sync-wait-receiver be the following exposition-only class templates: [ Editor's note: Note the addition of & to the declaration of the sync-wait_state::loop data member. ]

   namespace std::this_thread {
     template<class Sndr>
     struct sync-wait-state {                                      // exposition only
       execution::run_loop& loop;                                  // exposition only
       exception_ptr error;                                        // exposition only
       sync-wait-result-type<Sndr> result;                         // exposition only
     };
   
     template<class Sndr>
     struct sync-wait-receiver {                                   // exposition only
       using receiver_concept = execution::receiver_t;
       sync-wait-state<Sndr>* state;                               // exposition only
   
       template<class... Args>
       void set_value(Args&&... args) && noexcept;
   
       template<class Error>
       void set_error(Error&& err) && noexcept;
   
       void set_stopped() && noexcept;
   
       sync-wait-env get_env() const noexcept { return {&state->loop}; }
     };
   }

[ Editor's note: Leave paragraphs 6-8 as-is ]

9. For a subexpressions sndr and env, let Sndr be decltype((sndr)). If sender_to<Sndr, sync-wait-receiver<Sndr>> is false or if the type of env is not sync-wait-env, the expression sync_wait.apply_sender(sndr, env) is ill-formed; otherwise, it is equivalent to:

   sync-wait-state<Sndr> state{*env.loop};
   auto op = connect(sndr, sync-wait-receiver<Sndr>{&state});
   start(op);
   
   state.loop.run();
   if (state.error) {
     rethrow_exception(std::move(state.error));
   }
   return std::move(state.result);