P2300 std::execution (Senders/Receivers): A Case Study in Corporate Influence and Institutional Dysfunction
Great Founder Theory in C++
The Decade-Long Executor Wars (2012-2020)
The trajectory of P2300 (”std::execution”) represents perhaps the most protracted standardization battle in WG21 history, with origins tracing back to 2012 when executors discussions began in earnest (N3378). The initial proposal, P0443 (”A Unified Executors Proposal for C++”), emerged in late 2016 as a compromise among “such organisations and groups as Google, Sandia National Labs, Codeplay, Facebook, Nasdaq, Clearpool.io, Nvidia, Stellar Group, Microsoft, RedHat, HPX, HPC, and domains such as Ultra Low Latency Finance, Embedded Systems, APU, GPU, SYCL, Networking, Machine Learning, Library Development and Big Data.” One historical account notes that “more than 100 papers and revisions have been produced that either directly or indirectly have significantly impacted the consensus position represented by P0443.” This extraordinary volume of paper churn—unprecedented in WG21 history—reflects not productive iteration but rather factional gridlock, with each corporate constituency defending domain-specific requirements as “universal” necessities.
Chris Kohlhoff, the author of Boost.Asio and the Networking TS, had been contributing executor proposals since at least 2014 (N4046). P0443 was shaped heavily by the Networking TS’s requirements, creating what critics would later call an implicit assumption that executors existed primarily to serve asynchronous I/O patterns. The proposal achieved seeming consensus in SG1 (the Concurrency study group) and appeared on-track for C++20 by early 2018—until a fundamental design flaw was exposed.
The Rapperswil Rupture: Lazy Execution and the Facebook Intervention (2018)
At the June 2018 Rapperswil meeting, Eric Niebler and Kirk Shoop (then at Facebook) identified a critical limitation: P0443 provided “poor support for lazy execution, whereby executors participate in the efficient construction and optimal composition of tasks prior to those tasks being enqueued for execution.” Their solution, presented in P1055, introduced “senders” (originally called “deferred”) and “receivers”—abstractions that could be “freely composed into richer senders and receivers, and only when a receiver was ‘submitted’ to a sender would that task be passed to an execution context for actual execution.”
P1055 represented what one paper called “a radical departure from the P0443 design.” LEWG (Library Evolution Working Group), captivated by the promise of conceptual simplification, deferred the decision to merge P0443. This decision effectively killed executors for C++20 and launched a multi-year war between two fundamentally incompatible visions of C++ asynchrony.
In September 2018, an ad hoc Executors meeting in Bellevue, WA polled on direction: “For the long-term direction for executors we like senders/receivers.” This represented a significant faction shift—the new guard (Niebler, Shoop, and Lewis Baker, author of cppcoro and Facebook’s folly::coro) had successfully challenged the Kohlhoff-led old guard. P1194 (”The Compromise Executors Proposal”) by Niebler, Shoop, and Baker attempted to synthesize the approaches, but the “compromise” was really a victory for lazy execution semantics.
Corporate Alignment and libunifex (2019-2021)
Facebook’s investment became concrete with libunifex, a “prototype implementation of the C++ sender/receiver async programming model” authored primarily by Lewis Baker, Kirk Shoop, and Lee Howes. As Eric Niebler later acknowledged: “most of it has been written by my team, not by me: Lewis Baker, Kirk Shoop, and Lee Howes.” This implementation provided the crucial “existing practice” argument that WG21 demands—though critics noted that libunifex was experimental, internal to Facebook, and lacked the decades of production deployment that Boost.Asio could claim.
By 2021, when P2300 (the formal proposal evolving from the sender/receiver work) appeared, its author list read like a who’s-who of corporate concurrency experts: Michał Dominiak (then NVIDIA), Lewis Baker (Facebook), Lee Howes (Facebook), Michael Garland (NVIDIA), Eric Niebler (then Facebook, later NVIDIA), and Bryce Adelstein Lelbach (NVIDIA). The NVIDIA contingent’s involvement reflected P2300’s explicit goal of supporting GPU and heterogeneous parallelism—use cases that Kohlhoff’s networking-centric design had never prioritized.
The Networking TS Civil War (2021)
The conflict became explicit in late 2021 with a series of competing papers. Ville Voutilainen (representing Finland’s national body) authored P2464 (”Ruminations on networking and executors”), delivering a stark verdict: “This paper makes the plain observation that we should not standardize the Networking TS as it’s currently designed. The problem is the use of a P0443 executor.” Voutilainen argued that P0443 executors were “not an executor. It’s a work-submitter. It doesn’t provide any means of finding out whether the work submitted succeeded, or whether an error occurred.”
The Networking TS faction counter-attacked with P2469 (”Response to P2464: The Networking TS is baked, P2300 Sender/Receiver is not”), authored by Jamie Allsop, Vinnie Falco, Richard Hodges, Christopher Kohlhoff, and Klemens Morgenstern. They argued that “the Asio/Net.TS model is a superset of the capabilities of P2300” and that “Evidence suggests that P2300 has not fully explored the design space with respect to the placement of per-operation stable-location memory.”
The October 2021 LEWG polling revealed the depth of division:
Poll 1: “Continue considering shipping P2300 senders/receivers in C++23” — Consensus in favor
Poll 2: “We must have a single async model for the C++ Standard Library” — No consensus
Poll 3: “Stop pursuing the Networking TS/Asio design as the C++ Standard Library’s answer for networking” — No consensus
Poll 4: “Networking in the C++ Standard Library should be based on the sender/receiver model” — Weak consensus in favor
As one observer noted: “Translation of the above polls: ‘Do we want Networking TS in C++? No. Do we want P2300 in C++? Also no.’” The committee had deadlocked.
The GPU Faction’s Victory (2022-2024)
The deadlock eventually resolved in P2300’s favor through a combination of factors. First, the NVIDIA authors demonstrated concrete parallel computing performance: “The NVIDIA coauthors of P2300 report that parallel performance is on par with CUDA code.” A December 2022 HPC Wire article by Niebler, Georgy Evtushenko, and Jeff Larkin showed cross-platform performance “across different parallel programming models, using both distributed-memory and shared-memory, and across different computer architectures.”
Second, LEWG commentary revealed that the Networking TS faction had failed to address use cases beyond their domain. One committee member observed: “On one (I think the first) of three LEWG sessions on the Networking TS and Asio, the Asio proponent began a 90-minute talk on the Asio asynchronous programming model. They used that phrase—’asynchronous programming model’—yet had no examples from parallel computing... Asio supporters have no interest in supporting use cases outside their own.”
Third, the P2300 faction successfully argued that senders/receivers provided superior theoretical foundations. As one poll respondent noted: “The Networking TS model doesn’t facilitate composable error (or payload value) handling. Worse, it’s fundamentally incompatible with such a model.”
In February 2022, despite those favoring C++23 inclusion outnumbering opponents “by more than 2-to-1,” the chairs determined to wait. P2300 was tagged for C++26. Design approval came at subsequent meetings, and in June 2024 at St. Louis, P2300R10 was formally adopted into the C++26 working draft. The paper had reached ten major revisions and exceeded any prior WG21 proposal in page count.
Analysis Through Great Founder Theory
The P2300 saga illustrates several GFT patterns with unusual clarity:
Corporate empire dynamics: The 12-year executor struggle represents competition among corporate “empires” (Facebook/Meta, NVIDIA, and the Boost.Asio ecosystem) for control over C++’s async future. Facebook and NVIDIA ultimately prevailed not through superior argumentation but through superior implementation reality (libunifex, CUDA integration) and expanding coalition (HPC, GPU computing, structured concurrency advocates).
Knowledge succession failure: Chris Kohlhoff’s Boost.Asio represents “living knowledge”—decades of production deployment, iterative refinement, and documented failure modes. Yet WG21’s process could not effectively weigh this experience against theoretical arguments about composability and error propagation. The P2300 faction’s libunifex was experimental and Facebook-internal, lacking comparable deployment history, but its explicit theoretical foundations proved more persuasive in committee debates.
High/Mid power tensions: SG1 (Concurrency study group, Mid power) achieved internal consensus on P0443 by 2018, only to have LEWG (also Mid power) derail the merger by entertaining P1055. The subsequent decade saw neither working group able to impose resolution on the other. Plenary (High power) repeatedly declined to force a choice, allowing the factional war to continue.
Procedural sclerosis: The hundred-plus papers, 10+ revisions of P2300 alone, and 14+ dedicated LEWG meetings represent extraordinary process overhead that produced gridlock rather than refinement. Papers like P1791 (”Evolution of the P0443 Unified Executors Proposal to accommodate new requirements”) explicitly noted the danger that “specific needs will inadvertently be given precedence over the existing and extensive compromises”—yet new requirements continued to accumulate.
Borrowed vs owned power: The Networking TS faction held borrowed power (published TS status, long committee engagement, Kohlhoff’s reputation) but lacked owned power (shipping implementations at Facebook/NVIDIA scale, GPU performance demonstrations). The P2300 faction accumulated owned power through libunifex deployment, CUDA integration, and the explicit backing of major compiler vendors.
The Incomplete Victory
P2300’s adoption leaves significant loose ends. The Networking TS remains in limbo—neither merged nor formally abandoned. The proposal ships without a standard thread pool (users “will need to go to third party libraries for thread-pools, or write their own, in order to write async code that utilizes multiple CPU cores”). There is no standard task coroutine type interoperating with senders until at least C++29. P3109 (”A plan for std::execution for C++26”) acknowledges that “We expect the most common use of senders will actually be from within coroutines. It would be a real disservice for users to have to wait until C++29 before they have an async coroutine task type out of the box.”
Meanwhile, the tag_invoke customization mechanism that P2300 originally used was replaced with member-function-based customization (P2855) after concerns about “compile-time scalability.” Algorithm customization went through multiple revisions (P2999). The ensure_started and start_detached algorithms were removed from the proposal entirely because “all of the options are generally bad options” for handling orphaned async work.
The feature that finally ships in C++26 bears only partial resemblance to any of the proposals from the 2016-2018 period. It represents neither P0443’s original vision nor P1055’s theoretical purity but a heavily-compromised synthesis shaped by a decade of corporate lobbying, factional warfare, and procedural attrition. Whether users will find it usable remains to be seen—the “paltry set” of algorithms “will grow with future standards,” but for now, as Eric Niebler acknowledged, “The P2300 crew have collectively done a terrible job of making this work accessible.”