Paper Metadata

Document: P2300R10 · Title: std::execution · Authors: Michał Dominiak, Lewis Baker, Lee Howes, Kirk Shoop, Michael Garland, Eric Niebler, Bryce Adelstein Lelbach · Date: 2024-06-28 · Target: LEWG, LWG · Revision: R10 (previous: R9)

I am a bot, and this action was performed automatically. Please contact the moderators if you have any questions.

I’ve been waiting for a standard async framework since I started my C++ career. I’m about to retire.

The biggest under-discussed change in R10 is the removal of ensure_started and start_detached. These were the escape hatches—the “I need to fire off some work and not block on it” tools. Their removal forces every use of senders into a fully structured concurrency model where every operation must be awaited through a scope.

The paper points to P3149 (async_scope) as the replacement, but P3149 is a separate paper that isn’t in the same revision. So we’re shipping the async framework without the tool you need for one of the most common async patterns. It’s like shipping <algorithm> but putting std::sort in a companion paper.

I understand why they were removed. P3187R1 makes a solid case that ensure_started is a foot-gun—if the returned sender is destroyed before the operation completes, you get detached work, which is exactly the problem structured concurrency is supposed to solve. But the alternative is “wait for async_scope to ship.” In the meantime, users who need fire-and-forget have to either roll their own or reach for the reference implementation’s extensions.

ensure_started, start_detached, execute, and execute_may_block_caller are removed from the proposal. They are to be replaced with safer and more structured APIs by “async_scope — Creating scopes for non-sequential concurrency”

That “to be replaced” is doing a lot of heavy lifting. Is the committee comfortable shipping a framework with this dependency on a not-yet-adopted companion paper?

So we now have a 150-page async execution framework in C++26, and you still can’t read from a socket. The paper doesn’t mention networking once. Not in the motivation, not in the examples, not in the design rationale.

Asio has been production-ready since 2003. Chris Kohlhoff has maintained it through twenty years of standardization chaos. The Networking TS was built on it. And instead of adopting the thing that works, we got a decade-long argument about whether execution resources should be lazy or eager, and now we have a framework that can parallelize std::inclusive_scan across a GPU but can’t open a TCP connection.

I get it. P2300 is “the foundation.” Networking comes “later.” P2762 shows how networking senders might look. But “later” has been the answer for networking since C++11, and I’m running out of patience.

committee gonna committee

Firmware developer here. The zero-allocation property of operation states is the part of this paper that nobody is talking about. When you connect a sender chain, the resulting operation state composes statically. The paper’s run_loop example uses space in its operation states to build an intrusive linked list of work items—all on the stack. Zero heap allocations.

Intel’s bare-metal implementation proves this works in constrained environments. I’ve been building ad-hoc versions of exactly this pattern for twenty years. Having it in the standard with proper type safety and composability is genuinely exciting.

The people complaining about complexity are looking at the implementer-facing API. The user-facing API for someone who just wants to compose then | continues_on | bulk is clean.

The paper’s priorities in section 1.2 say “Make it easy to be correct by construction.” Then section 1.5.1 shows the implementation of then—the simplest possible sender adaptor—and it requires:

• A custom receiver type with CRTP-like inheritance
• A sender type with a connect member and a get_completion_signatures member
• transform_completion_signatures_of<S, Env, _except_ptr_sig, _set_value_t>
• A connect_result_t return type
• Perfect forwarding with C-style casts ((F&&) f_)

For then. The “hello world” of sender adaptors. If you want to write a custom sender for your execution resource, the learning curve is vertical.

The user-facing API (schedule | then | continues_on) is genuinely nice. But the gap between “using senders” and “implementing senders” is the widest I’ve seen in any standard library feature, and that includes ranges.

Section 4.9.4 contains this remarkable admission:

It is important to note, however, that initial review of this design in the SG1 concurrency subgroup raised some concerns related to runtime overhead of the design in single-threaded scenarios and these concerns are still being investigated.

“Still being investigated.” In R10. The revision being proposed for the standard. The cancellation overhead concern from SG1 is documented but unresolved in the text that’s going into C++26.

To be clear: the design mitigates this with never_stop_token and unstoppable_token, which should let the compiler optimize out the cancellation path. But “should” and “does” are different things, and the paper itself isn’t confident enough to remove the caveat.

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

Section 4.10 is the most important part of this paper and the least discussed. The decision to make all senders lazy is what enables GPU kernel fusion, static operation state composition, and zero-overhead structured concurrency. If senders could be eager, every algorithm would need to handle the race between “the operation completed before connect was called” and “the operation hasn’t started yet,” which is exactly the std::future problem we’re trying to escape.

The paper lays out five failure modes of eager senders (UB on destruction, detached work, blocking destructors, type-erased stop callbacks, loss of execution context). Every one of them is a real bug I’ve debugged in production GPU code. Laziness eliminates all five by construction.

For people who haven’t been following: the committee history of this paper is wild.

• 2012: SG1 starts discussing executors (N3562)
• 2016: P0443 (Unified Executors) begins, goes through 14 revisions
• 2020: P2300R0 reformulates executors around senders/receivers
• Jan 2022: vote to forward P2300R4 to LWG for C++23: SF:23, WF:14, N:0, WA:6, SA:11. No consensus. Zero neutral votes.
• 2024: P3109 creates a concrete plan, builds consensus. P2300R10 is proposed for C++26.

The 2022 vote is the one to study. Thirty-seven people voted in favor, seventeen against, and nobody abstained. That vote tells you everything about how polarizing this design is. The fact that we got from there to a shippable proposal in two years is, frankly, impressive committee work.

I teach a graduate C++ course. My plan for integrating senders is: year one, coroutines and ranges; year two, senders. You need the prerequisites. Students need to be comfortable with concepts, operator| composition, and the idea of lazy evaluation before they can approach this.

The good news: the pipe syntax (schedule(sch) | then(f) | continues_on(other_sch) | then(g)) is genuinely intuitive once you’ve seen range adaptors. The bad news: the first time a student makes a mistake and gets a template error message, they’ll lose a week.

R10 changelog for names alone:

• transfer → continues_on
• on → starts_on
• New on = starts_on + continues_on
• get_delegatee_scheduler → get_delegation_scheduler
• read → read_env

R9 renamed in_place_stop_* to inplace_stop_*. R8 renamed make_completion_signatures to transform_completion_signatures_of. Every revision renames things. If you’ve been writing code against the reference implementation, you’ve rewritten your import statements every six months.

Has anyone noticed there’s no schedule_after or schedule_at? The paper mentions in section 4.2:

A time_scheduler concept that extends scheduler to support time-based scheduling. Such a concept might provide access to schedule_after(sched, duration), schedule_at(sched, time_point) and now(sched) APIs.

“Future papers.” So C++26 gets an async framework where you can't say “do this in 5 seconds.” Timer-based scheduling is one of the most basic async patterns—timeouts, debouncing, polling, heartbeats—and it’s deferred to a future standard.

The completion signatures mechanism (section 5.8) is probably the most underappreciated innovation in the paper. It’s a type-level protocol that lets a sender statically declare every way it can complete—value types, error types, and whether it can send stopped. This means the compiler can check at connect time whether the receiver can handle all possible completions.

Compare this to std::future<T>, which can only send one value type or an exception_ptr. Senders can send multiple different value types depending on runtime conditions, and the type system tracks all of them. That’s why you see things like into_variant—it collapses all possible value completions into a single variant type when you want to unify them.

// A sender that might send int or string depending on a condition
using sigs = completion_signatures<
  set_value_t(int),
  set_value_t(std::string),
  set_error_t(std::exception_ptr),
  set_stopped_t()
>;

Meanwhile Rust has had async/await since 2019, tokio has been production-ready for years, and their async story “just works.” But sure, let’s spend another decade debating whether senders should be lazy.

The author list is four NVIDIA employees and two Meta employees. The reference implementation is an NVIDIA project. The primary deployment is at NVIDIA and Meta. The design prioritizes GPU compute and large-scale server workloads, which are NVIDIA and Meta’s business domains.

This is a competent design for the problems the authors personally face. The committee should recognize that the recommendation to adopt this as the standard async model for all of C++ comes from authors with a documented advocacy position and commercial interest in this specific design direction. Corroborating analysis from authors outside the GPU/hyperscaler bubble would strengthen the case.

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

Want to 10x your C++ skills? Our Advanced C++ Masterclass covers async, coroutines, and more! Use code SENDERS20 for 20% off. learnmoderncpp.io

Game engine perspective: we evaluated stdexec for our ECS job system. The runtime performance was competitive with our hand-rolled fiber-based scheduler—within 5% on our benchmark suite. The structured concurrency model maps well to frame-scoped work: spawn all jobs for a frame, sync_wait at the frame boundary, guaranteed completion.

The compile times were brutal. Our job system compiles in 3 seconds. The stdexec version took 90 seconds for the same translation unit. For a game studio that does 200+ builds per day, that’s a non-starter. We’re watching this space but won’t adopt until compile times improve by at least 10x.

tangentially, has anyone benchmarked <execution> compile times compared to, say, <ranges> or <format>? My CI pipeline already takes 2 hours and I’m not thrilled about adding another heavy header.

I actually read the whole paper. All of it. Here’s what everyone is missing while arguing about naming and networking:

The sender algorithm customization mechanism in section 5.4 is the actual innovation. When you call then(snd, f), the algorithm doesn’t just wrap the sender in a generic adaptor. It queries the sender’s completion scheduler for an execution domain, and then asks that domain to transform_sender the algorithm. This means a CUDA scheduler can intercept bulk(snd, shape, f) and turn it into a GPU kernel launch without the user writing any GPU-specific code.

auto snd = schedule(cuda_sch)
         | then([] { return 42; })
         | bulk(1024, [](int i, int v) { /* runs on GPU */ });
// The CUDA domain intercepts bulk() and maps it
// to a kernel launch. No __global__, no <<<>>>.

This is why P3303R1 (fixing transform_sender in connect/get_completion_signatures) was critical for R10. Without it, the domain dispatch happened too early and the scheduler couldn’t see the full sender chain. The fix makes it lazy—transform happens at connect time, when the scheduler has full context.

This is the part that justifies the complexity. Not then. Not sync_wait. The domain dispatch is what makes senders a platform rather than just another callback library.

Unpopular opinion apparently: I’ve been using coroutines for 3 years and this is the first time I’ve seen a coherent story for async in C++ that doesn’t feel like duct tape. The pipe syntax is nice, the structured concurrency model is sound, and the fact that operation states compose on the stack without allocation is genuinely novel for a standard library feature. I’ll take it.

I work on a major compiler and the amount of work required to implement this header is... significant. The basic-sender exposition-only type alone has more moving parts than most standard headers. We’re looking at 6-12 months of implementation work after the wording is frozen. Users should not expect <execution> to be available in their compiler the day C++26 ships.

proposed wording for my codebase:

auto do_my_job = schedule(coffee_machine)
    | then([] { return read_email(); })
    | continues_on(panic_scheduler)
    | then([](auto email) {
        if (email.from == "CTO")
            return open_resume_site();
        return do_actual_work();
      })
    | bulk(99, [](int i, auto result) {
        // pretend to be productive
      });

I thought about this more and there’s a gap nobody’s mentioned: the interaction between senders and coroutines.

Section 5.7 says you can co_await a sender in a coroutine that uses with_awaitable_senders. That’s great. But the paper doesn’t provide a standard coroutine task type. So you can co_await senders, but only if you write your own promise type first. The gap between “coroutines exist” and “senders exist” and “they work together seamlessly” is still two or three papers wide.

is this the thread where we complain about executors taking too long, or the thread where we complain about them being too complicated? I want to make sure I’m posting in the right one.

Boost/Folly/libunifex already does this. But sure, let’s spend another meeting cycle on wording for get_delegation_scheduler.