The Sender Sub-Language

C++20 provides symmetric transfer (P0913R1) - a mechanism where await_suspend returns a coroutine_handle<> and the compiler resumes the designated coroutine as a tail call. Coroutine chains execute in constant stack space. std::execution (P2300R10) composes asynchronous operations through sender algorithms. These algorithms create receivers that are structs, not coroutines. No coroutine_handle<> exists at any intermediate point in a sender pipeline. When a coroutine co_await s a sender that completes synchronously, the stack grows by one frame per completion. P3552R3’s std::execution::task inherits this property. The sender model’s zero-allocation composition property and symmetric transfer’s constant-stack property cannot both be satisfied. One requires structs. The other requires coroutines. This paper describes the mechanism, provides implementation experience, and documents the tradeoff.

C++20 coroutines have five properties that, taken together, make them uniquely suited to asynchronous I/O: type erasure through coroutine_handle<> , customization through promise_type , stackless independently resumable frames, symmetric transfer through await_suspend , and compiler-managed state that persists across suspension points. Each was designed for generality. Their conjunction yields something no single property suggests: the optimal basis for byte-oriented I/O.

We used C++20 coroutines directly for I/O - timers, sockets, DNS, TLS, HTTP - and observed what the language already provides. The protocol that emerged is the IoAwaitable: a system for associating a coroutine with an executor, stop token, and frame allocator, and propagating this context forward through a coroutine chain to the operating system API boundary where asynchronous operations are performed.

SG4 polled at Kona (November 2023) on P2762R2 “Sender/Receiver Interface For Networking”

“Networking should support only a sender/receiver model for asynchronous operations; the Networking TS’s executor model should be removed”

SF	F	N	A	SA
5	5	1	0	1

Consensus.

The approach described in this paper - a coroutine-native I/O model using C++20 language features - was not among the alternatives considered.

Poll 1. A coroutine-native I/O model is a distinct approach from both the Networking TS executor model and the sender/receiver model.

Poll 2. New research into coroutine-native I/O, not available at the time of the Kona poll, warrants consideration.

std::execution serves its domain well. Different asynchronous domains have different costs, and a single model cannot minimize all of them simultaneously. This paper identifies four structural gaps where the sender model meets coroutines: three at the boundary - error reporting, error returns, and frame allocator propagation - and one inside the composition mechanism - the symmetric transfer gap documented in P2583R0. Each gap is the cost of a property the sender model requires for compile-time analysis (P2300R10, P4014R0 ). They are not design defects, they are tradeoffs. Mandating that standard networking be built on the sender model would force coroutine I/O users to pay these costs. A coroutine-native I/O research report (P4003R0) made the gaps visible by showing that partial results, error returns, cancellation, and frame allocator propagation emerge naturally when I/O is designed for coroutines. The findings hold regardless of that report’s specific design. This paper recommends: ship std::execution for C++26, defer task (P3552R3, “Add a Coroutine Task Type”) to C++29, and explore coroutine-native I/O designs alongside sender-based designs.

1. “I/O completions that carry both an error code and a byte count present a design challenge for the three-channel completion model.”
2. “The coroutine integration in std::execution has open design questions that would benefit from further iteration.”
3. “WG21 should explore coroutine-native I/O designs alongside sender-based designs.”

C++26 introduces a rich sub-language for asynchronous programming through std::execution (P2300R10) . Sender pipelines replace C++’s control flow, variable binding, error handling, and iteration with library-level equivalents rooted in continuation-passing style and monadic composition. This paper is a guide to the Sender SubLanguage: its theoretical foundations, the programming model it provides, and the engineering trade-offs it makes. The trade-offs serve specific domains well. The question is whether other domains deserve the same freedom to choose the model that serves them.

1. “ std::execution serves coroutine-driven async I/O less ideally than heterogeneous compute.”
2. “Coroutine-driven async I/O should have the same freedom to optimize for its domain as heterogeneous compute did

1. Decouple Networking from std::execution SG14 advise that Networking (SG4) should not be built on top of P2300. The allocation patterns required by P2300 are incompatible with low-latency networking requirements.
2. Standardize "Direct Style" I/O Prioritize P4003 (or similar Direct Style concepts) as the C++29 Networking model. It offers the performance of Asio/Beast with the ergonomics of Coroutines, maintaining the "Zero-Overhead" principle.