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.

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)
}