How does co_await actually work? Not only at the "promise_type customization point" level, but at the level of the state machine the compiler emits on your behalf.
co_await
In this talk, we will take C++20 coroutines apart by manually transforming them into equivalent C++17 state machines, starting with a simple generator and building up to coroutines involving symmetric transfer and exception propagation. Each transformation exposes a subtlety that is easy to overlook when the compiler does the work for us: coroutine frame layout, suspension point indexing, lifetime of locals across suspension points, and the surprisingly tricky semantics of initial_suspend and final_suspend. By the end, you will have a mental model precise enough to reason about compiler codegen, debug coroutine-related issues, and evaluate the design tradeoffs baked into the C++20 coroutine specification.
initial_suspend
final_suspend
Because the transformations only touch the coroutine body (the promise_type, awaitables, and other customization points remain virtually unchanged) the coroutine infrastructure itself becomes a library-level concern, and we can change it. We demonstrate this by swapping the default stackless machinery for a stackful alternative that, for simple generators, matches the performance of handwritten iterators and ranges. Finally, we show that the tedious manual rewriting can be automated with a source-to-source rewriter built on LLVM's LibTooling, making a case for why reimplementing core language features as library code can be practically valuable even when the compiler already provides them.
promise_type
View Slides
I am a researcher and PhD candidate at the University of Freiburg (Germany) where I use modern C++ to build QLever, a highly efficient RDF graph database for knowledge graphs with hundreds of billions of statements. I have recently cofounded QLeverize AG which provides commercial support for QLever. If it was purely up to me, our codebase would already be running C++29 today.