What are Senders Good For, Anyway? C++ Bets on a Standard Async Model

The announcement

The C++ committee has design-approved P2300, a proposal to standardize an async abstraction known as "senders" for C++26 — and Eric Niebler has been on a one-man hype train explaining why. In a recent blog post he walks through turning a classic C-style callback API (think Win32 ReadFileEx and its overlapped+callback pattern) into a sender-based workflow, showing how old, crusty code can be wrapped to interoperate with the new model. Short version: it’s not magic. It’s glue, made consistent.

Why it matters

The practical pitch is simple: too many incompatible async APIs means mountains of boilerplate when you try to compose operations across libraries. Sound familiar? The Tower of Babel problem all over again. Niebler argues that a single, standard async abstraction lets libraries map their own beasts onto the same foundation, so chaining and composing async work becomes straightforward instead of a hairball. He admits the committee’s messaging hasn’t been great; it has been reported that many developers still find the proposal complicated. But the core idea is tidy, even elegant — convert the callback, keep the semantics, get composability.

The debate

Of course, not everyone is sold. Why senders when C++ already has coroutines? How much complexity will the ecosystem tolerate? Niebler says senders complement coroutines by providing a composable execution model that coroutines alone don’t standardize; skeptics point to learning cost and adoption friction. The real test won’t be committee approval but whether library authors and toolchains embrace the pattern. Will the C++ world trade yet another way to do async for one that actually lets everyone talk to each other? Time will tell — but for now, the proposal has a champion and a clear use-case: make the old stuff play nicely with the new.

Sources: ericniebler.com, Lobsters