Functions in D

Analogy categoryAnalogies

Introduction to Functions in D

Functions are the basic unit of reusable logic in D. A function declaration specifies a return type, a name, and a parameter list, and D infers the return type automatically if you use the auto keyword in place of an explicit type, letting the compiler deduce it from the return statements in the body. D functions can be nested inside other functions, declared at module scope, or declared as methods inside structs and classes, and D supports both eager (attribute-checked) and template-based generic functions within the same syntax.

🏏

Cricket analogy: A specialist death-over bowler is a dedicated, reusable piece of a team's strategy called upon whenever the situation demands it, just as a function packages reusable logic invoked wherever a program needs that specific behavior.

Function Declaration, Parameters, and Return Types

A D function's return type appears before its name: int add(int a, int b) { return a + b; }. Parameters are passed by value by default (structs and arrays are value types that get copied, except that dynamic arrays and associative arrays share their underlying data by reference even when the array header itself is copied). D also supports variadic functions using the ... syntax or, more idiomatically, typed variadics with T[] args..., and the auto return type lets the compiler infer the return type from the body, which is convenient for template functions whose return type depends on the parameter type.

🏏

Cricket analogy: A fielding position assignment sheet specifies exactly which player (parameter) fields at which position and what the expected outcome (return value) of a good catch is, just as a function signature specifies parameter types and a return type.

import std.stdio;

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

auto multiply(T)(T a, T b)  // template function, auto return type inferred
{
    return a * b;
}

int sum(int[] nums...)  // typed variadic parameter
{
    int total = 0;
    foreach (n; nums)
        total += n;
    return total;
}

void main()
{
    writeln(add(2, 3));           // 5
    writeln(multiply(2.5, 4.0));  // 10.0, T inferred as double
    writeln(sum(1, 2, 3, 4, 5));  // 15
}

Default Arguments and Function Overloading

D functions may specify default argument values for trailing parameters, so callers can omit them entirely: void connect(string host, int port = 8080). D also supports function overloading -- multiple functions with the same name but different parameter types or counts -- and the compiler picks the best match at compile time using its overload resolution rules, preferring exact matches, then implicit conversions, then template instantiation as a last resort. Overload resolution errors (ambiguous matches) are caught at compile time, not at runtime, which avoids an entire category of dispatch bugs found in more dynamically typed languages.

🏏

Cricket analogy: A team sheet that lists a wicketkeeper's default batting position but allows the captain to override it for a specific match is like a default parameter value that can be overridden by the caller.

Parameter Storage Classes: in, out, ref, and lazy

D parameters are in (the default: passed by value, effectively read-only within common usage though not strictly enforced like const), ref (passed by reference, so mutations inside the function are visible to the caller), out (also passed by reference, but the parameter is default-initialized on entry regardless of what the caller passed, useful for functions that produce a result through a parameter), and lazy (the argument expression is not evaluated until it's actually used inside the function body, effectively passing a delegate that computes the value on demand). ref parameters must be called with an lvalue -- you cannot pass a literal or temporary directly to a ref parameter without an explicit cast.

🏏

Cricket analogy: Handing a scorer the actual physical scorebook to update live during the match (not a photocopy) is like passing a ref parameter -- changes made are visible to everyone using that same book afterward.

import std.stdio;

void increment(ref int x)
{
    x++;
}

void divide(int a, int b, out int quotient, out int remainder)
{
    quotient = a / b;
    remainder = a % b;
}

void logIfDebug(bool debugMode, lazy string message)
{
    if (debugMode)
        writeln(message);  // message() is only evaluated here, if at all
}

void main()
{
    int value = 10;
    increment(value);
    writeln(value); // 11

    int q, r;
    divide(17, 5, q, r);
    writefln("q=%d r=%d", q, r);

    logIfDebug(false, "This expensive string is never built");
}

out parameters are re-initialized to their type's default value (.init) the moment the function is entered, discarding whatever value the caller's variable held before the call -- this is different from ref, which preserves the caller's existing value on entry. Passing a variable you expect to read from as out, instead of ref, is a common source of surprising bugs.

Design by Contract: in and out Blocks

D has built-in support for Design by Contract through in and out contract blocks attached to a function, plus invariants for classes and structs. An in block runs before the function body and asserts preconditions on the parameters; an out block runs after the body and can assert postconditions about the return value (bound to a name you choose, e.g. out(result)). These contracts are checked automatically in debug and unittest builds but compiled out entirely in release builds (built with -release), so they carry zero runtime cost in production while catching contract violations during development and testing.

🏏

Cricket analogy: A pre-match pitch inspection that must confirm the pitch is fit for play before the toss (a precondition) and a post-match pitch report confirming no dangerous cracks appeared during play (a postcondition) mirrors D's in and out contract blocks.

Contracts compose with inheritance: a derived class's overriding method's in contract is OR-ed with the base class's (any one passing is sufficient, allowing subclasses to weaken preconditions), while out contracts are AND-ed (all must pass, so subclasses can only strengthen postconditions) -- this follows the Liskov substitution principle automatically at the language level.

A function's signature is returnType name(parameters); use auto to let the compiler infer the return type.
Parameters are in (by value) by default; ref and out pass by reference, with out resetting to .init on entry.
lazy parameters defer evaluation of the argument expression until it's actually used inside the function body.
Default argument values let callers omit trailing parameters; overloading lets multiple functions share a name with distinct signatures.
Overload resolution happens at compile time, so ambiguous or unmatched calls are caught before the program runs.
in and out contract blocks implement Design by Contract, checked in debug/unittest builds and stripped in -release builds.
Contract inheritance rules (OR for in, AND for out) automatically enforce Liskov substitution for overridden methods.