Modules and Coroutines

Modules

Headers work, but they come with repeated parsing, macro leakage, and fragile include boundaries. Modules aim to improve that.

export module math;

export int add(int a, int b) {
    return a + b;
}

Consumers import the module instead of including a header:

import math;

What changes in practice

• Macros do not leak across module boundaries the way headers can.
• Imports communicate dependency direction more cleanly than long include chains.
• Build-system support matters more than syntax here.

When modules help

• large codebases with expensive header graphs
• libraries that want clearer interfaces
• new components where build-system support is already available

When to be careful

• mixed toolchains
• older CI environments
• third-party dependencies that still assume header-only integration

Coroutines

Coroutines let a function suspend and resume, which is useful for async workflows and generators.

task<int> compute_answer() {
    co_return 42;
}

The language feature alone is low-level. In practice you use coroutines through an abstraction provided by a framework or library.

Generator-style coroutines

generator<int> countdown(int from) {
    while (from > 0) {
        co_yield from--;
    }
}

This is often the easiest coroutine shape to understand because each suspension point yields a sequence element.

The three keywords

• co_await: suspend until another awaitable completes
• co_yield: produce the next value in a sequence
• co_return: finish with a result

Adoption advice

Adopt modules when your compiler and build system support them well. Adopt coroutines when you already have a real async or generator abstraction to build on. Both are powerful, but neither is a "turn it on everywhere" feature.

Exercises

• Move a tiny helper library interface into a module sketch.
• Identify a generator-style loop in existing code and rewrite it as a coroutine pseudocode example.
• List the toolchain requirements you would need before adopting modules in a real project.