P3980R0 — Task's Allocator Use (10 items) LEWG, LWG
Dietmar Kühl
This paper addresses several NB comments (US 253-386, US 254-385, US 255-384, US 261-391) concerning the use of allocators in std::execution::task. It proposes that the allocator used for the coroutine frame should be specified via an allocator_arg/allocator pair (preferably as the first arguments), while the allocator forwarded through task's environment to child senders should be obtained from the receiver's environment via get_allocator, separating these two concerns. The paper presents multiple wording alternatives and includes the preferred approach of requiring allocator_arg as the first argument and deriving the environment allocator from the connected receiver.

References — Anthropic Citations API

[1]
"Change [task.promise] pargraph 17 and 18 to use the correct type"
[2]
"Change [task.promise] pargraph 17 and 18 to use the correct type and don't convert to allocator_type"
[3]
"No allocator support (none): the use identical and just doesn't mention any allocator."
[4]
"the use can be identical but it can also be simplied taking advantage of the flexible location."
[5]
"Note that the allocator used for the coroutine frame is normally not used in the body of the allocator."
[6]
"[task.promise] p16" with href "https://wg21.link/task.pomise#16""
[7]
"Declaration: `state connect(Rcvr&& recv) &&;` / Mandates: `allocator_type(get_allocator(get_env(rcvr)))`"
[8]
"(18.2) `allocator_type(arg_next)` is a valid expression if there is a parameter of type `allocator_arg_t`."
[9]
"cb7 line 9: `class... Args` (ASCII) vs cb7 line 11: `class … Args` (Unicode U+2026)"
Summary: P3980R0 proposes changes to the allocator handling for std::execution::task so that the coroutine frame allocator is consistently passed as the first coroutine function parameter (of type const allocator_arg_t&) and made accessible within the coroutine body via the promise, rather than only being used implicitly for frame allocation. It provides wording changes to [task.promise] to implement this.
Pipeline: Discovery (Anthropic Opus + Citations API) → Verification Gate (OpenRouter Opus) → Report Writer (OpenRouter Opus)
Provenance: All references are machine-verified character positions from the Anthropic Citations API — deterministic, exact substrings, not model-generated quotes.