This paper is a research report drawn from working code: a complete coroutine-only networking library.

This is the sentence I've been waiting to read in a WG21 paper for six years. Not "we think this could work." Not "future work includes implementation." They built the thing, benchmarked it, and now they're telling us what they found. More papers should work this way.

The core design decision is the two-argument await_suspend:

coroutine_handle<> await_suspend(
    coroutine_handle<> cont,
    io_env const* env);

Standard awaitables take one argument. This takes two - the second carries the executor, stop token, and frame allocator. The upside: compile-time protocol checking. If you co_await an IoAwaitable from a non-conforming promise, you get a compile error, not a silent runtime bug. The downside: IoAwaitables don't compose with standard awaitables. You're in the IoAwaitable world or you're not.

The paper addresses this explicitly - the static_assert in await_transform catches mismatches at the right point. It's a deliberate walled garden with a clearly marked door.

The frame allocator uses thread-local storage for propagation. Section 5.5 addresses the concerns - fibers, thread migration, M:N schedulers - and argues the window is narrow (set before operator new, cleared after allocation). But TLS for a critical-path resource makes me nervous.

What happens when someone runs this on a fiber-based scheduler that multiplexes coroutines across threads? The paper says "the thread-local is written immediately before the coroutine allocation and read immediately during allocation" so the window is tiny. But tiny is not zero.

The paper positions this as "coroutines for I/O" but std::execution already handles I/O through senders. P2762 has been exploring sender-based networking. The committee already made a strategic decision that networking should be based on P2300. This paper is proposing a parallel, incompatible model.

The protocol is genuinely small. Two concepts, one struct, one type-erased executor. That's the entire public surface. Compare to the surface area of std::execution sender algorithms. The paper's line about narrow abstractions - iterators, RAII, allocators - is earned here. IoAwaitable captures one thing: how a coroutine gets its I/O context.

We could not find anything to remove from it without losing function.

Saint-Exupéry would approve.

Every three years someone proposes networking for C++. Every three years the committee argues about whether it should be based on the current executor/async model du jour. This has been going on since 2005. The Networking TS. The Executors TS. Now senders. Now this. At least this one has a working library.

Section 6 makes a strong case for coroutine frames as natural type erasure. A task<T> erases everything behind a coroutine_handle<>. You get runtime polymorphism without virtual functions. The any_read_stream example in Appendix B shows how this enables type-erased I/O streams with one template parameter instead of the usual template spaghetti.

Same authors as P4007R0 and P4014R0. Three papers, one argument: I/O should use coroutines directly, not route through senders. The committee will want to see analysis from someone who doesn't have a competing library before treating this as settled direction. That said, the implementation experience is real, and the Asio design lineage is decades deep.

The executor_ref type erasure is clean. Two function pointers (dispatch and post), one void pointer for context. That's the entire executor interface. No concepts, no traits, no customization points. A socket just needs to know how to resume a coroutine. executor_ref tells it how.

Appendix A is the best introduction to async I/O fundamentals I've read in a WG21 paper. Event loops, completion handlers, executors, strands, cancellation - explained from scratch with diagrams. Every new C++ developer writing networking code should start there.

Cancellation through std::stop_token propagating from launch site to I/O object to platform primitive (CancelIoEx, IORING_OP_ASYNC_CANCEL). Cooperative, composable, and it builds on what's already in the standard. This is how cancellation should work for I/O.

Between P4003 (the protocol), P4007 (the sender boundary analysis), P4014 (the sub-language guide), and P2583 (symmetric transfer gap) - there are now four papers making the case for coroutine I/O as a first-class model. The committee can agree or disagree but they can't say the case hasn't been made.

The execution context owning its I/O objects maps directly to how io_uring and IOCP actually work. The socket knows its ring. The operation goes through that ring. The completion comes back on that ring. This is what a platform-native design looks like when you don't force an abstraction layer between the coroutine and the kernel.

Suggested straw poll: "Coroutine-driven async I/O should have the same freedom to optimize for its domain as heterogeneous compute did." I predict SF/F/N/A/SA of roughly 4/8/5/3/2. Not unanimous. Not killed. Enough to keep the direction alive.

Can we please just get sockets in the standard. I don't care if they're sender-based, coroutine-based, or pigeon-based. Just ship something.

I've been using Rust's Tokio for three years now. Every time I read a WG21 paper about C++ async I feel like I'm watching a documentary about the space shuttle program. Impressive engineering. Decade-long timelines. Enormous cost. And my TCP server already works.

committee gonna committee