Mixins and Metaprogramming

Analogy categoryAnalogies

String Mixins vs Template Mixins

D offers two distinct mixin mechanisms that are often confused: a string mixin (mixin(someCompileTimeString)) splices arbitrary D source code — generated as a string, often via CTFE — directly into the surrounding scope at compile time, while a template mixin (mixin SomeTemplate!(args);) instantiates a reusable, pre-written block of declarations (fields, methods, even whole class bodies) into the current scope, similar to a hygienic macro. Both happen entirely at compile time and produce ordinary compiled D code with no runtime interpretation overhead, but string mixins are typically used to generate code whose exact shape depends on compile-time data (like a list of column names), while template mixins are used to factor out repeated boilerplate (like implementing a common interface) across many unrelated types.

🏏

Cricket analogy: It's like the difference between a scorer writing a custom, one-off scoring rule into the scorebook by hand for an unusual county match format (string mixin) versus reusing a standard ICC playing-conditions template that's dropped wholesale into every T20 international's rulebook (template mixin).

Generating Code with String Mixins

A string mixin takes any expression that evaluates to a string at compile time (frequently built with CTFE helper functions) and splices it in as literal D source code, which is powerful for generating repetitive boilerplate from data — for example, iterating over a compile-time list of field names and generating a getter/setter pair for each one, or building a switch statement with one case per enum member without writing it by hand. Because the mixed-in text is parsed as real D code at the exact point of the mixin, it has full access to the surrounding scope (so a generated function body can reference private members), but this also means a typo in the generated string produces a compiler error pointing at an unhelpful, synthetic line inside the generated text rather than at your original source.

🏏

Cricket analogy: It's like a scorer's assistant who auto-generates a full over-by-over commentary script from the raw ball-by-ball data feed rather than typing each line by hand, though a garbled data field can produce a nonsensical commentary line that's hard to trace back to its source.

string makeGetter(string type, string name)
{
    return type ~ " get" ~ capitalize(name) ~ "() { return " ~ name ~ "; }";
}

struct Point
{
    private int x, y;
    mixin(makeGetter("int", "x"));
    mixin(makeGetter("int", "y"));
}

void main()
{
    auto p = Point(3, 4);
    assert(p.getX() == 3 && p.getY() == 4);
}

Because string mixins are parsed as raw text, IDE tooling and error messages often can't point precisely at the logical source of a bug — always build the mixin string with a well-tested CTFE helper function (and print it with pragma(msg, ...) during development) rather than concatenating ad-hoc strings inline, or debugging becomes painful.

Reusable Behavior with Template Mixins and static if

A mixin template is declared with mixin template Name(Args) { ... } and instantiated with mixin Name!(args); inside a struct, class, or function, injecting its declarations as if they were typed directly at that location — this is how D implements mixin-based composition, letting a single reusable block (say, a Comparable mixin that generates opEquals and opCmp from a compile-time list of field names) be dropped into many unrelated types. Inside such templates, static if(condition) { ... } performs compile-time conditional compilation (skipping or including declarations based on a compile-time boolean, often derived from __traits(hasMember, ...) or __traits(compiles, ...)), and static foreach iterates over a compile-time sequence to generate one declaration per item, together forming D's primary toolkit for structural, reflection-driven metaprogramming without a separate macro language.

🏏

Cricket analogy: It's like a standard fielding-drill module a coach drops into every age-group team's training plan unchanged, while a smart drill sheet still adapts itself — including extra slip-catching reps only for teams that actually have a wicketkeeper trainee listed on the roster.

mixin template Loggable()
{
    void log(string msg)
    {
        import std.stdio : writefln;
        writefln("[%s] %s", typeof(this).stringof, msg);
    }
}

struct OrderService
{
    mixin Loggable!();
}

struct PaymentService
{
    mixin Loggable!();
}

void main()
{
    OrderService().log("order placed");   // [OrderService] order placed
    PaymentService().log("charge run");   // [PaymentService] charge run
}

__traits(compiles, expr) and __traits(hasMember, T, "name") are the workhorses of D's compile-time reflection — combined with static if inside a mixin template, they let you write generic code that adapts its generated members based on what a type actually provides, similar in spirit to C++20 concepts but resolved through simple boolean compile-time expressions.

String mixins (mixin(str)) splice compile-time-computed source text into the surrounding scope, ideal for data-driven code generation.
Template mixins (mixin Name!(args);) inject a reusable, pre-written block of declarations into a type, ideal for factoring out repeated boilerplate.
Both mixin kinds resolve entirely at compile time and produce ordinary compiled code with zero runtime interpretation cost.
Errors inside string-mixin-generated code point at the generated text, not your original source, so building strings with tested CTFE helpers matters.
static if enables compile-time conditional inclusion of declarations, often driven by __traits(hasMember, ...) or __traits(compiles, ...).
static foreach generates one declaration per item in a compile-time sequence, avoiding hand-written repetition.
pragma(msg, ...) is a useful debugging tool to print a generated mixin string during compilation.