Reminder: be civil. The paper authors sometimes read these threads.

The paper's strongest section is 3.3. Let me walk through it because I don't think most people are going to click through to the PDF.

P2300R10's own motivating example (Section 1.3.3) implements a composed read using sender pipelines. async_read completes through set_value with the byte count, or through set_error with the error code. If the second read fails partway through - connection reset after transferring some bytes - set_error fires. The byte count has no channel. then only handles set_value. The error propagates past it, the dynamic_buffer with its partially valid contents is destroyed.

To our knowledge, no published sender code - P2300R10, stdexec, Leahy's adaptor - discriminates the channel based on bytes transferred.

This is verifiable. Go check the stdexec repo. Check Leahy's use_sender adaptor. In the set_error path, the byte count is discarded.

For anyone who's done production socket programming: how many bytes transferred before the error matters. Connection reset after 47 bytes of a 1024-byte read is qualitatively different from connection reset after 0 bytes. Boost.Asio got this right twenty-five years ago with void(error_code, size_t). The three-channel model cannot express it without losing something.

can we please just get networking in the standard before I retire. this is like watching two people argue about the color of the bike shed while the building has no plumbing

inb4 "just use Rust" but seriously. Rust shipped tokio, async-std, and actual production networking years ago. we're still debating which channel an ECONNRESET goes through

I spent an hour with the PDF. Some observations from someone who uses both sender pipelines and coroutines in production:

The paper is better than most committee papers at separating observation from advocacy. The disclosure section opens by listing what the authors' own design can't do - compile-time work graphs, heterogeneous dispatch, cooperative runtime assumption. You don't see that often.

The strongest arguments, in order:

1. Section 3.3 - data loss. The claim that every published sender implementation of composed I/O loses partial results on the error path is verifiable and, as far as I can tell, correct. This isn't theoretical.

2. Section 7.5 - ABI lock-in. Once shipped, the three-channel model, connect/start, and void await_suspend become ABI. Closing any of the four gaps means changing these relationships. "Ship task is the risky choice, not the safe one" is a sentence that will make people uncomfortable because it might be right.

3. Section 5.4 - silent fallback. Forgetting allocator_arg at one call site falls back to std::allocator with no diagnostic. That's a production bug factory.

The weakest argument is Section 8, "Why Wait To Ship?" - it reads like a separate paper stapled on at the end. The cost-of-waiting analysis is thin compared to the gap analysis.

The task type table in 7.5 is devastating though. Every independent implementation: one template parameter. P3552: two. When the entire ecosystem converges on something and your design diverges, that's a signal.

From Section 4:

std::execution::task<std::size_t>
do_read(tcp_socket& s, buffer& buf)
{
    auto [ec, n] = co_await s.async_read(buf);
    if (ec)
        co_yield with_error(ec); // terminates the coroutine
    co_return n;
}

In every other coroutine context in the C++ ecosystem, co_yield means "produce a value and continue." Here it means "fail and terminate."

cppcoro, folly::coro, Boost.Cobalt, Boost.Asio, libcoro, asyncpp - six years of established practice. None uses co_yield for error signaling. P1713R0 proposed lifting the return_void/return_value restriction in 2019. No consensus in Cologne. Now P3950R0 proposes the same change because task requires it.

A language rule that served every coroutine library for a decade must be reconsidered because one library needs it. The rule is not the problem.

The committee has been here before. Two data points:

1. The P2300 deferral from C++23. Same pattern - ongoing design changes, open questions, "ship now iterate later" pressure. The committee deferred. std::execution got substantially better as a result.

2. The forwarding polls. "Forward P3552R1 to LWG for C++29" - SF:5 / F:7 / N:0 / A:0 / SA:0. Unanimous. "Forward P3552R1 to LWG with a recommendation to apply for C++26 (if possible)" - SF:5 / F:3 / N:4 / A:1 / SA:0. Weak consensus, with "if possible" qualifier.

C++29 was unanimous. C++26 was conditional and weak. Kühl himself filed sixteen open concerns in P3796R1. The frame allocator poll got five neutral votes and nothing else - the entire room abstained.

The paper's framing is right: shipping task is the risky choice, not the safe one.

I've been doing embedded C++ for two decades. Frame allocation overhead is not theoretical for us.

The benchmark table from Section 5 (4-deep coroutine call chain, 2M iterations):

MSVC with recycling allocator: 1265ms. MSVC with std::allocator: 3927ms. 3.1x speedup just by controlling the frame allocator.

To get that speedup with P3552, you need Appendix B's five-layer ceremony: custom environment type, task alias with that env, allocator_arg at every call site, environment construction at the launch site, write_env injection. Forgetting any one step silently falls back to std::allocator. No compile error, no warning, no diagnostic.

In production code with dozens of coroutine call sites, someone will miss one. Users will profile, see heap allocation cost, and conclude coroutines are slow. Coroutines are not slow. The fast path is too hard to use.

Edit: I checked the beman::task reference implementation. allocator_arg is the only propagation mechanism. No thread-local fallback, no automatic propagation.

the senders vs coroutines discourse has more revisions than the papers themselves at this point

I work in finance. The paper quotes Sutter: "We already use C++26's std::execution in production for an entire asset class." I believe it. We've evaluated stdexec. For work graph construction and deterministic pipelines it's excellent.

But my connection handler that processes 50K concurrent TCP sessions is not a GPU dispatch graph. ECONNRESET is not exceptional - it's every third connection on a bad day. Dimov's mapping routes (ECONNRESET, 0) through set_error. P3552's task delivers that as an exception. Stack unwinding for every client disconnect.

A server handling thousands of connections sees ECONNRESET constantly - clients disconnect, networks flap, load balancers probe, mobile users lose signal.

Boost.Asio got this right decades ago. if (ec) is the right model for I/O errors. The paper's recommendation - ship execution for its domains, let coroutine I/O iterate independently - is the pragmatic call.

Section 6 deserves more attention than it's getting in this thread. The symmetric transfer gap:

// Coroutine-native: constant stack
coroutine_handle<> await_suspend(
    coroutine_handle<> h) noexcept
{
    auto next = start(state);
    return next ? next : noop_coroutine();
}

// Sender bridge: stack grows
void await_suspend(
    coroutine_handle<> h) noexcept
{
    start(state); // .resume() within set_value
}

P2300's sender-awaitable uses void await_suspend. Synchronous completions call .resume() as a function call within set_value. Stack grows by one frame per synchronous completion. Sender algorithms are structs, not coroutines. No coroutine_handle exists at intermediate points. There is nothing to symmetric-transfer to.

P2583R0 surveys six production coroutine libraries. Five use symmetric transfer. Different authors, platforms, goals - same mechanism. P0913R1 was adopted specifically to enable this.

The table in Section 7.5 speaks for itself:

asyncpp: template<typename T> class task - 1 param.
Boost.Cobalt: template<typename T> class task - 1 param.
cppcoro: template<typename T> class task - 1 param.
libcoro: template<typename T> class task - 1 param.
P3552: template<typename T, typename Environment> class task - 2 params.

When every independent implementation converges on the same signature and your design diverges, that's not a feature. The second parameter leaks the sender model's execution environment into the coroutine's public API surface.

as someone who uses Boost.Asio daily for production networking, the paper's characterization of I/O error handling matches my experience exactly. ECONNRESET is not exceptional. it's Tuesday

I'm just here waiting for someone to benchmark what all those nested sender template types do to compile times

so let me get this straight. the authors of P4003 wrote a paper arguing that the committee should explore the approach described in P4003. I am shocked

can someone ELI5 what a sender even is? I've been writing async code with Asio for a year and I've never needed one