Remove Default Candidate Executor

ABSTRACT


This paper proposes that ​associated_executor​ not provide a default candidate type.

BACKGROUND

The Networking TS [1] introduces “associators:” Binary class templates whose arguments are the “source type” and the “candidate type” (respectively) (§13.2.7.8 [async.reqmts.associator]). A default (the “default candidate type”) is required to be provided for the “candidate type” (i.e. an associator must be usable as if it were a unary class template).


The purpose of an associator is to obtain an instance of an “associated object” based on a “source object” (an instance of the source type) and optionally a “candidate object” (an instance of the candidate type). The type of the associated object (i.e. the “associated type”) is available through the ​type​ member type alias and the actual computation of the associated object may be performed via the ​get​ static member function. This member function must be invocable as if it were a unary or binary function (in the unary case only the source object is accepted whereas the binary case accepts both the source object and candidate object).


There are two associators provided by the Networking TS: ​associated_executor​ (§13.12 [async.assoc.exec]) and ​associated_allocator​ (§13.5 [async.assoc.alloc]) which obtain objects whose types satisfy the ​Executor​ (§13.2.2 [async.reqmts.executor]) and ProtoAllocator​ (§13.2.1 [async.reqmts.proto.allocator]) named type requirements
(respectively). They have default candidate types ​system_executor​ and ​allocator (respectively).


P2149R0 [2] was written in response to discussion in Prague 2020 SG4 which brought the design and usability of ​system_executor​ into question. P2149R0 proposed a two pronged solution.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2161r2.pdf

Stay in touch

arrow-white