can we please just get networking in the standard before I retire

the absolute state of C++ async:

2005: "we need networking"
2012: "we need executors first"
2017: "we need sender/receiver first"
2021: "sender/receiver covers networking"
2023: "actually only sender/receiver for networking"
2026: "actually there's a third way"
2029: "we need to unify the three ways first"
2032: networking

Ok, I actually read the paper. Twice. Here's where I landed.

The comparison table in Section 6 is the strongest argument in the paper and I'm surprised it's buried that deep. The key row is await_ready can return true - for awaitables yes, for senders "structurally impossible." That's not a minor difference. If your I/O completes synchronously (data already in the kernel buffer, say), the awaitable path can skip the suspension entirely. The sender path through connect/start cannot. For high-throughput byte streams where you're reading small chunks in a loop, that adds up.

The executor concept is basically Asio with coroutine_handle<> replacing completion handlers. That's... not a bad thing? The Networking TS executors were rejected partly because the completion handler model was clunky for coroutines. This strips it down to dispatch(continuation&) which returns a handle for symmetric transfer. Clean.

What I'm less convinced by:

1. The "structurally impossible" claim. It's true under P2300R10's current architecture, but the paper presents it as a fundamental limitation rather than an implementation choice. A sender could potentially define an await_ready-like fast path if the design cared to. The paper is right that P2300 doesn't, but "impossible" is doing a lot of heavy lifting.

2. The frame allocator via get_current_frame_allocator() / set_current_frame_allocator(). The paper doesn't say thread-local but that's the obvious implementation. What happens when you have work-stealing schedulers moving coroutines between threads? The "safe_resume" protocol is mentioned but deferred to P4172R0.

3. "The two belong in the standard together." This is the hard part. Not technically - conceptually. How does a user know when to reach for co_await socket.read_some(buf) vs execution::then(async_read(socket, buf), ...)? The paper says byte I/O is sequential and execution is DAG-shaped. Real programs aren't that clean.

That said - the code speaks for itself. Three platforms, a Compiler Explorer demo, and a derivatives exchange using it. That's more implementation experience than most papers bring to LEWG.

Firmware dev here. I opened this paper because of the frame allocator section and it didn't disappoint.

Section 3.5 numbers: MSVC with a recycling allocator hits 1265ms vs 3926ms with std::allocator. That's 3.1x. Not a micro-benchmark curiosity. That's the difference between "coroutines are too expensive" and "coroutines are fine actually."

The protocol propagates the allocator to every frame in the chain automatically. No allocator_arg_t in every signature. That's the right call.

We can't use coroutines right now because the frame allocation cost is unpredictable. If this protocol standardizes a way to plug in a pool allocator at launch and have it propagate silently, that changes the calculation. Not every embedded target can afford new/delete per coroutine frame, but a pre-allocated pool? That works.

I'll be watching what happens with get_current_frame_allocator() though. The paper is cagey about storage mechanism. Thread-local is fine for our use case (single-threaded event loop) but I know the multi-threaded crowd will have opinions.

Let me push on the "structurally impossible" claim in Section 6.

await_ready can return true - Yes (awaitable) / No - structurally impossible (sender)

The paper says this is because connect(sndr, rcvr) creates an operation state that must be start()-ed. But there's nothing stopping a sender-based wrapper from checking whether the operation has already completed before suspending. You could have an as_awaitable that calls connect + start, and if the receiver is synchronously signaled, sets a flag that makes await_ready return true.

That's not "structurally impossible." It's "not how P2300R10 is currently specified" and "would require implementation effort." Those are different.

Edit: Actually, re-reading more carefully - the paper's point might be that start() is a void-returning function that signals completion through the receiver, not as a return value. So you'd need the receiver to set a thread-local flag or something. Which... is exactly what the paper is doing with frame allocators. Hmm.

Edit2: OK I think the accurate statement is "structurally more expensive, not structurally impossible." The synchronous path exists but costs you the connect + start overhead plus a flag check. For byte I/O in a tight loop that matters. Conceding the point partially.

For anyone who wants to see the actual protocol without reading the full paper, here's the minimum viable IoAwaitable:

struct my_read_awaitable {
    bool await_ready() noexcept { return has_data_; }

    void await_suspend(
        std::coroutine_handle<> h,
        io_env const* env) {
        // submit to OS, executor resumes us
        env->executor.post(cont_);
    }

    std::pair<error_code, size_t>
    await_resume() noexcept { return {ec_, n_}; }
};

The two-argument await_suspend is the whole protocol. The io_env* gives you executor, stop token, and frame allocator. That's it. Everything else in the paper is infrastructure around this one signature.

Godbolt demo from the paper: godbolt.org/z/Wzrb7McrT

Process analysis of the straw polls in Section 7:

Polls 1-2 are the gates. If the committee doesn't agree that this is a distinct approach AND that new research warrants consideration, polls 3-5 never happen.

Poll 1 is straightforward - yes, coroutine-native I/O is distinct from both the Networking TS executor model and S/R. Nobody's disputing that.

Poll 2 is the real fight. "New research... warrants consideration" is polite for "please re-open a question you thought was settled." The Kona SG4 poll was consensus. Some committee members will view this as relitigating. Others will say three platforms + production deployment + SG14 backing is exactly the kind of new information that justifies revisiting.

Polls 3-5 are technical. Frame allocator propagation, separate compilation, advancing the protocol. These are the easy votes IF polls 1-2 pass.

My prediction: polls 1-2 get rough consensus but with real SA votes. The old guard who drove the Kona decision aren't going to be happy. This will be a contentious session.

I just want to point out that we are in year 21 of the C++ networking saga and the current state of the art is five competing proposals, three history papers explaining why we have five competing proposals, and a companion paper explaining the companion paper to the paper explaining the proposal.

The paper itself says P0592R0 listed networking as a C++20 priority. C++20 shipped five years ago. We're talking about C++29 now.

I'm going to go write a Python script that does what this paper does in 3 lines and then cry into my CMakeLists.txt.

As someone who used Beast heavily before switching shops - Falco knows the networking space. Beast is battle-tested in production at scale. The execution_context + service model in Section 4 is clearly descended from Asio, which is both a strength (proven design) and a weakness (some committee members have Asio fatigue).

The real question is whether the committee can evaluate this on technical merit or whether it'll get caught in the political crossfire between the P2300 camp and the "just ship the Networking TS already" camp. This paper tries to position itself as a "third way" but the executor model is close enough to Asio that opponents will call it Asio-with-coroutines.

Which... it kind of is? And that might be fine?

Meanwhile in Rust:

let mut buf = [0u8; 1024];
let n = socket.read(&mut buf).await?;

One line. No concepts. No frame allocators. No executor model. No companion paper. No twenty-year standards process.

I'm not saying "just use Rust" but I am gesturing in its general direction.