The retry algorithm comparison is the whole paper in one slide.

Sender version: 100+ lines, deferred construction helper, receiver adaptor with CRTP, operation state lifecycle with std::optional, completion signature transformation, template metaprogramming across four struct definitions.

Coroutine version:

template <class F>
auto retry(F make_sender) -> task<T> {
    for (;;) {
        try {
            co_return co_await make_sender();
        } catch (...) {}
    }
}

Seven lines. Same behavior. I understand why the sender version exists - it handles the full completion signature algebra. But for the other 90% of us, this is the paper's strongest argument.

Section 4 is going to make some people uncomfortable. The paper traces Eric Niebler's published writing from 2017 to 2024 and documents the shift from "90% of all async code should be coroutines" to "senders are the foundation, coroutines are one way to consume them." It's all public blog posts with direct quotes and links. No private communications, no inference.

Whether you read this as "the emphasis changed as the target problems changed" or "the vision drifted" depends on which side of the sender/coroutine divide you sit on. But the timeline itself is just facts.

Whether you agree with the paper's conclusions or not, calling std::execution a "sub-language" is not loaded - it's accurate. The equivalence table in Section 2 maps sequential statements, local variables, return, try/catch, for/while, if/else, throw, and break/continue to sender primitives. When a library provides its own versions of every fundamental control flow construct, it has become a programming model, not an API.

Template metaprogramming is a sub-language. constexpr evaluation is a sub-language. The preprocessor is a sub-language. Calling senders a sub-language puts them in that category, which is descriptive, not pejorative. The paper even says it's "an achievement."

Three of four algorithms in the P2300R7 motivating example aren't in C++26. stop_when: removed. timeout: never proposed. first_successful: never proposed.

The motivating example motivates a library that doesn't exist.

I work on GPU dispatch pipelines. Senders give me zero-allocation composition with compile-time work graphs that the compiler can optimize end-to-end. Nothing else in C++ does this. The "complexity" in Section 5 is the complexity of expressing what I need expressed. If you don't need it, don't write sender algorithms - compose the existing ones.

Section 5.6, the backtracker example. I've read it three times. I still can't trace where the fail continuation goes through three levels of std::move and two nested let_value lambdas. This is a code review rejection in any codebase I've worked in.

The suggested straw polls are well-constructed. "std::execution serves coroutine-driven async I/O less ideally than heterogeneous compute." I don't think anyone on LEWG would disagree with that. The question is whether they'll actually take it and what follows from it.

The nvexec precedent argument in Section 6.2 is clever but it proves more than intended. nvexec reimplements every standard sender algorithm with CUDA extensions - bulk, then, when_all, continues_on, let_value, split, reduce - all in .cuh files. And it requires a non-standard compiler.

If the domain that senders were specifically designed for needs a complete reimplementation with non-standard extensions, maybe "universal asynchrony abstraction" was always the wrong goal. Maybe the right goal is domain-specific models that share boundaries. Which is... what the paper argues.

Points for putting the disclosure section first. The authors are upfront about having written P4003R0 (Coroutines for I/O) and P4007R0 (Senders and Coroutines). They have a position. They're telling you what it is before the argument starts.

The theoretical foundations table in Section 3 - Moggi (1991), Lambda Papers (1975), Danvy and Filinski (1990) - is the nerdiest thing I've read this week and I loved every line. They're really going back to first principles to explain why senders look the way they do. This should be required reading for anyone implementing a sender algorithm.

The trade-off table in Section 6.1 lists "long compile times" as a cost. I just want compile times to go down. Every new template-heavy feature makes it worse and my CI already takes 45 minutes.

Can we get networking in the standard before I retire. I started this job writing C++ in 2018.

Senders: solving yesterday's problems with tomorrow's compile times since 2020.

Is P2300 the new concepts? Years of design, massive committee investment, and a significant chunk of the community wondering if the cure is worse than the disease.

The zero-allocation property matters to me. In my world, malloc is a bug. Senders give me composable async without touching the heap. That's real. But I also write approximately zero networking code, so I have no opinion on the I/O question.

The standard is stronger when each domain gets the model it needs, and neither is forced to use the other's tool.

This is the most reasonable conclusion I've seen in any of the sender/coroutine papers. Nobody loses anything. GPU keeps senders. I/O gets coroutines. Both exist. Both are standardized. Done.

As someone who used Haskell for five years before switching to C++, seeing just mapped to monadic return and let_value mapped to bind made my entire career flash before my eyes. The paper is right that this is CPS. It's also right that most C++ developers never asked for CPS.

*laughs in Boost.Asio still working fine for my use case*

Meanwhile Rust shipped async/await, Tokio is the de facto standard runtime, and nobody argues about whether the abstraction is a sub-language. It just works.

I implemented a sender-based connection pool at work last year. Took three weeks. Reimplemented it with coroutines in four days. Both versions handle 40K concurrent connections. The coroutine version is 400 lines shorter and two junior devs can maintain it.

For anyone who wants more context, watch Eric Niebler's CppCon 2024 talk on senders and Lewis Baker's symmetric transfer talk. Two different perspectives from two people who both understand the design deeply.

The paper acknowledges that senders are "an achievement" and says the committee should be "proud of it." That's not a hit piece. It's asking for coexistence. I don't understand why that's controversial.

The "concurrent selection" row in the equivalence table being marked (absent) is doing a lot of quiet work. when_all shipped but its dual didn't. You can fork but you can't race.

Great, another paper that will take 10 years to get through LEWG.