CppCon 2026

C++20 coroutines come with a reputation for complexity — and writing your own coroutine return type deserves that reputation. But here is the good news: you probably don't have to. With std::generator in C++23, high-quality libraries like Asio and cppcoro today, and std::task on its way in C++26, most developers can simply write co_await and move on.

There is one gap, however. Sooner or later, every developer using coroutines needs to bridge an existing asynchronous interface — a timer, an I/O operation, a thread pool callback, a legacy future — into the coroutine world. That bridge is built with awaiters and awaitables, and that is exactly what this session teaches.

We will start from first principles: what does co await actually do? We will demystify the three functions that form the awaiter protocol — await ready, await suspend, and await resume — and build a clear mental model for each. We will implement a real awaiter from scratch, then explore how symmetric control transfer keeps the call stack flat across deeply chained async operations. Next, we will learn how to make any existing type co await-able without modifying it, using operator co await, and how await transform lets you restrict or adapt awaitable behavior to a specific coroutine context. Finally, we will look at how to write cancellation-aware awaiters using std::stop token, so your coroutines respond promptly when work is no longer needed.

No prior coroutines experience is assumed. If you know what co await looks like on the surface but not what happens underneath it, this session is for you. You will leave with both the knowledge and the code to wrap any asynchronous operation into a first-class co await expression.

Range views enable a “no raw loops” style of programming — not as a matter of taste, but as a pragmatic way to reuse well-tested algorithms to write code faster, express intent clearly, and avoid common bugs. In practice, however, developers often run into issues that may lead them to abandon ranges altogether:

• unintuitive behavior and surprising limitations
• slower compilation and runtime performance compared to raw loops
• high complexity when implementing custom views

In this talk, we’ll distill the core design choices behind these problems — and the alternatives that avoid them. In particular, we’ll compare:

• iterators and indices
• external and internal iteration
• transformations of nested views that overcome limitations of internal iteration

Attendees will leave with practical insights for designing and using range abstractions, along with examples of libraries that embody these ideas.

What makes an async workflow readable? Not just linear control flow — you also need to see where errors go, what each step depends on, and how failures compose. This talk takes a single production workflow — multiple async RPC calls with conditional branching, parallel fan-out, and partial-failure handling — and shows it implemented in three paradigms: callbacks with thread pools, a workflow orchestration graph over futures, and coroutines with std::expected. We evaluate each through four questions: where does the control flow live, the error flow, the coupling, and the migration risk?

Coroutines restore linear control flow, but without structured error composition, the workflow drowns in manual failure checks at every step, that is more error-handling code than business logic. Task

Sean Parent's "no raw pointers" guideline is often misunderstood as "avoid T* , use smart pointers instead", even though Sean explicitly included smart pointers in his definition of a raw pointer: "anything with implied ownership and reference semantics".

This talk presents a refinement of that guideline:

Pointers - smart or not - shall not appear in function signatures, neither as argument nor as return type.

The focus of this talk is how to implement classes as regular types while still supporting dynamic allocation, polymorphism, and sharing internally.

It shows how such value types can be implemented manually, without dedicated library support. It then follows the evolution of the language and library in gradually simplifying these abstractions: C++11 smart pointers ( unique_ptr and shared_ptr ), C++26 vocabulary types ( indirect and polymorphic ), as well as in-progress proposals ( copy_on_write and protocol ) are presented as tools to simplify writing safe abstractions, not as safe abstractions themselves.

Along the way, the talk revisits the Rules of 3/5/0, exception safety guidelines, const propagation, aliasing, and local reasoning.

The talk aims to make you stop passing pointers around.