1.4.1 Generic async algorithm example: retry

retry is the kind of Generic algorithm senders and receivers enable. It has simple semantics: schedule work on an execution context; if the execution succeeds, done; otherwise, if the user requests cancellation, done; otherwise, if a scheduling error occurs, try again.

template<invocable Fn>
void retry(executor_of<Fn> auto ex, Fn fn) {
  // ???
}

Executors alone prohibit a generic implementation because they lack a portable way to intercept and react to scheduling errors. Later we show how this algorithm might look when implemented with senders and receivers.

1.4.2 Goal: an asynchronous STL

Suitably chosen concepts driving the definition of Generic async algorithms like retry streamline the creation of efficient, asynchronous graphs of work. Here is some sample syntax for the sorts of async programs we envision (borrowed from P1897):

sender auto s = just(3) |                               // produce '3' immediately
                on(scheduler1) |                        // transition context
                transform([](int a){return a+1;}) |     // chain continuation
                transform([](int a){return a*2;}) |     // chain another continuation
                on(scheduler2) |                        // transition context
                let_error([](auto e){return just(3);}); // with default value on errors
int r = sync_wait(s);                                   // wait for the result

It should be possible to replace just(3) with a call to any asynchronous API whose return type satisfies the correct concept and maintain this program’s correctness. Generic algorithms like when_all and when_any would permit users to express fork/join concurrency in their DAGs. As with STL’s iterator abstraction, the cost of satisfying the conceptual requirements are offset by the expressivity of a large reusable and composable library of algorithms.

1.4.3 Current techniques

There are many techniques for creating chains of dependent asynchronous execution. Ordinary callbacks have enjoyed success in C++ and elsewhere for years. Modern codebases have switched to variations of future abstractions that support continuations (e.g., std::experimental::future::then). In C++20 and beyond, we could imagine standardizing on coroutines, so that launching an async operation returns an awaitable. Each of these approaches has strengths and weaknesses.

Futures, as traditionally realized, require the dynamic allocation and management of a shared state, synchronization, and typically type-erasure of work and continuation. Many of these costs are inherent in the nature of “future” as a handle to an operation that is already scheduled for execution. These expenses rule out the future abstraction for many uses and makes it a poor choice for a basis of a Generic mechanism.

Coroutines suffer many of the same problems but can avoid synchronizing when chaining dependent work because they typically start suspended. In many cases, coroutine frames require unavoidable dynamic allocation. Consequently, coroutines in embedded or heterogeneous environments require great attention to detail. Neither are coroutines good candidates for cancellation because the early and safe termination of coordinating coroutines requires unsatisfying solutions. On the one hand, exceptions are inefficient and disallowed in many environments. Alternatively, clumsy ad hoc mechanisms, whereby co_yield returns a status code, hinder correctness. P1662 provides a complete discussion.

Callbacks are the simplest, most powerful, and most efficient mechanism for creating chains of work, but suffer problems of their own. Callbacks must propagate either errors or values. This simple requirement yields many different interface possibilities, but the lack of a standard obstructs Generic design. Additionally, few of these possibilities accomodate cancellation signals when the user requests upstream work to stop and clean up.

1.5.1 Receiver

A receiver is simply a callback with a particular interface and semantics. Unlike a traditional callback which uses function-call syntax and a single signature handling both success and error cases, a receiver has three separate channels for value, error, and “done” (aka cancelled).

These channels are specified as customization points, and a type R modeling receiver_of<R,Ts...> supports them:

std::execution::set_value(r, ts...); // signal success, but set_value itself may fail
std::execution::set_error(r, ep);    // signal error (ep is std::exception_ptr), never fails
std::execution::set_done(r);         // signal stopped, never fails

Exactly one of the three functions must be called on a receiver before it is destroyed. Each of these interfaces is considered “terminal”. That is, a particular receiver may assume that if one is called, no others ever will be. The one exception being if set_value exits with an exception, the receiver is not yet complete. Consequently, another function must be called on it before it is destroyed. After a failed call to set_value, correctness requires a subsequent call either to set_error or set_done; a receiver need not guarantee that a second call to set_value is well-formed. Collectively, these requirements are the “receiver contract”.

Although receiver’s interface appears novel at first glance, it remains just a callback. Moreover, receiver’s novelty disappears when recognizing that std::promise’s set_value and set_exception provide essentially the same interface. This choice of interface and semantics, along with sender, facilitate the Generic implementation of many useful async algorithms like retry.

1.5.2 Sender

A sender represents work that has not been scheduled for execution yet, to which one must add a continuation (a receiver) and then “launch”, or enqueue for execution. A sender’s duty to its connected receiver is to fulfill the receiver contract by ensuring that one of the three receiver functions returns normally.

Earlier versions of this paper fused these two operations — attach a continuation and launch for execution — into the single operation submit. This paper proposes to split submit into a connect step that packages a sender and a receiver into an operation state, and a start step that logically starts the operation and schedules the receiver completion-signalling methods to be called when the operation completes.

// P0443R12
std::execution::submit(snd, rec);

// P0443R13
auto state = std::execution::connect(snd, rec);
// ... later
std::execution::start(state);

This split offers interesting opportunities for optimization, and harmonizes senders with coroutines.

The sender concept itself places no requirements on the execution context on which a sender’s work executes. Instead, specific models of the sender concept may offer stronger guarantees about the context from which the receiver’s methods will be invoked. This is particularly true of the senders created by a scheduler.

1.5.3 Scheduler

Many generic async algorithms create multiple execution agents on the same execution context. Therefore, it is insufficient to parameterize these algorithms with a single-shot sender completing in a known context. Rather, it makes sense to pass these algorithms a factory of single-shot senders. Such a factory is called a “scheduler”, and it has a single basis operation: schedule:

sender auto s = std::execution::schedule(sched);
// OK, s is a single-shot sender of void that completes in sched's execution context

Like executors, schedulers act as handles to an execution context. Unlike executors, schedulers submit execution lazily, but a single type may simultaneously model both concepts. We envision that subsumptions of the scheduler concept will add the ability to postpone or cancel execution until after some time period has elapsed.

1.6.1 Algorithm then

The following code implements a then algorithm that, like std::experimental::future::then, schedules a function to be applied to the result of an asynchronous operation when available. This code demonstrates how an algorithm can adapt receivers to codify the algorithm’s logic.

template<receiver R, class F>
struct _then_receiver : R { // for exposition, inherit set_error and set_done from R
    F f_;

    // Customize set_value by invoking the callable and passing the result to the base class
    template<class... As>
      requires receiver_of<R, invoke_result_t<F, As...>>
    void set_value(As&&... as) && noexcept(/*...*/) {
      std::execution::set_value((R&&) *this, invoke((F&&) f_, (As&&) as...));
    }

    // Not shown: handle the case when the callable returns void
};

template<sender S, class F>
struct _then_sender : std::execution::sender_base {
    S s_;
    F f_;

    template<receiver R>
      requires sender_to<S, _then_receiver<R, F>>
    state_t<S, _then_receiver<R, F>> connect(R r) && {
        return std::execution::connect((S&&)s_, _then_receiver<R, F>{(R&&)r, (F&&)f_});
    }
};

template<sender S, class F>
sender auto then(S s, F f) {
    return _then_sender{{}, (S&&)s, (F&&)f};
}

Given some asynchronous, sender-returning API async_foo, a user of then can execute some code once the async result is available:

sender auto s = then(async_foo(args...), [](auto result) {/* stuff... */});

This builds a composed asynchronous operation. When the user wants to schedule this operation for execution, they would connect a receiver, and then call start on the resulting operation state.

Scheduling work on an execution context can also be done with then. Given a static_thread_pool object pool that satisfied the scheduler concept, a user may do the following:

sender auto s = then(
    std::execution::schedule( pool ),
    []{ std::printf("hello world"); } );

This creates a sender that, when submitted, will call printf from a thread in the thread pool.

There exist heterogeneous computing environments that are unable to execute arbitrary code. For those, an implementation of then as shown above would either not work or would incur the cost of a transition to the host in order to execute the unknown code. Therefore, then itself and several other fundamental algorithmic primitives, would themselves need to be customizable on a per-execution context basis.

A full working example of then can be found here: https://godbolt.org/z/dafqM-

1.6.2 Algorithm retry

As described above, the idea of retry is to retry the async operation on failure, but not on success or cancellation. Key to a correct generic implementation of retry is the ability to distinguish the error case from the cancelled case.

As with the then algorithm, the retry algorithm places the logic of the algorithm into a custom receiver to which the sender to be retried is connect-ed. That custom receiver has set_value and set_done members that simply pass their signals through unmodified. The set_error member, on the other hand, reconstructs the operation state in-place by making another call to connect with the original sender and a new instance of the custom receiver. That new operation state is then start-ed again, which effectively causes the original sender to be retried.

The appendix lists the source of the retry algorithm. Note that the signature of the retry algorithm is simply:

sender auto retry(sender auto s);

That is, it is not parameterized on an execution context on which to retry the operation. That is because we can assume the existence of a function on which schedules a sender for execution on a specified execution context:

sender auto on(sender auto s, scheduler auto sched);

Given these two functions, a user can simply do retry(on(s, sched)) to retry an operation on a particular execution context.

1.6.3 Toward an asynchronous STL

The algorithms then and retry are only two of many interesting Generic asynchronous algorithms that are expressible in terms of senders and receivers. Two other important algorithms are on and via, the former which schedules a sender for execution on a particular scheduler, and the latter which causes a sender’s continuations to be run on a particular scheduler. In this way, chains of asynchronous computation can be created that transition from one execution context to another.

Other important algorithms are when_all and when_any, encapsulating fork/join semantics. With these algorithms and others, entire DAGs of async computation can be created and executed. when_any can in turn be used to implement a generic timeout algorithm, together with a sender that sleeps for a duration and then sends a “done” signal, and so these algorithms compose.

In short, sender/receiver permits a rich set of Generic asynchronous algorithms to sit alongside Stepanov’s sequence algorithms in the STL. Asynchronous APIs that return senders would be usable with these Generic algorithms, increasing reusability. P1897 suggest an initial set of these algorithms.

2.1.1 General

This Clause describes components supporting execution of function objects [function.objects].

(The following definition appears in working draft N4762 [thread.req.lockable.general])

An execution agent is an entity such as a thread that may perform work in parallel with other execution agents. [Note: Implementations or users may introduce other kinds of agents such as processes or thread-pool tasks. –end note] The calling agent is determined by context; e.g., the calling thread that contains the call, and so on.

An execution agent invokes a function object within an execution context such as the calling thread or thread-pool. An executor submits a function object to an execution context to be invoked by an execution agent within that execution context. [Note: Invocation of the function object may be inlined such as when the execution context is the calling thread, or may be scheduled such as when the execution context is a thread-pool with task scheduler. –end note] An executor may submit a function object with execution properties that specify how the submission and invocation of the function object interacts with the submitting thread and execution context, including forward progress guarantees [intro.progress].

For the intent of this library and extensions to this library, the lifetime of an execution agent begins before the function object is invoked and ends after this invocation completes, either normally or having thrown an exception.

2.1.2 Header <execution> synopsis

namespace std {
namespace execution {

  // Exception types:

  extern runtime_error const invocation-error; // exposition only
  struct receiver_invocation_error : runtime_error, nested_exception {
    receiver_invocation_error() noexcept
      : runtime_error(invocation-error), nested_exception() {}
  };

  // Invocable archetype

  using invocable_archetype = unspecified;

  // Customization points:

  inline namespace unspecified{
    inline constexpr unspecified set_value = unspecified;

    inline constexpr unspecified set_done = unspecified;

    inline constexpr unspecified set_error = unspecified;

    inline constexpr unspecified execute = unspecified;

    inline constexpr unspecified connect = unspecified;

    inline constexpr unspecified start = unspecified;

    inline constexpr unspecified submit = unspecified;

    inline constexpr unspecified schedule = unspecified;

    inline constexpr unspecified bulk_execute = unspecified;
  }

  template<class S, class R>
    using connect_result_t = invoke_result_t<decltype(connect), S, R>;

  template<class, class> struct as-receiver; // exposition only

  template<class, class> struct as-invocable; // exposition only

  // Concepts:

  template<class T, class E = exception_ptr>
    concept receiver = see-below;

  template<class T, class... An>
    concept receiver_of = see-below;

  template<class R, class... An>
    inline constexpr bool is_nothrow_receiver_of_v =
      receiver_of<R, An...> &&
      is_nothrow_invocable_v<decltype(set_value), R, An...>;

  template<class O>
    concept operation_state = see-below;

  template<class S>
    concept sender = see-below;

  template<class S>
    concept typed_sender = see-below;

  template<class S, class R>
    concept sender_to = see-below;

  template<class S>
    concept scheduler = see-below;

  template<class E>
    concept executor = see-below;

  template<class E, class F>
    concept executor_of = see-below;

  // Sender and receiver utilities type
  namespace unspecified { struct sender_base {}; }
  using unspecified::sender_base;

  template<class S> struct sender_traits;

  // Associated execution context property:

  struct context_t;

  constexpr context_t context;

  // Blocking properties:

  struct blocking_t;

  constexpr blocking_t blocking;

  // Properties to indicate if submitted tasks represent continuations:

  struct relationship_t;

  constexpr relationship_t relationship;

  // Properties to indicate likely task submission in the future:

  struct outstanding_work_t;

  constexpr outstanding_work_t outstanding_work;

  // Properties for bulk execution guarantees:

  struct bulk_guarantee_t;

  constexpr bulk_guarantee_t bulk_guarantee;

  // Properties for mapping of execution on to threads:

  struct mapping_t;

  constexpr mapping_t mapping;

  // Memory allocation properties:

  template <typename ProtoAllocator>
  struct allocator_t;

  constexpr allocator_t<void> allocator;

  // Executor type traits:

  template<class Executor> struct executor_shape;
  template<class Executor> struct executor_index;

  template<class Executor> using executor_shape_t = typename executor_shape<Executor>::type;
  template<class Executor> using executor_index_t = typename executor_index<Executor>::type;

  // Polymorphic executor support:

  class bad_executor;

  template <class... SupportableProperties> class any_executor;

  template<class Property> struct prefer_only;

} // namespace execution
} // namespace std

2.2.1 ProtoAllocator requirements

A type A meets the ProtoAllocator requirements if A is CopyConstructible (C++Std [copyconstructible]), Destructible (C++Std [destructible]), and allocator_traits<A>::rebind_alloc<U> meets the allocator requirements (C++Std [allocator.requirements]), where U is an object type. [Note: For example, std::allocator<void> meets the proto-allocator requirements but not the allocator requirements. –end note] No comparison operator, copy operation, move operation, or swap operation on these types shall exit via an exception.

2.2.2 Invocable archetype

The name execution::invocable_archetype is an implementation-defined type such that invocable<execution::invocable_archetype&> is true.

A program that creates an instance of execution::invocable_archetype is ill-formed.

2.2.3 Customization points

2.2.4 Concepts receiver and receiver_of

A receiver represents the continuation of an asynchronous operation. An asynchronous operation may complete with a (possibly empty) set of values, an error, or it may be cancelled. A receiver has three principal operations corresponding to the three ways an asynchronous operation may complete: set_value, set_error, and set_done. These are collectively known as a receiver’s completion-signal operations.

    template<class T, class E = exception_ptr>
    concept receiver =
      move_constructible<remove_cvref_t<T>> &&
      constructible_from<remove_cvref_t<T>, T> &&
      requires(remove_cvref_t<T>&& t, E&& e) {
        { execution::set_done(std::move(t)) } noexcept;
        { execution::set_error(std::move(t), (E&&) e) } noexcept;
      };

    template<class T, class... An>
    concept receiver_of =
      receiver<T> &&
      requires(remove_cvref_t<T>&& t, An&&... an) {
        execution::set_value(std::move(t), (An&&) an...);
      };

The receiver’s completion-signal operations have semantic requirements that are collectively known as the receiver contract, described below:

• None of a receiver’s completion-signal operations shall be invoked before execution::start has been called on the operation state object that was returned by execution::connect to connect that receiver to a sender.

• Once execution::start has been called on the operation state object, exactly one of the receiver’s completion-signal operations shall complete non-exceptionally before the receiver is destroyed.

• If execution::set_value exits with an exception, it is still valid to call execution::set_error or execution::set_done on the receiver.

Once one of a receiver’s completion-signal operations has completed non-exceptionally, the receiver contract has been satisfied.

2.2.5 Concept operation_state

    template<class O>
      concept operation_state =
        destructible<O> &&
        is_object_v<O> &&
        requires (O& o) {
          { execution::start(o) } noexcept;
        };

An object whose type satisfies operation_state represents the state of an asynchronous operation. It is the result of calling execution::connect with a sender and a receiver.

execution::start may be called on an operation_state object at most once. Once execution::start has been invoked, the caller shall ensure that the start of a non-exceptional invocation of one of the receiver’s completion-signalling operations strongly happens before [intro.multithread] the call to the operation_state destructor.

The start of the invocation of execution::start shall strongly happen before [intro.multithread] the invocation of one of the three receiver operations.

execution::start may or may not block pending the successful transfer of execution to one of the three receiver operations.

2.2.6 Concepts sender and sender_to

A sender represents an asynchronous operation not yet scheduled for execution. A sender’s responsibility is to fulfill the receiver contract to a connected receiver by delivering a completion signal.

    template<class S>
      concept sender =
        move_constructible<remove_cvref_t<S>> &&
        !requires {
          typename sender_traits<remove_cvref_t<S>>::__unspecialized; // exposition only
        };

    template<class S, class R>
      concept sender_to =
        sender<S> &&
        receiver<R> &&
        requires (S&& s, R&& r) {
          execution::connect((S&&) s, (R&&) r);
        };

None of these operations shall introduce data races as a result of concurrent invocations of those functions from different threads.

A sender type’s destructor shall not block pending completion of the submitted function objects. [Note: The ability to wait for completion of submitted function objects may be provided by the associated execution context. –end note]

2.2.7 Concept typed_sender

A sender is typed if it declares what types it sends through a receiver’s channels. The typed_sender concept is defined as:

    template<template<template<class...> class Tuple, template<class...> class Variant> class>
      struct has-value-types; // exposition only

    template<template<class...> class Variant>
      struct has-error-types; // exposition only

    template<class S>
      concept has-sender-types = // exposition only
        requires {
          typename has-value-types<S::template value_types>;
          typename has-error-types<S::template error_types>;
          typename bool_constant<S::sends_done>;
        };

    template<class S>
      concept typed_sender =
        sender<S> &&
        has-sender-types<sender_traits<remove_cvref_t<S>>>;

2.2.8 Concept scheduler

XXX TODO The scheduler concept…

    template<class S>
      concept scheduler =
        copy_constructible<remove_cvref_t<S>> &&
        equality_comparable<remove_cvref_t<S>> &&
        requires(S&& s) {
          execution::schedule((S&&)s);
        };

None of a scheduler’s copy constructor, destructor, equality comparison, or swap operation shall exit via an exception.

None of these operations, nor an scheduler type’s schedule function, or associated query functions shall introduce data races as a result of concurrent invocations of those functions from different threads.

For any two (possibly const) values x1 and x2 of some scheduler type X, x1 == x2 shall return true only if x1.query(p) == x2.query(p) for every property p where both x1.query(p) and x2.query(p) are well-formed and result in a non-void type that is EqualityComparable (C++Std [equalitycomparable]). [Note: The above requirements imply that x1 == x2 returns true if x1 and x2 can be interchanged with identical effects. An scheduler may conceptually contain additional properties which are not exposed by a named property type that can be observed via execution::query; in this case, it is up to the concrete scheduler implementation to decide if these properties affect equality. Returning false does not necessarily imply that the effects are not identical. –end note]

An scheduler type’s destructor shall not block pending completion of any receivers submitted to the sender objects returned from schedule. [Note: The ability to wait for completion of submitted function objects may be provided by the execution context that produced the scheduler. –end note]

In addition to the above requirements, type S models scheduler only if it satisfies the requirements in the Table below.

In the Table below,

• s denotes a (possibly const) scheduler object of type S,
• N denotes a type that models sender, and
• n denotes a sender object of type N

execution::start(o), where o is the result of a call to execution::connect(N, r) for some receiver object r, is required to eagerly submit r for execution on an execution agent that s creates for it. Let rc be r or an object created by copy or move construction from r. The semantic constraints on the sender N returned from a scheduler s’s schedule function are as follows:

• If rc’s set_error function is called in response to a submission error, scheduling error, or other internal error, let E be an expression that refers to that error if set_error(rc, E) is well-formed; otherwise, let E be an exception_ptr that refers to that error. [ Note: E could be the result of calling current_exception or make_exception_ptr — end note ] The scheduler calls set_error(rc, E) on an unspecified weakly-parallel execution agent ([ Note: An invocation of set_error on a receiver is required to be noexcept — end note]), and

• If rc’s set_error function is called in response to an exception that propagates out of the invocation of set_value on rc, let E be make_exception_ptr(receiver_invocation_error{}) invoked from within a catch clause that has caught the exception. The executor calls set_error(rc, E) on an unspecified weakly-parallel execution agent, and

• A call to set_done(rc) is made on an unspecified weakly-parallel execution agent ([ Note: An invocation of a receiver’s set_done function is required to be noexcept — end note ]).

[ Note: The senders returned from a scheduler’s schedule function have wide discretion when deciding which of the three receiver functions to call upon submission. — end note ]

2.2.9 Concepts executor and executor_of

XXX TODO The executor and executor_of concepts…

Let executor-of-impl be the exposition-only concept

    template<class E, class F>
      concept executor-of-impl =
        invocable<remove_cvref_t<F>&> &&
        constructible_from<remove_cvref_t<F>, F> &&
        move_constructible<remove_cvref_t<F>> &&
        copy_constructible<E> &&
        is_nothrow_copy_constructible_v<E> &&
        equality_comparable<E> &&
        requires(const E& e, F&& f) {
          execution::execute(e, (F&&)f);
        };

Then,

    template<class E>
      concept executor =
        executor-of-impl<E, execution::invocable_archetype>;

    template<class E, class F>
      concept executor_of =
        executor<E> &&
        executor-of-impl<E, F>;

Neither of an executor’s equality comparison or swap operation shall exit via an exception.

None of an executor type’s copy constructor, destructor, equality comparison, swap function, execute function, or associated query functions shall introduce data races as a result of concurrent invocations of those functions from different threads.

For any two (possibly const) values x1 and x2 of some executor type X, x1 == x2 shall return true only if std::query(x1,p) == std::query(x2,p) for every property p where both std::query(x1,p) and std::query(x2,p) are well-formed and result in a non-void type that is equality_comparable (C++Std [equalitycomparable]). [Note: The above requirements imply that x1 == x2 returns true if x1 and x2 can be interchanged with identical effects. An executor may conceptually contain additional properties which are not exposed by a named property type that can be observed via std::query; in this case, it is up to the concrete executor implementation to decide if these properties affect equality. Returning false does not necessarily imply that the effects are not identical. –end note]

An executor type’s destructor shall not block pending completion of the submitted function objects. [Note: The ability to wait for completion of submitted function objects may be provided by the associated execution context. –end note]

In addition to the above requirements, types E and F model executor_of only if they satisfy the requirements of the Table below.

In the Table below,

• e denotes a (possibly const) executor object of type E,
• cf denotes the function object DECAY_COPY(std::forward<F>(f))
• f denotes a function of type F&& invocable as cf() and where decay_t<F> models move_constructible.

[Editorial note: The operational semantics of execution::execute should be specified with the execution::execute CPO rather than the executor concept. –end note.]

2.2.10 Sender and receiver traits

2.2.11 Query-only properties

struct context_t
{
  template <class T>
    static constexpr bool is_applicable_property_v = executor<T>;

  static constexpr bool is_requirable = false;
  static constexpr bool is_preferable = false;

  using polymorphic_query_result_type = any;

  template<class Executor>
    static constexpr decltype(auto) static_query_v
      = Executor::query(context_t());
};

2.2.12 Behavioral properties

Behavioral properties define a set of mutually-exclusive nested properties describing executor behavior.

Unless otherwise specified, behavioral property types S, their nested property types S::Ni, and nested property objects S::ni conform to the following specification:

struct S
{
  template <class T>
    static constexpr bool is_applicable_property_v = executor<T>;

  static constexpr bool is_requirable = false;
  static constexpr bool is_preferable = false;
  using polymorphic_query_result_type = S;

  template<class Executor>
    static constexpr auto static_query_v
      = see-below;

  template<class Executor, class Property>
  friend constexpr S query(const Executor& ex, const Property& p) noexcept(see-below);

  friend constexpr bool operator==(const S& a, const S& b);
  friend constexpr bool operator!=(const S& a, const S& b) { return !operator==(a, b); }

  constexpr S();

  struct N1
  {
    static constexpr bool is_requirable = true;
    static constexpr bool is_preferable = true;
    using polymorphic_query_result_type = S;

    template<class Executor>
      static constexpr auto static_query_v
        = see-below;

    static constexpr S value() { return S(N1()); }
  };

  static constexpr N1 n1;

  constexpr S(const N1);

  ...

  struct NN
  {
    static constexpr bool is_requirable = true;
    static constexpr bool is_preferable = true;
    using polymorphic_query_result_type = S;

    template<class Executor>
      static constexpr auto static_query_v
        = see-below;

    static constexpr S value() { return S(NN()); }
  };

  static constexpr NN nN;

  constexpr S(const NN);
};

Queries for the value of an executor’s behavioral property shall not change between invocations unless the executor is assigned another executor with a different value of that behavioral property.

S() and S(S::Ni()) are all distinct values of S. [Note: This means they compare unequal. –end note.]

The value returned from std::query(e1, p1) and a subsequent invocation std::query(e1, p1), where

• p1 is an instance of S or S::Ni, and
• e2 is the result of std::require(e1, p2) or std::prefer(e1, p2),

shall compare equal unless

• p2 is an instance of S::Ni, and
• p1 and p2 are different types.

The value of the expression S::N1::static_query_v<Executor> is

• Executor::query(S::N1()), if that expression is a well-formed expression;
• ill-formed if declval<Executor>().query(S::N1()) is well-formed;
• ill-formed if can_query_v<Executor,S::Ni> is true for any 1 < i <= N;
• otherwise S::N1().

[Note: These rules automatically enable the S::N1 property by default for executors which do not provide a query function for properties S::Ni. –end note]

The value of the expression S::Ni::static_query_v<Executor>, for all 1 < i <= N, is

• Executor::query(S::Ni()), if that expression is a well-formed constant expression;
• otherwise ill-formed.

The value of the expression S::static_query_v<Executor> is

• Executor::query(S()), if that expression is a well-formed constant expression;
• otherwise, ill-formed if declval<Executor>().query(S()) is well-formed;
• otherwise, S::Ni::static_query_v<Executor> for the least i <= N for which this expression is a well-formed constant expression;
• otherwise ill-formed.

[Note: These rules automatically enable the S::N1 property by default for executors which do not provide a query function for properties S or S::Ni. –end note]

Let k be the least value of i for which can_query_v<Executor,S::Ni> is true, if such a value of i exists.

template<class Executor, class Property>
  friend constexpr S query(const Executor& ex, const Property& p) noexcept(noexcept(std::query(ex, std::declval<const S::Nk>())));

Returns: std::query(ex, S::Nk()).

Remarks: This function shall not participate in overload resolution unless is_same_v<Property,S> && can_query_v<Executor,S::Ni> is true for at least one S::Ni`.

bool operator==(const S& a, const S& b);

Returns: true if a and b were constructed from the same constructor; false, otherwise.

2.2.13 Properties for customizing memory allocation

template <typename ProtoAllocator>
struct allocator_t;

The allocator_t property conforms to the following specification:

template <typename ProtoAllocator>
struct allocator_t
{
    template <class T>
      static constexpr bool is_applicable_property_v = executor<T>;

    static constexpr bool is_requirable = true;
    static constexpr bool is_preferable = true;

    template<class Executor>
    static constexpr auto static_query_v
      = Executor::query(allocator_t);

    template <typename OtherProtoAllocator>
    allocator_t<OtherProtoAllocator> operator()(const OtherProtoAllocator &a) const;

    static constexpr ProtoAllocator value() const;

private:
    ProtoAllocator a_; // exposition only
};

If the expression std::query(E, P) is well formed, where P is an object of type allocator_t<ProtoAllocator>, then: * the type of the expression std::query(E, P) shall satisfy the ProtoAllocator requirements; * the result of the expression std::query(E, P) shall be the allocator currently established in the executor E; and * the expression std::query(E, allocator_t<void>{}) shall also be well formed and have the same result as std::query(E, P).

template <typename OtherProtoAllocator>
allocator_t<OtherProtoAllocator> operator()(const OtherProtoAllocator &a) const;

constexpr ProtoAllocator value() const;

2.3.1 Associated shape type

template<class Executor>
struct executor_shape
{
  private:
    // exposition only
    template<class T>
    using helper = typename T::shape_type;

  public:
    using type = std::experimental::detected_or_t<
      size_t, helper, decltype(std::require(declval<const Executor&>(), execution::bulk))
    >;

    // exposition only
    static_assert(std::is_integral_v<type>, "shape type must be an integral type");
};

2.3.2 Associated index type

template<class Executor>
struct executor_index
{
  private:
    // exposition only
    template<class T>
    using helper = typename T::index_type;

  public:
    using type = std::experimental::detected_or_t<
      executor_shape_t<Executor>, helper, decltype(std::require(declval<const Executor&>(), execution::bulk))
    >;

    // exposition only
    static_assert(std::is_integral_v<type>, "index type must be an integral type");
};

2.4.1 Class bad_executor

An exception of type bad_executor is thrown by polymorphic executor member function execute when the executor object has no target.

class bad_executor : public exception
{
public:
  // constructor:
  bad_executor() noexcept;
};

bad_executor() noexcept;

2.4.2 Struct prefer_only

The prefer_only struct is a property adapter that disables the is_requirable value.

[Example:

Consider a generic function that performs some task immediately if it can, and otherwise asynchronously in the background.

template<class Executor, class Callback>
void do_async_work(
    Executor ex,
    Callback callback)
{
  if (try_work() == done)
  {
    // Work completed immediately, invoke callback.
    execution::execute(ex, callback);
  }
  else
  {
    // Perform work in background. Track outstanding work.
    start_background_work(
        std::prefer(ex,
          execution::outstanding_work.tracked),
        callback);
  }
}

This function can be used with an inline executor which is defined as follows:

struct inline_executor
{
  constexpr bool operator==(const inline_executor&) const noexcept
  {
    return true;
  }

  constexpr bool operator!=(const inline_executor&) const noexcept
  {
    return false;
  }

  template<class Function> void execute(Function f) const noexcept
  {
    f();
  }
};

as, in the case of an unsupported property, invocation of std::prefer will fall back to an identity operation.

The polymorphic any_executor wrapper should be able to simply swap in, so that we could change do_async_work to the non-template function:

void do_async_work(any_executor<execution::outstanding_work_t::tracked_t> ex,
                   std::function<void()> callback)
{
  if (try_work() == done)
  {
    // Work completed immediately, invoke callback.
    execution::execute(ex, callback);
  }
  else
  {
    // Perform work in background. Track outstanding work.
    start_background_work(
        std::prefer(ex,
          execution::outstanding_work.tracked),
        callback);
  }
}

with no change in behavior or semantics.

However, if we simply specify execution::outstanding_work.tracked in the executor template parameter list, we will get a compile error due to the executor template not knowing that execution::outstanding_work.tracked is intended for use with prefer only. At the point of construction from an inline_executor called ex, executor will try to instantiate implementation templates that perform the ill-formed std::require(ex, execution::outstanding_work.tracked).

The prefer_only adapter addresses this by turning off the is_requirable attribute for a specific property. It would be used in the above example as follows:

void do_async_work(any_executor<prefer_only<execution::outstanding_work_t::tracked_t>> ex,
                   std::function<void()> callback)
{
  ...
}

– end example]

template<class InnerProperty>
struct prefer_only
{
  InnerProperty property;

  static constexpr bool is_requirable = false;
  static constexpr bool is_preferable = InnerProperty::is_preferable;

  using polymorphic_query_result_type = see-below; // not always defined

  template<class Executor>
    static constexpr auto static_query_v = see-below; // not always defined

  constexpr prefer_only(const InnerProperty& p);

  constexpr auto value() const
    noexcept(noexcept(std::declval<const InnerProperty>().value()))
      -> decltype(std::declval<const InnerProperty>().value());

  template<class Executor, class Property>
  friend auto prefer(Executor ex, const Property& p)
    noexcept(noexcept(std::prefer(std::move(ex), std::declval<const InnerProperty>())))
      -> decltype(std::prefer(std::move(ex), std::declval<const InnerProperty>()));

  template<class Executor, class Property>
  friend constexpr auto query(const Executor& ex, const Property& p)
    noexcept(noexcept(std::query(ex, std::declval<const InnerProperty>())))
      -> decltype(std::query(ex, std::declval<const InnerProperty>()));
};

If InnerProperty::polymorphic_query_result_type is valid and denotes a type, the template instantiation prefer_only<InnerProperty> defines a nested type polymorphic_query_result_type as a synonym for InnerProperty::polymorphic_query_result_type.

If InnerProperty::static_query_v is a variable template and InnerProperty::static_query_v<E> is well formed for some executor type E, the template instantiation prefer_only<InnerProperty> defines a nested variable template static_query_v as a synonym for InnerProperty::static_query_v.

constexpr prefer_only(const InnerProperty& p);

Effects: Initializes property with p.

constexpr auto value() const
  noexcept(noexcept(std::declval<const InnerProperty>().value()))
    -> decltype(std::declval<const InnerProperty>().value());

Returns: property.value().

Remarks: Shall not participate in overload resolution unless the expression property.value() is well-formed.

template<class Executor, class Property>
friend auto prefer(Executor ex, const Property& p)
  noexcept(noexcept(std::prefer(std::move(ex), std::declval<const InnerProperty>())))
    -> decltype(std::prefer(std::move(ex), std::declval<const InnerProperty>()));

Returns: std::prefer(std::move(ex), p.property).

Remarks: Shall not participate in overload resolution unless std::is_same_v<Property, prefer_only> is true, and the expression std::prefer(std::move(ex), p.property) is well-formed.

template<class Executor, class Property>
friend constexpr auto query(const Executor& ex, const Property& p)
  noexcept(noexcept(std::query(ex, std::declval<const InnerProperty>())))
    -> decltype(std::query(ex, std::declval<const InnerProperty>()));

Returns: std::query(ex, p.property).

Remarks: Shall not participate in overload resolution unless std::is_same_v<Property, prefer_only> is true, and the expression std::query(ex, p.property) is well-formed.

2.4.3 Polymorphic executor wrappers

The any_executor class template provides polymorphic wrappers for executors.

In several places in this section the operation CONTAINS_PROPERTY(p, pn) is used. All such uses mean std::disjunction_v<std::is_same<p, pn>...>.

In several places in this section the operation FIND_CONVERTIBLE_PROPERTY(p, pn) is used. All such uses mean the first type P in the parameter pack pn for which std::is_same_v<p, P> is true or std::is_convertible_v<p, P> is true. If no such type P exists, the operation FIND_CONVERTIBLE_PROPERTY(p, pn) is ill-formed.

template <class... SupportableProperties>
class any_executor
{
public:
  // construct / copy / destroy:

  any_executor() noexcept;
  any_executor(nullptr_t) noexcept;
  any_executor(const any_executor& e) noexcept;
  any_executor(any_executor&& e) noexcept;
  template<class... OtherSupportableProperties>
    any_executor(any_executor<OtherSupportableProperties...> e);
  template<class... OtherSupportableProperties>
    any_executor(any_executor<OtherSupportableProperties...> e) = delete;
  template<executor Executor>
    any_executor(Executor e);

  any_executor& operator=(const any_executor& e) noexcept;
  any_executor& operator=(any_executor&& e) noexcept;
  any_executor& operator=(nullptr_t) noexcept;
  template<executor Executor>
    any_executor& operator=(Executor e);

  ~any_executor();

  // any_executor modifiers:

  void swap(any_executor& other) noexcept;

  // any_executor operations:

  template <class Property>
  any_executor require(const Property& p) const;

  template <class Property>
  any_executor prefer(const Property& p);

  template <class Property>
  typename Property::polymorphic_query_result_type query(const Property& p) const;

  template<class Function>
    void execute(Function&& f) const;

  // any_executor capacity:

  explicit operator bool() const noexcept;

  // any_executor target access:

  const type_info& target_type() const noexcept;
  template<executor Executor> Executor* target() noexcept;
  template<executor Executor> const Executor* target() const noexcept;
};

// any_executor comparisons:

template <class... SupportableProperties>
bool operator==(const any_executor<SupportableProperties...>& a, const any_executor<SupportableProperties...>& b) noexcept;
template <class... SupportableProperties>
bool operator==(const any_executor<SupportableProperties...>& e, nullptr_t) noexcept;
template <class... SupportableProperties>
bool operator==(nullptr_t, const any_executor<SupportableProperties...>& e) noexcept;
template <class... SupportableProperties>
bool operator!=(const any_executor<SupportableProperties...>& a, const any_executor<SupportableProperties...>& b) noexcept;
template <class... SupportableProperties>
bool operator!=(const any_executor<SupportableProperties...>& e, nullptr_t) noexcept;
template <class... SupportableProperties>
bool operator!=(nullptr_t, const any_executor<SupportableProperties...>& e) noexcept;

// any_executor specialized algorithms:

template <class... SupportableProperties>
void swap(any_executor<SupportableProperties...>& a, any_executor<SupportableProperties...>& b) noexcept;

The any_executor class satisfies the executor concept requirements.

[Note: To meet the noexcept requirements for executor copy constructors and move constructors, implementations may share a target between two or more any_executor objects. –end note]

Each property type in the SupportableProperties... pack shall provide a nested type polymorphic_query_result_type.

The target is the executor object that is held by the wrapper.

any_executor() noexcept;

any_executor(nullptr_t) noexcept;

any_executor(const any_executor& e) noexcept;

any_executor(any_executor&& e) noexcept;

template<class... OtherSupportableProperties>
  any_executor(any_executor<OtherSupportableProperties...> e);

template<class... OtherSupportableProperties>
  any_executor(any_executor<OtherSupportableProperties...> e) = delete;

template<executor Executor>
  any_executor(Executor e);

any_executor& operator=(const any_executor& e) noexcept;

any_executor& operator=(any_executor&& e) noexcept;

any_executor& operator=(nullptr_t) noexcept;

template<executor Executor>
  any_executor& operator=(Executor e);

~any_executor();

void swap(any_executor& other) noexcept;

template <class Property>
any_executor require(const Property& p) const;

template <class Property>
any_executor prefer(const Property& p);

template <class Property>
typename Property::polymorphic_query_result_type query(const Property& p) const;

template<class Function>
  void execute(Function&& f) const;

explicit operator bool() const noexcept;

const type_info& target_type() const noexcept;

template<executor Executor> Executor* target() noexcept;
template<executor Executor> const Executor* target() const noexcept;

template<class... SupportableProperties>
bool operator==(const any_executor<SupportableProperties...>& a, const any_executor<SupportableProperties...>& b) noexcept;

template<class... SupportableProperties>
bool operator==(const any_executor<SupportableProperties...>& e, nullptr_t) noexcept;
template<class... SupportableProperties>
bool operator==(nullptr_t, const any_executor<SupportableProperties...>& e) noexcept;

template<class... SupportableProperties>
bool operator!=(const any_executor<SupportableProperties...>& a, const any_executor<SupportableProperties...>& b) noexcept;

template<class... SupportableProperties>
bool operator!=(const any_executor<SupportableProperties...>& e, nullptr_t) noexcept;
template<class... SupportableProperties>
bool operator!=(nullptr_t, const any_executor<SupportableProperties...>& e) noexcept;

template<class... SupportableProperties>
void swap(any_executor<SupportableProperties...>& a, any_executor<SupportableProperties...>& b) noexcept;

2.5.1 Header <thread_pool> synopsis

namespace std {

  class static_thread_pool;

} // namespace std

2.5.2 Class static_thread_pool

static_thread_pool is a statically-sized thread pool which may be explicitly grown via thread attachment. The static_thread_pool is expected to be created with the use case clearly in mind with the number of threads known by the creator. As a result, no default constructor is considered correct for arbitrary use cases and static_thread_pool does not support any form of automatic resizing.

static_thread_pool presents an effectively unbounded input queue and the execution functions of static_thread_pool’s associated executors do not block on this input queue.

[Note: Because static_thread_pool represents work as parallel execution agents, situations which require concurrent execution properties are not guaranteed correctness. –end note.]

class static_thread_pool
{
  public:
    using scheduler_type = see-below;
    using executor_type = see-below;
    
    // construction/destruction
    explicit static_thread_pool(std::size_t num_threads);
    
    // nocopy
    static_thread_pool(const static_thread_pool&) = delete;
    static_thread_pool& operator=(const static_thread_pool&) = delete;

    // stop accepting incoming work and wait for work to drain
    ~static_thread_pool();

    // attach current thread to the thread pools list of worker threads
    void attach();

    // signal all work to complete
    void stop();

    // wait for all threads in the thread pool to complete
    void wait();

    // placeholder for a general approach to getting schedulers from 
    // standard contexts.
    scheduler_type scheduler() noexcept;

    // placeholder for a general approach to getting executors from 
    // standard contexts.
    executor_type executor() noexcept;
};

For an object of type static_thread_pool, outstanding work is defined as the sum of:

• the number of existing executor objects associated with the static_thread_pool for which the execution::outstanding_work.tracked property is established;

• the number of function objects that have been added to the static_thread_pool via the static_thread_pool executor, scheduler and sender, but not yet invoked; and

• the number of function objects that are currently being invoked within the static_thread_pool.

The static_thread_pool member functions scheduler, executor, attach, wait, and stop, and the associated schedulers’, senders` and executors’ copy constructors and member functions, do not introduce data races as a result of concurrent invocations of those functions from different threads of execution.

A static_thread_pool’s threads run execution agents with forward progress guarantee delegation. [Note: Forward progress is delegated to an execution agent for its lifetime. Because static_thread_pool guarantees only parallel forward progress to running execution agents; i.e., execution agents which have run the first step of the function object. –end note]

using scheduler_type = see-below;

using executor_type = see-below;

static_thread_pool(std::size_t num_threads);

~static_thread_pool();

void attach();

void stop();

void wait();

scheduler_type scheduler() noexcept;

executor_type executor() noexcept;

2.5.3 static_thread_pool scheduler types

All scheduler types accessible through static_thread_pool::scheduler(), and subsequent invocations of the member function require, conform to the following specification.

class C
{
  public:

    // types:

    using sender_type = see-below;

    // construct / copy / destroy:

    C(const C& other) noexcept;
    C(C&& other) noexcept;

    C& operator=(const C& other) noexcept;
    C& operator=(C&& other) noexcept;

    // scheduler operations:

    see-below require(const execution::allocator_t<void>& a) const;
    template<class ProtoAllocator>
    see-below require(const execution::allocator_t<ProtoAllocator>& a) const;

    see-below query(execution::context_t) const noexcept;
    see-below query(execution::allocator_t<void>) const noexcept;
    template<class ProtoAllocator>
    see-below query(execution::allocator_t<ProtoAllocator>) const noexcept;

    bool running_in_this_thread() const noexcept;
};

bool operator==(const C& a, const C& b) noexcept;
bool operator!=(const C& a, const C& b) noexcept;

Objects of type C are associated with a static_thread_pool.

C(const C& other) noexcept;

C(C&& other) noexcept;

C& operator=(const C& other) noexcept;

C& operator=(C&& other) noexcept;

see-below require(const execution::allocator_t<void>& a) const;

template<class ProtoAllocator>
  see-below require(const execution::allocator_t<ProtoAllocator>& a) const;

static_thread_pool& query(execution::context_t) const noexcept;

see-below query(execution::allocator_t<void>) const noexcept;
see-below query(execution::allocator_t<ProtoAllocator>) const noexcept;

bool running_in_this_thread() const noexcept;

bool operator==(const C& a, const C& b) noexcept;

bool operator!=(const C& a, const C& b) noexcept;

class C
{
  public:
    sender_type schedule() noexcept;
};

  sender_type schedule() noexcept;

2.5.4 static_thread_pool sender types

All sender types accessible through static_thread_pool::scheduler().schedule(), and subsequent invocations of the member function require, conform to the following specification.

class C
{
  public:

    // construct / copy / destroy:

    C(const C& other) noexcept;
    C(C&& other) noexcept;

    C& operator=(const C& other) noexcept;
    C& operator=(C&& other) noexcept;

    // sender operations:

    see-below require(execution::blocking_t::never_t) const;
    see-below require(execution::blocking_t::possibly_t) const;
    see-below require(execution::blocking_t::always_t) const;
    see-below require(execution::relationship_t::continuation_t) const;
    see-below require(execution::relationship_t::fork_t) const;
    see-below require(execution::outstanding_work_t::tracked_t) const;
    see-below require(execution::outstanding_work_t::untracked_t) const;
    see-below require(const execution::allocator_t<void>& a) const;
    template<class ProtoAllocator>
    see-below require(const execution::allocator_t<ProtoAllocator>& a) const;

    static constexpr execution::bulk_guarantee_t query(execution::bulk_guarantee_t) const;
    static constexpr execution::mapping_t query(execution::mapping_t) const;
    execution::blocking_t query(execution::blocking_t) const;
    execution::relationship_t query(execution::relationship_t) const;
    execution::outstanding_work_t query(execution::outstanding_work_t) const;
    see-below query(execution::context_t) const noexcept;
    see-below query(execution::allocator_t<void>) const noexcept;
    template<class ProtoAllocator>
    see-below query(execution::allocator_t<ProtoAllocator>) const noexcept;

    bool running_in_this_thread() const noexcept;
};

bool operator==(const C& a, const C& b) noexcept;
bool operator!=(const C& a, const C& b) noexcept;

Objects of type C are associated with a static_thread_pool.

C(const C& other) noexcept;

C(C&& other) noexcept;

C& operator=(const C& other) noexcept;

C& operator=(C&& other) noexcept;

see-below require(execution::blocking_t::never_t) const;
see-below require(execution::blocking_t::possibly_t) const;
see-below require(execution::blocking_t::always_t) const;
see-below require(execution::relationship_t::continuation_t) const;
see-below require(execution::relationship_t::fork_t) const;
see-below require(execution::outstanding_work_t::tracked_t) const;
see-below require(execution::outstanding_work_t::untracked_t) const;

see-below require(const execution::allocator_t<void>& a) const;

template<class ProtoAllocator>
  see-below require(const execution::allocator_t<ProtoAllocator>& a) const;

static constexpr execution::bulk_guarantee_t query(execution::bulk_guarantee_t) const;

static constexpr execution::mapping_t query(execution::mapping_t) const;

execution::blocking_t query(execution::blocking_t) const;
execution::relationship_t query(execution::relationship_t) const;
execution::outstanding_work_t query(execution::outstanding_work_t) const;

static_thread_pool& query(execution::context_t) const noexcept;

see-below query(execution::allocator_t<void>) const noexcept;
see-below query(execution::allocator_t<ProtoAllocator>) const noexcept;

bool running_in_this_thread() const noexcept;

bool operator==(const C& a, const C& b) noexcept;

bool operator!=(const C& a, const C& b) noexcept;

class C
{
  public:
    template<template<class...> class Tuple, template<class...> class Variant>
      using value_types = Variant<Tuple<>>;
    template<template<class...> class Variant>
      using error_types = Variant<exception_ptr>;
    static constexpr bool sends_done = true;

    template<receiver_of R>
      see-below connect(R&& r) const;
};

template<receiver_of R>
  see-below connect(R&& r) const;

2.5.5 static_thread_pool executor types

All executor types accessible through static_thread_pool::executor(), and subsequent invocations of the member function require, conform to the following specification.

class C
{
  public:

    // types:

    using shape_type = size_t;
    using index_type = size_t;

    // construct / copy / destroy:

    C(const C& other) noexcept;
    C(C&& other) noexcept;

    C& operator=(const C& other) noexcept;
    C& operator=(C&& other) noexcept;

    // executor operations:

    see-below require(execution::blocking_t::never_t) const;
    see-below require(execution::blocking_t::possibly_t) const;
    see-below require(execution::blocking_t::always_t) const;
    see-below require(execution::relationship_t::continuation_t) const;
    see-below require(execution::relationship_t::fork_t) const;
    see-below require(execution::outstanding_work_t::tracked_t) const;
    see-below require(execution::outstanding_work_t::untracked_t) const;
    see-below require(const execution::allocator_t<void>& a) const;
    template<class ProtoAllocator>
    see-below require(const execution::allocator_t<ProtoAllocator>& a) const;

    static constexpr execution::bulk_guarantee_t query(execution::bulk_guarantee_t) const;
    static constexpr execution::mapping_t query(execution::mapping_t) const;
    execution::blocking_t query(execution::blocking_t) const;
    execution::relationship_t query(execution::relationship_t) const;
    execution::outstanding_work_t query(execution::outstanding_work_t) const;
    see-below query(execution::context_t) const noexcept;
    see-below query(execution::allocator_t<void>) const noexcept;
    template<class ProtoAllocator>
    see-below query(execution::allocator_t<ProtoAllocator>) const noexcept;

    bool running_in_this_thread() const noexcept;
};

bool operator==(const C& a, const C& b) noexcept;
bool operator!=(const C& a, const C& b) noexcept;

Objects of type C are associated with a static_thread_pool.

C(const C& other) noexcept;

C(C&& other) noexcept;

C& operator=(const C& other) noexcept;

C& operator=(C&& other) noexcept;

see-below require(execution::blocking_t::never_t) const;
see-below require(execution::blocking_t::possibly_t) const;
see-below require(execution::blocking_t::always_t) const;
see-below require(execution::relationship_t::continuation_t) const;
see-below require(execution::relationship_t::fork_t) const;
see-below require(execution::outstanding_work_t::tracked_t) const;
see-below require(execution::outstanding_work_t::untracked_t) const;

see-below require(const execution::allocator_t<void>& a) const;

template<class ProtoAllocator>
  see-below require(const execution::allocator_t<ProtoAllocator>& a) const;

static constexpr execution::bulk_guarantee_t query(execution::bulk_guarantee_t) const;

static constexpr execution::mapping_t query(execution::mapping_t) const;

execution::blocking_t query(execution::blocking_t) const;
execution::relationship_t query(execution::relationship_t) const;
execution::outstanding_work_t query(execution::outstanding_work_t) const;

static_thread_pool& query(execution::context_t) const noexcept;

see-below query(execution::allocator_t<void>) const noexcept;
see-below query(execution::allocator_t<ProtoAllocator>) const noexcept;

bool running_in_this_thread() const noexcept;

bool operator==(const C& a, const C& b) noexcept;

bool operator!=(const C& a, const C& b) noexcept;

class C
{
  public:
    template<class Function>
      void execute(Function&& f) const;

    template<class Function>
      void bulk_execute(Function&& f, size_t n) const;
};

template<class Function>
  void execute(Function&& f) const;

template<class Function>
  void bulk_execute(Function&& f, size_t n) const;

2.6.1 Revision 14

Fixed many editorial issues and these bug fixes:

• as-receiver::set_error() should accept any error type, not just std::exception_ptr
• execution::connect should require its second argument to satisfy receiver
• Constrain recursion in sender_to and executor_of concepts
• any_executor’s FIND_CONVERTIBLE_PROPERTY can lead to wrong results
• Generic blocking adapter is not implementable

2.6.2 Revision 13

As directed by SG1 at the 2020-02 Prague meeting, we have split the submit operation into the primitive operations connect and start.

2.6.3 Revision 12

Introduced introductory design discussion which replaces the obsolete P0761. No normative changes.

2.6.4 Revision 11

As directed by SG1 at the 2019-07 Cologne meeting, we have implemented the following changes suggested by P1658 and P1660 which incorporate “lazy” execution:

• Eliminated all interface-changing properties.
• Introduced set_value, set_error, set_done, execute, submit, and bulk_execute customization point objects.
• Introduced executor, executor_of, receiver, receiver_of, sender, sender_to, typed_sender, and scheduler concepts.
• Renamed polymorphic executor to any_executor.
• Introduced invocable_archetype.
• Eliminated OneWayExecutor and BulkOneWayExecutor requirements.
• Eliminated is_executor, is_oneway_executor, and is_bulk_oneway_executor type traits.
• Eliminated interface-changing properties from any_executor.

2.6.5 Revision 10

As directed by LEWG at the 2018-11 San Diego meeting, we have migrated the property customization mechanism to namespace std and moved all of the details of its specification to a separate paper, P1393. This change also included the introduction of a separate customization point for interface-enforcing properties, require_concept. The generalization also necessitated the introduction of is_applicable_property_v in the properties paper, which in turn led to the introduction of is_executor_v to express the applicability of properties in this paper.

2.6.6 Revision 9

As directed by the SG1/LEWG straw poll taken during the 2018 Bellevue executors meeting, we have separated The Unified Executors programming model proposal into two papers. This paper contains material related to one-way execution which the authors hope to standardize with C++20 as suggested by the Bellevue poll. P1244 contains remaining material related to dependent execution. We expect P1244 to evolve as committee consensus builds around a design for dependent execution.

This revision also contains bug fixes to the allocator_t property which were originally scheduled for Revision 7 but were inadvertently omitted.

2.6.7 Revision 8

Revision 8 of this proposal makes interface-changing properties such as oneway mutually exclusive in order to simplify implementation requirements for executor adaptors such as polymorphic executors. Additionally, this revision clarifies wording regarding execution agent lifetime.

2.6.8 Revision 7

Revision 7 of this proposal corrects wording bugs discovered by the authors after Revision 6’s publication.

• Enhanced static_query_v to result in a default property value for executors which do not provide a query function for the property of interest
• Revise then_execute and bulk_then_execute’s operational semantics to allow user functions to handle incoming exceptions thrown by preceding execution agents
• Introduce exception_arg to disambiguate the user function’s exceptional overload from its nonexceptional overload in then_execute and bulk_then_execute

2.6.9 Revision 6

Revision 6 of this proposal corrects bugs and omissions discovered by the authors after Revision 5’s publication, and introduces an enhancement improving the safety of the design.

• Enforce mutual exclusion of behavioral properties via the type system instead of via convention
• Introduce missing execution::require adaptations
• Allow executors to opt-out of invoking factory functions when appropriate
• Various bug fixes and corrections

2.6.10 Revision 5

Revision 5 of this proposal responds to feedback requested during the 2017 Albuquerque ISO C++ Standards Committee meeting and introduces changes which allow properties to better interoperate with polymorphic executor wrappers and also simplify execution::require’s behavior.

• Defined general property type requirements
• Elaborated specification of standard property types
• Simplified execution::require’s specification
• Enhanced polymorphic executor wrapper
  • Templatized execution::executor<SupportableProperties...>
  • Introduced prefer_only property adaptor
• Responded to Albuquerque feedback
  • From SG1
    • Execution contexts are now optional properties of executors
    • Eliminated ill-specified caller-agent forward progress properties
    • Elaborated Future’s requirements to incorporate forward progress
    • Reworded operational semantics of execution functions to use similar language as the blocking properties
    • Elaborated static_thread_pool’s specification to guarantee that threads in the bool boost-block their work
    • Elaborated operational semantics of execution functions to note that forward progress guarantees are specific to the concrete executor type
  • From LEWG
    • Eliminated named BaseExecutor concept
    • Simplified general executor requirements
    • Enhanced the OneWayExecutor introductory paragraph
    • Eliminated has_*_member type traits
• Minor changes
  • Renamed TS namespace from concurrency_v2 to executors_v1
  • Introduced static_query_v enabling static queries
  • Eliminated unused property_value trait
  • Eliminated the names allocator_wrapper_t and default_allocator

2.6.11 Revision 4

• Specified the guarantees implied by bulk_sequenced_execution, bulk_parallel_execution, and bulk_unsequenced_execution

2.6.12 Revision 3

• Introduced execution::query() for executor property introspection
• Simplified the design of execution::prefer()
• oneway, twoway, single, and bulk are now require()-only properties
• Introduced properties allowing executors to opt into adaptations that add blocking semantics
• Introduced properties describing the forward progress relationship between caller and agents
• Various minor improvements to existing functionality based on prototyping

2.6.13 Revision 2

• Separated wording from explanatory prose, now contained in paper P0761
• Applied the simplification proposed by paper P0688

2.6.14 Revision 1

• Executor category simplification
• Specified executor customization points in detail
• Introduced new fine-grained executor type traits
  • Detectors for execution functions
  • Traits for introspecting cross-cutting concerns
    • Introspection of mapping of agents to threads
    • Introspection of execution function blocking behavior
• Allocator support for single agent execution functions
• Renamed thread_pool to static_thread_pool
• New introduction

2.6.15 Revision 0

• Initial design