Modules and Coroutines

Modules

export module math;

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

import math;

• Use modules to reduce header duplication and improve build boundaries.
• Treat toolchain support as the deciding factor for adoption speed.

Typical module split

export module math;

export int add(int a, int b);

module math;

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

Keep the interface unit small and stable. Move implementation details out of the exported surface when possible.

Practical module advice

• Start with a new or isolated library, not the entire codebase.
• Expect compiler and build-system setup to dominate the first adoption pass.
• Keep a fallback plan if your CI or dependency graph still assumes header-based builds.

Minimal build shape

add_library(math)
target_sources(math
    PUBLIC
        FILE_SET CXX_MODULES FILES math.cppm
    PRIVATE
        math.cpp
)

The key reminder is that module adoption is a build-model change, not just a syntax change.

Coroutines

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

• co_return finishes with a value.
• co_yield produces a sequence element.
• co_await suspends until another awaitable is ready.

Minimal async shape

task<int> compute() {
    int base = co_await read_value_async();
    co_return base * 2;
}

Even this tiny example shows the real coroutine value: the code reads top-to-bottom while still modeling suspension.

Coroutine mental model

• The compiler rewrites the function into a state machine.
• The promise type controls how results, suspension, and errors are handled.
• The return type is not just decoration; it is part of the coroutine protocol.

Adoption guidance

• Add modules first in leaf libraries or new components.
• Add coroutines through a real abstraction such as a task type or generator library, not as raw promise-type experiments in production code.

Quick adoption checklist

• verify compiler, standard library, and build-system support first
• choose one bounded module or coroutine use case instead of a wide rewrite
• keep the first use case easy to test in isolation
• decide upfront where errors, cancellation, and shutdown semantics live

When modules help most

• Large header-heavy libraries with long rebuild times.
• APIs that benefit from clearer exported boundaries.
• New code where you can control the build graph from the start.

When coroutines help most

• Async I/O code that otherwise becomes callback-heavy.
• Streaming or generator-style traversal.
• Task orchestration where suspension is the real control-flow model.

Reality check

• Modules are a build-system and toolchain feature as much as a language feature.
• Coroutines are usually not useful by themselves; they become useful with a task, generator, or async I/O abstraction.

Quick decision rule

• If the pain is compile times and header boundaries, look at modules.
• If the pain is async control flow and callback nesting, look at coroutines.
• If neither pain is real in your codebase yet, do not force adoption just because the features are new.

One-line patterns to remember

• modules: export a narrow interface, hide implementation details, and let the build model the boundary
• coroutines: suspend and resume through a real task or generator abstraction, not ad hoc low-level machinery