C++20 Coroutines — Why co_yield Crashed After 200 Frames

C++20 is the biggest revision to the language since C++11 rewired how we think about modern C++. It didn't just add syntax sugar — it introduced four pillars that fundamentally change how you architect, template, and scale C++ codebases: Concepts, Ranges, Coroutines, and Modules. These aren't academic curiosities. Google, Microsoft, and JetBrains are already shipping production code that leans on these features, and the compilers — GCC 10+, Clang 10+, MSVC 19.28+ — have solid enough support that there's no excuse for ignoring them in greenfield projects.

Before C++20, template error messages were infamous horror shows — pages of substitution failures that pointed nowhere useful. Constraints on template parameters were enforced via SFINAE tricks that even seasoned engineers would copy-paste without fully understanding. Lazy data pipelines required external libraries like range-v3. Asynchronous code meant either raw threads, callback hell, or heavy framework dependencies. Every one of these pain points has a direct answer in C++20.

By the end of this article you'll understand not just what each feature does, but why it was designed that way, what trade-offs the committee made, where the sharp edges are in real production code, and how to answer the interview questions that trip up candidates who only skimmed the release notes. We'll write real, runnable code for each feature and look hard at the moments where things go wrong.

Why C++20 Coroutines Are Not Just Syntactic Sugar

C++20 coroutines are stackless, resumable functions that suspend execution at a suspension point (co_await, co_yield, co_return) without blocking the thread. Unlike stackful coroutines (e.g., Boost.Coroutine2), each coroutine frame is heap-allocated and contains only the live variables across suspension points — no full stack copy. This makes them lightweight: a suspended coroutine costs roughly 100–200 bytes, not megabytes.

The compiler transforms the function into a state machine. Each suspension point becomes a label; the coroutine frame stores the program counter and spilled registers. Resumption jumps back to the correct label. This zero-overhead abstraction means you pay only for what you suspend — no hidden allocation if you never suspend. But the frame lifetime is decoupled from the caller: if you destroy the coroutine handle without resuming, the frame leaks.

Use coroutines when you need to write asynchronous code that reads like synchronous logic — network I/O, generator pipelines, or cooperative multitasking. They are not a replacement for threads; they are a tool to express non-blocking waits without callback hell. In production, the most common mistake is assuming the coroutine frame lives as long as the function scope — it doesn't. The frame persists until the coroutine completes or the handle is destroyed.

1. Concepts: Contracts for Template Parameters

Concepts allow you to specify constraints on template arguments that are checked at compile time, replacing SFINAE with readable, maintainable predicates. A concept is a compile-time boolean expression evaluated on the type — if it fails, the template is excluded from overload resolution (not an error unless no valid overload exists).

Before C++20, you'd use std::enable_if or tag dispatch to achieve the same. The difference? Concepts produce error messages that actually tell you what's wrong — not a 200-line template instantiation backtrace.

The standard library already provides predefined concepts like std::integral, std::floating_point, std::default_initializable, and std::ranges::range. You compose them with logical operators (&&, ||) and the requires clause.

#include <concepts>
#include <iostream>

template<typename T>
concept Addable = requires(T a, T b) {
    { a + b } -> std::same_as<T>;
};

template<Addable T>
T add(T a, T b) {
    return a + b;
}

int main() {
    std::cout << add(3, 4) << '\n';           // OK: int satisfies Addable
    // std::cout << add(std::string("Hi"), std::string("!")); // Error: std::string does not satisfy Addable
    return 0;
}

2. Ranges: Composable Lazy Data Pipelines

Ranges bring the composability of functional programming to C++ containers and views. A range is anything that can be iterated over — arrays, vectors, strings, or custom types. Views (std::views) are composable adaptors that lazily transform or filter ranges without allocating new containers.

Instead of writing nested loops or manually chaining algorithms, you write a pipeline: vec | views::filter(pred) | views::transform(f) | views::take(n). Each stage is lazy — only the elements actually needed are processed.

The performance win is twofold: no memory allocation for intermediate results, and early termination when using take or drop_while. But beware of dangling references: views store iterators, and if the underlying range dies, the view becomes invalid.

#include <ranges>
#include <vector>
#include <iostream>

int main() {
    std::vector<int> data = {1, 2, 3, 4, 5, 6};
    auto result = data
        | std::views::filter([](int x){ return x % 2 == 0; })   // lazy: none executed yet
        | std::views::transform([](int x){ return x * x; })
        | std::views::take(3);                                  // only first 3

    for (int v : result) {
        std::cout << v << ' ';
    }
    // Output: 4 16 36
    return 0;
}

3. Coroutines: Cooperative Multitasking Without Threads

Coroutines are functions that can suspend execution and resume later, preserving local state across suspension points. Unlike threads, coroutines don't require OS scheduling — the decision to suspend and resume is cooperative.

C++20 provides three keywords: co_await (suspend and wait for an awaitable), co_yield (produce a value and suspend), and co_return (final return from a coroutine). The compiler transforms the function into a state machine, allocating a coroutine frame on the heap (by default) to hold suspended state.

Coroutines shine in scenarios like streaming data, asynchronous I/O, and generators. But they have subtle pitfalls: heap allocation overhead, potential stack overflow if deeply nested, and difficult debugging because the stack is reconstructed at suspension points.

#include <coroutine>
#include <iostream>

template<typename T>
struct Generator {
    struct promise_type {
        T current_value;
        std::suspend_always yield_value(T value) {
            current_value = value;
            return {};
        }
        std::suspend_always initial_suspend() { return {}; }
        std::suspend_always final_suspend() noexcept { return {}; }
        Generator get_return_object() { return Generator{this}; }
        void return_void() {}
        void unhandled_exception() { std::terminate(); }
    };
    // ... handle management omitted for brevity
};

Generator<int> range(int start, int end) {
    for (int i = start; i < end; ++i)
        co_yield i;
}

int main() {
    for (auto v : range(1, 5)) {
        std::cout << v << ' ';
    }
    return 0;
}

4. Modules: Modern Compilation Boundaries

Modules (export, import) provide a new way to organise C++ code that is faster to compile and more hygienic than headers. A module interface unit (.cppm) declares what is exported, and module implementation units (.cpp) define non-exported details. Importing a module gives access only to the exported names, eliminating macro leaks, ODR violations, and include-order dependencies.

Modules also improve build times because the compiler pre-compiles module interfaces into .pcm files (Clang) or .ifc files (MSVC). Translation units that import the module only need to load that precompiled interface — no reparsing of headers.

However, module support is not fully consistent across compilers. You may encounter issues with .cppm vs .ixx extensions, and interaction with precompiled headers (PCH) can be fragile.

export module math;
export int add(int a, int b) {
    return a + b;
}
export int multiply(int a, int b) {
    return a * b;
}

// Non-exported: not visible to importers
int helper(int x) {
    return x * 2;
}

5. Three-Way Comparison Operator (Spaceship)

The <=> operator (also called the spaceship operator) performs a three-way comparison, returning a comparison category type that indicates less, equal, or greater. The compiler can automatically generate ==, !=, <, <=, >, >= from <=> if you write = default. This eliminates the boilerplate of writing six comparison operators for a class.

There are three category types: std::strong_ordering (total order: no two values are incomparable), std::weak_ordering (equivalence classes, e.g., case-insensitive strings), and std::partial_ordering (values may be incomparable, e.g., floating-point NaN).

The operator is a two-way operator with reversed candidate generation, which can lead to ambiguities when both <=> and == are custom defined.

#include <compare>
#include <iostream>

struct Point {
    int x, y;
    auto operator<=>(const Point&) const = default; // generates all six
};

int main() {
    Point p1{1, 2}, p2{1, 3};
    std::cout << std::boolalpha;
    std::cout << (p1 < p2) << '\n';  // true, because x==1, y:2<3
    std::cout << (p1 == p2) << '\n'; // false
    std::cout << (p1 <=> p2 < 0) << '\n'; // true (p1 less)
}

6. std::to_array: Stop Using Raw Arrays in Templates

We had a bug last month. A junior wrote a template function expecting an array of integers, passed a braced-init-list, and got template deduction failure. The compiler couldn't figure out what type {1,2,3} was. Enter std::to_array. It's a factory function that deduces both size and element type from an initializer list at compile time. No more std::array size template arguments that mismatch. No more silent decays to pointers. The WHY: braced-init-lists have no type in template context. std::to_array converts them to a proper std::array with a concrete type. Use it for any compile-time sized container you pass into template code. It's in <array> and costs nothing at runtime. The compiler will reject mismatched sizes before your CI pipeline runs.

// io.thecodeforge
#include <array>
#include <iostream>

template <typename T, size_t N>
void process_array(const std::array<T, N>& arr) {
    for (const auto& val : arr) {
        std::cout << val << ' ';
    }
    std::cout << '\n';
}

int main() {
    // Before C++20: template deduction fails
    // process_array({1, 2, 3}); // ERROR

    // C++20: explicit conversion works
    process_array(std::to_array<int>({1, 2, 3}));

    // Even better: type deduced automatically
    auto arr = std::to_array({4.2, 5.7, 9.1});
    process_array(arr);

    return 0;
}

7. [[likely]] and [[unlikely]]: Assert Your Branch Expectations to the Optimizer

Your hot path was slow. We profiled. The branch predictor was thrashing on a 50/50 split that should have been 95/5. The compiler didn't know. [[likely]] and [[unlikely]] are attributes that annotate which branch the CPU should predict. No functional change. Pure performance hint. WHY: branch misprediction stalls cost 10-20 cycles per miss. In tight loops, that adds up. Place [[likely]] on the path that runs 95% of the time—error checks, fast-return paths, early exits. Place [[unlikely]] on error handling. The compiler will reorder blocks to minimize taken branches. It works in if/else, switch cases, and loop conditions. One caveat: don't lie. If you mark a branch [[likely]] that actually runs 50%, performance degrades. Profile first, annotate second.

// io.thecodeforge
#include <iostream>
#include <random>
#include <chrono>

int parse_input(int value) {
    // Expected: most values are > 0
    if (value > 0) [[likely]] {
        return value * 2;
    } else [[unlikely]] {
        // Error path: log and return -1
        std::cerr << "Invalid input: " << value << "\n";
        return -1;
    }
}

int main() {
    std::mt19937 gen(42);
    std::uniform_int_distribution<int> dist(-10, 100);
    
    long long sum = 0;
    auto start = std::chrono::high_resolution_clock::now();
    
    for (int i = 0; i < 10'000'000; ++i) {
        sum += parse_input(dist(gen));
    }
    
    auto end = std::chrono::high_resolution_clock::now();
    std::cout << "Sum: " << sum << "\n";
    std::cout << "Time: " 
              << std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count()
              << "ms\n";
    
    return 0;
}

8. Map and Set .contains(): Kill the .count() Hack for Good

I've seen codebases with if (my_map.count(key) > 0) scattered everywhere. That works, but it's wasteful. std::map::count has to traverse the tree to count all matches—which returns 0 or 1 for unique keys. Inefficient and confusing. C++20 gives us .contains(key) which returns bool directly. It communicates intent: "does this key exist?" not "how many times does this key appear?". The WHY: readability and performance. contains() can short-circuit after finding the first match. For unordered containers, it's a single hash lookup. For ordered maps, it's one tree traversal, not a full count. Replace all your .count() > 0 checks. It's a safe mechanical transformation. Your code will be clearer. Your code reviewers will thank you. Your profiler will show lower CPU usage.

// io.thecodeforge
#include <iostream>
#include <map>
#include <unordered_set>

int main() {
    std::map<int, std::string> users = {
        {1, "Alice"},
        {2, "Bob"},
        {3, "Charlie"}
    };
    
    std::unordered_set<int> active_sessions = {2, 5, 7};
    
    // C++17: ugly count() hack
    if (users.count(2) > 0) {
        std::cout << "User 2 exists in map\n";
    }
    
    // C++20: clean contains()
    if (users.contains(2)) {
        std::cout << "User 2 exists (C++20 way)\n";
    }
    
    // Works on unordered containers too
    if (active_sessions.contains(5)) {
        std::cout << "Session 5 is active\n";
    }
    
    // Combine with conditional insertion
    if (!active_sessions.contains(10)) {
        active_sessions.insert(10);
        std::cout << "Session 10 added\n";
    }
    
    return 0;
}