What are Senders Good For? Understanding C++'s P2300 Async Revolution

In the evolving landscape of C++ asynchronous programming, a significant development has been taking shape: the P2300 proposal, which introduces senders as a standard async programming model. Approved for C++26, this effort represents a fundamental shift in how C++ handles asynchrony, yet it faces understandable skepticism from developers accustomed to existing approaches.

The core problem P2300 addresses is one of fragmentation in async programming. As Niebler illustrates through the classic Win32 callback API example, traditional async programming often relies on callback mechanisms that, while functional, create significant interoperability challenges. The callback pattern, exemplified by APIs like ReadFileEx, requires manual management of operation state through overlapped structures and custom callbacks—a pattern developers have used for decades but which suffers from critical limitations in composability.

{{IMAGE:3}}

The fundamental issue emerges when attempting to chain operations from different libraries. Each async library tends to implement its own abstraction, creating what Niebler aptly calls the "Tower of Babel" problem. This fragmentation forces developers to write extensive glue code to bridge different async models, increasing complexity and reducing reusability. As the xkcd comic on standards proliferation illustrates, this problem tends to grow organically as more libraries emerge with their own approaches.

Senders offer a solution by providing a standardized, composable abstraction for asynchronous operations. Rather than a single callback as in traditional approaches, senders employ three distinct completion mechanisms: success (set_value), failure (set_error), and cancellation (set_stopped). This tripartite design captures the full spectrum of async operation outcomes in a structured way.

The implementation of a sender-based async_read_file reveals several key advantages. First, the sender itself serves merely as a descriptor of the asynchronous operation, with actual work deferred until explicitly started. This separation allows for sophisticated composition patterns where multiple async operations can be organized into complex dependency graphs before any work begins.

The operation state, analogous to the overlapped structure in callback APIs, but more sophisticated, contains all necessary data for the async operation's lifetime. Crucially, the lifetime management becomes more explicit and safer through this model. The connect function links a sender with a receiver (which contains the three completion callbacks), producing an operation state that can then be started.

What makes senders particularly compelling is their integration with C++ coroutines. As demonstrated in the article, a sender can be seamlessly used with co_await, providing the developer experience of traditional coroutines while leveraging the underlying sender model. This dual compatibility—usable both with coroutines and through direct algorithm composition—makes senders exceptionally versatile.

The stdexec library example illustrates how senders enable generic programming patterns. By implementing a standard async model, libraries can create operations that work seamlessly with generic algorithms like then(), when_all(), and sync_wait(). This composability represents a significant leap forward in async programming, allowing developers to build complex pipelines from components that might originate from different libraries.

Addressing common criticisms, Niebler acknowledges that implementing senders is more complex than simple callback APIs, but argues that consuming them is remarkably straightforward. The end developer experience is simplified through intuitive syntax like co_await, while the underlying complexity remains abstracted away. Furthermore, the sender model offers performance advantages, particularly for embedded developers, by avoiding coroutine frame allocations when operations are composed directly without coroutines.

The true value of P2300 lies in its potential to unify C++ async programming. By establishing a standard abstraction, the proposal enables an ecosystem where async libraries can interoperate seamlessly. This standardization doesn't eliminate existing approaches but provides a common ground that reduces boilerplate and increases reusability.

As C++ continues to evolve with increasingly sophisticated concurrency and parallelism features, senders represent a crucial piece of infrastructure. They provide the foundation for building complex async systems that remain composable, performant, and maintainable—addressing fundamental challenges that have long plagued asynchronous programming in C++.

For developers and library authors, the message is clear: while the transition to senders requires understanding a new model, the long-term benefits of interoperability, composability, and ecosystem growth make this evolution not just beneficial but necessary for the future of C++ async programming.