Delegates and Closures

Analogy categoryAnalogies

Introduction to Delegates and Closures in D

A delegate in D is a bound pair of a function pointer and a context pointer (either an object instance or a closure environment), which is what allows a delegate -- unlike a bare function pointer -- to refer to a class or struct's instance method, or to a nested function that accesses variables from its enclosing scope. Closures in D are created automatically when a nested function or lambda references variables from its enclosing function; the compiler allocates the referenced variables on the heap (or keeps them alive via the closure context) so they remain valid even after the enclosing function returns, which is essential for patterns like event callbacks and lazily-evaluated iterators.

🏏

Cricket analogy: A team's designated vice-captain who can step in and make on-field calls using the captain's full authority and knowledge of the game plan is like a delegate -- a function bundled with the exact context it needs to act.

Function Pointers vs Delegates

A function pointer in D, declared with the type int function(int), points only to a free function or a static method -- it carries no context, so it cannot reference outer-scope variables or be bound to a class instance. A delegate, declared with the type int delegate(int), additionally carries a context pointer, so it can be bound to an instance method (where the context is the this reference) or to a nested function that closes over local variables. D will not implicitly convert a delegate to a function pointer or vice versa because they have different sizes in memory: a function pointer is one machine word, while a delegate is two (the function pointer plus the context pointer).

🏏

Cricket analogy: A generic bowling action drilled in isolation at the nets, with no specific batsman or match situation in mind, is like a bare function pointer -- pure logic with no bound context -- whereas a bowler's specific plan against a named batsman in a live match is like a delegate carrying that context.

import std.stdio;

int square(int x) { return x * x; }

struct Multiplier
{
    int factor;
    int apply(int x) { return x * factor; } // instance method
}

void main()
{
    int function(int) fp = &square;   // function pointer: no context
    writeln(fp(4)); // 16

    auto m = Multiplier(3);
    int delegate(int) dg = &m.apply;  // delegate: bound to m's context
    writeln(dg(4)); // 12

    // fp = dg;  // compile error: function pointer and delegate are not interchangeable
}

Closures: Capturing Context

When a nested function or lambda references a variable declared in its enclosing function, D automatically turns that reference into a closure: the compiler detects the escaping reference and allocates the captured variables on the garbage-collected heap rather than the stack, so the values remain valid even after the outer function returns and its stack frame would otherwise be gone. This is what lets a function like counter() return a delegate that increments and remembers its own private counter variable across calls, with each call to counter() producing an independent closure with its own separate captured state.

🏏

Cricket analogy: A player's personal training journal that keeps accumulating notes across every net session, even after each individual session ends, is like a closure preserving captured state across calls, with each player's journal being an entirely independent instance.

Because D captures closure variables by reference into heap-allocated storage, a common pitfall is capturing a loop variable and expecting each generated delegate to see a distinct value -- in D, foreach loop variables are typically scoped fresh per iteration (unlike old C-style for loops reusing one variable), but capturing a manually declared outer variable across multiple nested-function creations will make all those delegates share and see the same final mutated value, not independent snapshots.

Delegates as Callbacks and Higher-Order Functions

Delegates are D's standard mechanism for callbacks: functions like std.algorithm.sorting's sort, std.algorithm.iteration's map and filter, and event-handling APIs all accept a delegate (or a function, or a lambda that's implicitly convertible to either) as a parameter, letting you pass custom comparison, transformation, or predicate logic without writing a named function for every use site. Because delegates can be instance methods, they're also how D implements much of its object-oriented event and observer patterns -- a UI button's onClick can be assigned a delegate bound to a specific handler object, invoking that object's method with full access to its state when the event fires.

🏏

Cricket analogy: A third umpire who is handed a specific review protocol (a delegate) to apply consistently every time a decision is referred upstairs mirrors passing a callback delegate to a sorting or filtering function.

import std.stdio;
import std.algorithm : sort, filter, map;
import std.array : array;

void main()
{
    int[] nums = [5, 3, 8, 1, 9, 2];

    // lambda implicitly used as a comparison delegate
    auto sorted = nums.dup.sort!((a, b) => a > b).array;
    writeln(sorted); // descending order

    auto evens = nums.filter!(x => x % 2 == 0).array;
    writeln(evens);

    auto doubled = nums.map!(x => x * 2).array;
    writeln(doubled);

    // a delegate bound to a callback registry
    void delegate(string) onEvent;
    onEvent = (string msg) { writeln("Event fired: ", msg); };
    onEvent("build_complete");
}

Lambda Syntax and toDelegate

D offers several equivalent lambda syntaxes: the concise x => x * 2 expression form, and the fuller (int x) { return x * 2; } function-literal form, both of which can implicitly become either a function pointer or a delegate depending on whether they capture any enclosing context. If a lambda captures nothing from its surroundings, it can be treated as a plain function pointer; the moment it references an outer variable, it must become a delegate. std.functional's toDelegate utility converts a context-free function pointer into a delegate (with a null context), which is useful when an API strictly requires a delegate type but you only have a plain function to offer.

🏏

Cricket analogy: A pre-recorded generic pitch report that applies to any ground, with no specific stadium referenced, is like a context-free lambda usable as a function pointer, whereas a live pitch report referencing today's specific stadium conditions is like a delegate; toDelegate is like formally filing the generic report under today's match record.

Because a bare lambda's inferred type (function pointer versus delegate) depends on whether it captures context, passing the exact same-looking lambda syntax to two different APIs can silently produce two different underlying types -- always check whether an API's parameter is declared as int function(int) or int delegate(int) when a lambda you expect to work fails to compile, and reach for std.functional.toDelegate to bridge a context-free lambda into a delegate-only API.

A delegate bundles a function pointer with a context pointer (an object instance or closure environment); a bare function pointer carries no context.
Function pointers and delegates are not implicitly interchangeable in D because they differ in memory layout (one word versus two).
Closures form automatically when a nested function or lambda references outer-scope variables, which D then heap-allocates to outlive the enclosing function.
Each closure creation captures its own independent copy of the enclosing state, enabling patterns like private per-instance counters.
Delegates are D's standard callback mechanism, used throughout std.algorithm (sort, map, filter) and event/observer patterns.
Lambdas can implicitly become a function pointer (if context-free) or a delegate (if capturing); std.functional.toDelegate bridges the two.
Watch for shared-state bugs when multiple closures capture and mutate the same outer variable rather than independent copies.