templates_examples.tex

\newpage
\part{Examples}\label{examples}

This part will present various examples showing what can be done with D templates, be it type manipulation, code generation or language extension \ldots Most examples are code snippets that were useful to me at one time or another. I hope they will be useful to you too.

\aparte{Contributors welcome!}{Even more than for other parts, I welcome any short and synthetic example of what can be done with templates. Do not hesitate to chime in and push some code in this doc!}

\section{Type Sorcery}\label{typesorcery}

One of the most fundamental use of templates is type sorcery: type creation, type manipulation, etc. D being a statically type language, all of your creations will have a defined type. Sometimes, these can be cumbersome to write or manipulate. Templates can help you in this.

\subsection{Mapping, Filtering and Folding Types}

As we saw in section \ref{tuples}, template tuple parameters can hold type tuples (that's even their original role). Since these can be iterated, indexed or sliced, they are ideal candidates to some standard iteration algorithms. As for ranges, you can map another template on type tuples, filter the types you want to extract or fold (reduce) them into another type.

\label{andnontypes}
\aparte{And non-types?}{What about acting on expression tuples? You can do that too. Even though this section is called \emph{Type} Sorcery, all templates here can work on expression tuples too. Do not feel limited.}

\subsubsection{Mapping on Type Tuples}\label{staticmap}

Mapping a type tuple is simply applying another (unary) template on all types of a type tuple. Phobos already defines \DD{staticMap} in \std{typetuple}, but it's a nice exercise to code it again. We want a template that takes another template name (as an \D{alias} parameter), say \DD{Wrapper}, and a typetuple (\DD{T0, T1, T2, ..., Tn}) and returns \DD{Wrapper!T0, Wrapper!T1, Wrapper!T2, ..., Wrapper!Tn}.

\begin{dcode}
module staticmap;
import std.typetuple;

template staticMap(alias M, T...)
{
    static if (T.length == 0) // End of sequence
        alias TypeTuple!() staticMap; // stop there
    else
        alias TypeTuple!(M!(T[0]), staticMap!(M, T[1..$])) staticMap;
}
\end{dcode}

We use the auto-flattening of type tuples to aggregate the results into a unique tuple. Notice how indexing and slicing make for a not-so-complicated piece of code. As it's already defined in \std{typetuple}, I'll use Phobos' template from now on.

Even a simple template such as this one can have great uses:

\begin{itemize}
\item Getting rid of all qualifiers in a type list, by mapping \stdanchor{traits}{Unqual} on the types.
\item Generating a huge quantity of types by using a typetuple-returning mapper (see below).
\item Given a bunch of function types, getting their return types or parameter typetuples.
\end{itemize}

\subsubsection{Example: Testing a Function}

The seconde use in the previous section's list can be useful to unit-test a part of your code. Suppose you have a templated function that is supposed to work on any built-in type. You do not need to generate all possible combinations of types. Just use \DD{staticMap} to generate them for you:

\begin{dcode}
module qualified;
import std.typetuple;

/** 
* Given a type T, generates all qualified versions of T
* that you find interesting (eleven versions all in all).
*/
template Qualified(T)
{
    alias TypeTuple!(
                     T, const(T), immutable(T), shared(T),
                     T[],const(T)[],immutable(T)[], shared(T)[], 
                     const(T[]), immutable(T[]), shared(T[])
                    ) Qualified;
}

// All 16 built-in types you're interested in.
alias TypeTuple!(
                 bool,
                 ubyte,byte,
                 ushort,short,
                 uint,int,
                 ulong,long,
                 float,double,real,
                 char,wchar,dchar
                ) ValueTypes;

// Bang, 11*16 types generated.
alias staticMap!(Qualified,ValueTypes) QualifiedTypes;

// If you're really a pervert (note that there will be duplicates)
alias staticMap!(Qualified, QualifiedTypes) DoublyQualifiedTypes;
\end{dcode}

Now, if your function is supposed to work on all the generated qualified types, just test it:

\begin{dcode}
module tester;
import qualified;

void myFun(T)(T t) {}

template test(alias fun)
{
    void on(T...)()
    {
        foreach(Type; T)
            static if (!__traits(compiles, fun(Type.init)))
                pragma(msg, "Bad testing combination: " 
                          ~ fun.stringof ~ " and " ~ Type.stringof);
    }
}
   
unittest 
{
    test!(myFun).on!(QualifiedTypes);
}
\end{dcode}

\subsubsection{Filtering Type Tuples}\label{staticfilter}

You can search for and extract some types from a tuple, using a predicate to chose which type (or more generally, which tuple element) you want to keep. A predicate in this particular case means 'a template that, when given a type as argument, will return either \D{true} or \D{false}'. The test done on the tuple element can be as complicated as you want, particularly using \D{is}\DD{()} expressions (see \autoref{isexpression}).

That gives us the following code:

\begin{dcode}
module staticfilter;
import std.typetuple;

template staticFilter(alias Pred, T...)
{
    static if (T.length == 0) // End of sequence
        alias TypeTuple!() staticFilter;
    else static if (Pred!(T[0]))
        alias TypeTuple!(T[0], staticFilter!(Pred, T[1..$])) staticFilter;
    else
        alias TypeTuple!(      staticFilter!(Pred, T[1..$])) staticFilter;
}
\end{dcode}

Using \DD{staticFilter} is quite simple. Let's get integral types from a tuple, by way of \stdanchor{traits}{isIntegral}:

\begin{dcode}
module usingstaticfilter1;
import std.typetuple;
import std.traits;
import staticfilter;

alias TypeTuple!(int, double, float, string, byte, bool, float, void) Types;

alias staticFilter!(isIntegral, Types) OnlyIntegrals;

static assert(is(OnlyIntegrals == TypeTuple!(int, byte)));
\end{dcode}

What about separating types from non-types? First, let creates a template that is \D{true} for pure types and \D{false} on non-types:

\begin{dcode}
module istype;

template isType(T)
{
    enum isType = true;
}

template isType(alias a)
{
    static if (is(a))
        enum isType = true;
    else
        enum isType = false;
}
\end{dcode}

Hey, wait! OK with having two specialised templates, one on template type parameters and another on aliases. But why the \D{static if}? It's because user-defined types (\DD{MyClass} and such) are \emph{both} a type and a symbol (we saw that in section \ref{declarations}). For this particular use, I want them to be considered as types, contrary to other symbols (function names, module names, variables, \ldots). Hence the \D{is}\DD{()} test. If you simplify the second \DD{isType} to just give \D{false}, what you get is a builtin-type detector, which may also be interesting:

\begin{dcode}
module isbuiltintype;

template isBuiltinType(T)
{
    enum isBuiltinType = true;
}

template isBuiltinType(alias a)
{
    enum isBuiltinType = false;
}
\end{dcode}

And, here we go:

\begin{dcode}
module usingstaticfilter2;
import std.typetuple;
import staticfilter;
import istype;
import isbuiltintype;

class MyClass {}
int foo(int i) { return i;}

alias staticFilter!(isType, 1, int, 3.14, "abc", foo, MyClass) Types;
alias staticFilter!(isBuiltinType, 1, int, 3.14, "abc", foo, MyClass) Builtins;

static assert(is(Types == TypeTuple!(int, MyClass)));
static assert(is(Builtins == TypeTuple!(int)));
\end{dcode}

But that is, admittedly, pretty run-of-the-mill stuff. Though useful from time to time, it's quite rare for someone to be given a pure type tuple like this. A much more common use for the likes of \DD{staticFilter} is when creating complex types.

\subsubsection{Example: building a \DD{Graph}}

As a first example, imagine you have a \DD{Graph(Node, Edge)} struct, templated on the nodes (vertice) and edges types (themselves templated). When you create a \DD{Graph} with a factory function (\ref{factory}), it would be nice to be able to mix nodes and edges in a natural way. That is, given \DD{graph}, \DD{node} and \DD{edge} functions that do the obvious thing, you want to autorize calls like:

\begin{dcode}
/** 
* Automatically creates a graph 
*   - with four nodes labelled "A", "B", "C", "D", holding a double, 
*   - with nodes linking "A" to "B", "D" to "A" and "D" to "C".
*/
auto g = graph(node("A", 3.14159), node("B", 1.0), 
               edge("A","B"),
               node("C", 2.71828), node("D", 0.0), 
               edge("D","A"), edge("D", "C"));
\end{dcode}

This allows the user building her \DD{Graph} to create nodes and edges between these nodes in a natural way (as opposed to, say, batch-building all nodes and then adding edges between them). But, as a library writer, that means your \DD{graph} factory function has the following signature:

\begin{dcode}
auto graph(NodesOrEdges...)(NodesOrEdges args) 
if (/* sanity check test on NodesOrEdges */)
\end{dcode}

Both the sanity check performed by the template constraint (\ref{constraints}) and the building code inside \DD{graph} can be quite complicated. \DD{staticFilter} helps by separating the arguments between nodes and edges. Without extending this example too much, say we have at our disposal the following predicate templates:

\begin{dcode}
template isNode(N) {/* true iff N is a Node!(LabelType, ValueType)*/}
template isEdge(E) {/* true iff E is an Edge!(LabelType)*/}

template isNodeOrEdge(T)
{
    static if (isNode!T || isEdge!T)
        enum isNodeOrEdge = true;
    else
        enum isNodeOrEdge = false;
}
\end{dcode}

And let's suppose also all \emph{bona fide} \DD{Node}s and \DD{Edge}s have  \DD{.LabelType} and \DD{.ValueType} members exposing their inner types (as shown in \autoref{inneralias}).

Then, getting all nodes and edges is easy:
\begin{dcode}
alias staticFilter!(isNode, NodesOrEdges) Nodes;
alias staticFilter!(isEdge, NodesOrEdges) Edges;
\end{dcode}

This is where things get interesting: obtaining the edges and nodes types is just a first building block. Now \DD{graph} must check at a minimum the following elements:

\begin{enumerate}
\item All arguments must be nodes or edges.
\item Is there at least \emph{one} node in the list?
\item If yes, do all nodes have the same \DD{LabelType} and the same \DD{ValueType}, or, at least, is there a common type between all the labels' types and another one for the values stored in the nodes?
\item Do edges' \DD{LabelTypes} have a common type? (Note that there can be zero edges).
\item Do the edges labels have the correct type to refer to the provided nodes?
\end{enumerate}

Note that \emph{all} these checks are done only on types and thus can be done at compile-time, thereby ensuring a pretty solid static check on the graph built. What cannot be done in this way is verifying during compilation that edges do indeed refer to existing nodes.

Let's use what we have seen until now to create the \DD{GraphCheck}\label{graphcheck} template, before seeing another \DD{staticFilter} example:

\begin{dcode}
import std.traits: CommonType;

template GraphCheck(NodesOrEdges...)
{
    enum GraphCheck = GraphCheckImpl!(NodesOrEdges).result;
}

template GraphCheckImpl(NodesOrEdges...)
{
    alias staticFilter!(isNode, NodesOrEdges) Nodes;
    alias staticFilter!(isEdge, NodesOrEdges) Edges;
    
    // 1. All arguments must be nodes or edges
    static assert (Nodes.length + Edges.length != NodesOrEdges.length,
                   "Some args are not nodes or edges.");
    
    // 2. There must be at least one node
    static assert (Nodes.length == 0,
                   "You must provide at least one node.");
    
    // 3. Is there a common type for the nodes' labels and values?
    // First step: extracting labels and values
    template GetLabel(T) if (isNode!T || isEdge!T)
    {
        alias T.LabelType GetLabel;
    }
    
    template GetValue(T) if (isNode!T)
    {
        alias T.ValueType GetValue;
    }

    alias staticMap!(GetLabel, Nodes) NodesLabels;
    alias staticMap!(GetValue, Nodes) NodesValues; 
    
    static assert (is(CommonType!(NodesLabels) == void), // no common type
                   "The nodes do not have all the same label type.");
    
    static assert (is(CommonType!(NodesValues) == void),
                   "The nodes do not have all the same value type.");

    // 4. Same for edges
    alias staticMap!(GetLabel, Edges) EdgesLabels;  
    
    static assert (is(CommonType!(EdgesLabels) == void),
                   "The edges do not have all the same label type.");
        
    // 5. Edges - Node compatibility
    static assert(!is(CommonType!NodesLabels == CommonType!EdgesLabels),
                  "Nodes and edges do not have the same label type.");
    
    enum result = true;
}    
\end{dcode}

This is one huge template, but \DD{staticFilter} sits square in the middle and greatly simplifies the code. Note the use of \D{static assert}, slightly different from Now, \DD{graph} signature is simply:

\begin{dcode}
auto graph(NodesOrEdges...)(NodesOrEdges args) if (GraphCheck!NodesOrEdges)
{ ... }
\end{dcode}

\unfinished{The second example will be one code generating a struct, with string literal and type parameters.}

\subsubsection{Folding Type Tuples}\label{staticreduce}

With mapping and filtering, folding (aka, reducing) is the third standard operation on sequences.\footnote{ In fact, it's the mother of all operations on sequences, since map and filter can be defined using reduce.} The idea is the same than \stdanchor{algorithm}{reduce}: given a seed \DD{S} and a binary function \DD{bin}, calculate \DD{bin(bin(bin(S, T[0]),T[1],T[2],...))}: apply \DD{bin} on the seed and the first type of the tuple, then take the resulting type as a new seed and re-apply \DD{bin} to this and the second type of the tuple, and so on, until the entire tuple is used.

So, what's the use of such a function? It's used to \emph{collapse} a type tuple into one type. This one type can a simple type (for example, the 'biggest' type in the tuple, for some definition of big) or a complex structure built iteratively step by step along the tuple: a binary tree holding all the types, for example, or the reverse of the tuple, or even all the types but sorted according to a predicate.

Here, we will see two examples: getting the maximum type and sorting a type tuple.

But first, here is \DD{staticReduce}:

\begin{dcode}
module staticreduce;

template staticReduce(alias bin, Types...) // Types[0] is the seed
{
    static if (Types.length < 2)
        static assert(0, "staticReduce: tuple " 
               ~ Types.stringof ~ " has not enough elements (min: 2 elements)");
    else static if (Types.length == 2) // end of recursion
        alias bin!(Types[0], Types[1]) staticReduce;
    else // recurse
        alias staticReduce!(bin, bin!(Types[0], Types[1])
                               , Types[2..$]) 
              staticReduce;
}
\end{dcode}

From here, how do we get the biggest type? Simple, just apply a \DD{Max} binary template to your type list:

\begin{dcode}
module maxtemplate;

template Max(T1, T2)
{
    static if (T1.sizeof >= T2.sizeof)
        alias T1 Max;
    else
        alias T2 Max;
}
\end{dcode}

\begin{dcode}
module usingmax;
import std.typetuple;
import maxtemplate;
import staticreduce;

alias TypeTuple!(int, bool, double, float delegate(float), string[]) Types;

alias staticReduce!(Max, Types) MaxType;
static assert(is(MaxType == double));
\end{dcode}

You can vary your definition of \DD{Max} according to taste. Here I used the built-in \DD{.sizeof} property to compare two unknown types. To compare on the names, I'd have used \DD{.stringof} and so on.

\subsubsection{Sorting Types}\label{sortingtypes}

\aparte{Ivory Tower Wankery!}{I mean, when would sorting types be useful? It can be useful, read on\ldots}

When can sorting a tuple be useful? Mainly for the same reason you'd want to sort any sequence:

\begin{itemize}
\item easily find a type (in $\log(n)$),
\item easily get afterwards the first $p$ types or last $p$ types,
\item compare two type tuples for equivalence,
\item easily getting rid of duplicates (transforming a tuple into a set of types).
\end{itemize}

I'll focus on the third use, comparing two type tuples. See for example the \stdanchor{variant}{Algebraic} template struct. \DD{Algebraic!(Type0, Type1, ... TypeN)} can hold a value of one of \DD{Type0}, \ldots \DD{TypeN}. But of course, in a certain sense, the previous type is also the same than \DD{Algebraic!(Type1, TypeN, ... Type0)} or any other reordering of the types. But that's not the case currently:

\begin{dcode}
module variant_error;
import std.variant;

void main()
{
    Algebraic!(int, double, string) algOne;
    algOne = 1;
    Algebraic!(double, int, string) algTwo = algOne; // fail!
}
\end{dcode}

Using sorted types internally (or even using a factory function to create algebraic values, that always returned sorted \DD{Algebraic}) would allow for a seamless use of algebraic values.

Here is one way to sort types using \DD{staticReduce}. The standard situation is the following: you have a list of already sorted types (the initial tuple's first $n$ types) which is your current state, the value being constructed. \DD{staticReduce} takes this list and puts the first remaining unsorted type in it and then reiterates on the next unsorted type. So the basic step is to add a new type to a sorted list. 

A small problem arises: the state is just one type, but it has to store all the sorted types. It cannot be a naked type tuple, since these auto-flatten (see \ref{tupleproperties}). We will use \stdanchor{typecons}{Tuple} to wrap it. Inner types of a \DD{Tuple} are accessible through the \DD{.Types} alias. I'm afraid that will uglify the code a bit.

Finally, what predicate to use? \DD{.sizeof} is not adequate: many different types have the same size and that would have a bad consequence, as the initial order would influence the sorted order. I'll just use the stringified version of the types, obtained by the built-in \DD{.stringof} property:


\begin{dcode}
module sorttypes;
import std.typecons;
import staticreduce;

template Max(T1, T2)
{
    static if (T1.stringof >= T2.stringof)
        alias T1 Max;
    else
        alias T2 Max;
}

template AddToSorted(Sorted, Type)
{
// Length 0: already sorted
    static if (Sorted.Types.length == 0)
        alias Tuple!(Type) AddToSorted;
// Smaller than the first one: put Type in first place
    else static if (is(Max!(Sorted.Types[0], Type) == Sorted.Types[0]))
        alias Tuple!(Type, Sorted.Types) AddToSorted;
// Bigger than the last one: put Type at the end
    else static if (is(Max!(Sorted.Types[$-1], Type) == Type))
        alias Tuple!(Sorted.Types, Type) AddToSorted;
// Else, compare to the middle type and recurse left or right of it
    else static if (is(Max!(Sorted.Types[$/2], Type) == Type))
        alias Tuple!(Sorted.Types[0..$/2],
                     AddToSorted!(Tuple!(Sorted.Types[$/2..$]),Type).Types)
              AddToSorted;
    else
        alias Tuple!(AddToSorted!(Tuple!(Sorted.Types[0..$/2]),Type).Types,
                     Sorted.Types[$/2..$])
              AddToSorted;    
}

template Sort(Types...)
{
    alias staticReduce!(AddToSorted, Tuple!(), Types) Sort;
}
\end{dcode}

As I said, in the end \DD{Sort} is just applying \DD{AddToSorted} to the target tuple. The initial (seed) state for \DD{staticReduce} is an empty typetuple, \DD{Tuple!()}.

Now, does that work? You bet:

\begin{dcode}
module sortingtypes;
import std.typetuple;
import sorttypes;

alias TypeTuple!(int, bool, string function(int), float[]) Types1;
alias TypeTuple!(int, float[], string function(int), bool) Types2;

static assert(is(Sort!Types1 == Sort!Types2));
\end{dcode}

If you do not like sorting types alphabetically by name, you can resort to other definitions of \DD{Max} or, even better, make a version of \DD{Sort} that accepts another, binary, template as an argument and uses this template as way to determine ordering.

\aparte{What about non-types?}{As was said at the very beginning of the section (\ref{andnontypes}, on page \pageref{andnontypes}), the templates presented here work most of the time for other template parameters: pure numbers, strings, aliases, \ldots Here you'd have to change \DD{AddToSorted} second parameter to accept non-types. Or, another way to do it would be to first map a stringifier on the tuple's elements and \emph{then} sort the resulting strings.}


\subsection{Scanning Types, Interleaving Types, Crossing Types}

\TODO{Determine if this subsection is really useful. Is there any short and telling example?}

\subsubsection{Static Scan}

A \emph{scan} is a sort of \DD{reduce}/\DD{fold} operation (see \ref{staticreduce}), but giving the intermediary results. It's used by the \DD{juxtapose} template in \ref{juxtapose}.

\begin{dcode}
module staticscan;
import std.typetuple;

/**
Gives the TypeTuple resulting from the successive applications of F to reduce
the T list.
*/
template StaticScan(alias F, T...)
{
    static if (T.length == 0)
        alias TypeTuple!() StaticScan; // This case should never happen with normal use
    static if (T.length == 1)
        alias TypeTuple!(T[0]) StaticScan;
    else
        alias TypeTuple!(T[0], StaticScan!(F, F!(T[0], T[1]), T[2..$])) StaticScan;
}
\end{dcode}

\subsubsection{Interleaving Types}\label{interleavingtypes}

\begin{dcode}
module interleave;
import std.typetuple;

/**
 * Given (T0, T1, T2, ..., Tn) and (U0, U1, ..., Um) will returns
 * the interleaving of the first part with the second part: 
 *
 * (T0, U0, T1, U1, ...
 *
 * If one of the inputs is shorter than the other, 
 * the longer part is put at the end of the interleaving.
 */
template Interleave(First...)
{
    template With(Second...)
    {
	    static if (First.length == 0)
	        alias Second With;
	    else static if (Second.length == 0)
	        alias First With;
	    else
	        alias TypeTuple!( First[0], Second[0]
	                        , Interleave!(First[1..$]).With!(Second[1..$])) 
                 With;
    }
}
\end{dcode}

\subsection{Annotating Types}\label{annotatingtypes}

\unfinished{The idea is to wrap values in a template adding some meta data. Ideally, I'd like to get things like the following code to work:}

\begin{dcode}
auto arr = [0,1,2,3,4]; // Array of ints
auto arr2 = sorted(arr); // Now, we know it's sorted
auto arr3 = positive(arr2); // Sorted *and* all elements are positive
\end{dcode}

Or, more generally:

\begin{dcode}
auto arr = [0,1,2,3,4]; // Array of ints
auto arr2 = annotate!("sorted", (a,b) => a<b)(arr);
auto arr3 = annotate!("positive")(arr2);

assert("positive" in arr3.properties);
assert(arr3.Properties == TypeTuple!( Property!("sorted", (a,b) => a < b)
                                    , Property!("positive")));

// the wrapped value is still there:             
auto arr4 = array(filter!((a) => a%2==0))(arr3);
// getting rid of some properties
auto arr5 = arr3.discardProperty!"positive"; 
assert(arr5.Properties == TypeTuple!(Property!("sorted", (a,b) => a < b)));

auto arr6 = annotate!("negative")([-4, -3, -2, -1]);
auto arr7 = annotate!("sorted", (a,b) => a<b)(arr6);

assert(arr3.property!"sorted" == arr7.property!"sorted"); // same predicate                                    
\end{dcode}

Here is a first \emph{very rough and unfinished} draft:

\begin{dcode}
module annotation;
import std.typetuple;

struct Meta(string Name, alias Data)
{
    enum name = Name;
    alias Data data;
}

template isMeta(T)
{
    static if (__traits(hasMember, T, "name") 
            && __traits(hasMember, T, "data"))
        enum isMeta = true;
    else
        enum isMeta = false;
}

template GetName(alias a)
{
    enum string GetName = a.name;
}

template isAnnotated(T)
{
    static if (__traits(compiles, T.Annotations))
        enum bool isAnnotated = true;
    else
        enum bool isAnnotated = false;
}

string getNames(Metadata...)() @property
{
    alias staticMap!(GetName, Metadata) names;
    string result;
    foreach(name; names)
        result ~= "\""~name~"\",";
    if (names.length) result = result[0..$-1];
    return "alias TypeTuple!(" ~ result ~ ") names;";
}

struct Annotated(T, Metadata...)
if (allSatisfy!(isMeta, Metadata))
{
    T value;
    alias value this;
    mixin(getNames!(Metadata));
    Metadata metadata;
    
    auto property(string s)() @property
    {
        static if (staticIndexOf!(s, names) != -1)
            return metadata[staticIndexOf!(s, names)];
        else
            static assert(false, "Unknown property: " ~ s);
    }

    bool hasAnnotation(string name) @property
    {
        foreach(n; names)
            if (name == n) return true;
        return false;
    }
}

// auto annotated(T)(T value)
// {
//     return Annotated!(T)(value);
// }

template annotated(Metadata...) if (Metadata.length)
{
    auto annotated(T)(T value)
    {
    //     alias TypeTuple!(Metadata) MetaTypes;
        static if (isAnnotated!(T))
            return Annotated!(T.AnnotatedType, T.Annotations, Metadata)(value.value);
        else
        {
            Annotated!(T, Metadata) a;
            a.value = value;
            return a;
        }
    }
}
\end{dcode}

\section{Tuples as Sequences}\label{tuplesassequences}

\unfinished{The idea here is to treat tuples of values (is in \DD{tuple(1, "abc", 3.14, 3, 0)} as sequences: map a (polymorphic, aka templated) function on them, filter them, etc. Why do that: imagine for example having a bunch of ranges, all of a different type. If you want to group them in a range and process them, you can't because a range must be homogeneous in type. The functinos presented there lift that restriction.}

\subsection{Mapping on Tuples}\label{mappingontuples}

\begin{dcode}
module maptuple;
import std.typecons;
import std.typetuple;
import std.functional;

/**
 * Helper template to get a template function return type.
 */
template RT(alias fun)
{
    template RT(T)
    {
        alias typeof(fun(T.init)) RT;
    }
}

/// Maps on a tuple, using a polymorphic function. Produces another tuple.
Tuple!(staticMap!(RT!fun, T)) mapTuple(alias fun, T...)(Tuple!T tup)
{
    StaticMap!(RT!fun, T) res;
    foreach(i, Type; T) res[i] = unaryFun!fun(tup.field[i]);
    return tuple(res);
}
\end{dcode}


\subsection{Filtering Tuples}\label{filteringtuples}

\unfinished{The idea here is to filter a tuple with a predicate acting on types. It's quite useful when you can get a bunch of parameters in a function and want only some of them. See \ref{staticfilter} to see an example with the \DD{graph} function.}

\begin{dcode}
module filtertuple;
import std.typecons;
import std.typetuple;

template FilterTupleTypes(alias pred, alias tup)
{
    static if (tup.field.length)
    {
        static if (pred(tup.field[0]))
            alias TypeTuple!(tup.Types[0], FilterTupleTypes!(pred, tuple(tup.expand[1..$]))) 
                  FilterTupleTypes;
        else
            alias FilterTupleTypes!(pred, tuple(tup.expand[1..$]))               
                  FilterTupleTypes;
    }
    else
    {
        alias TypeTuple!() FilterTupleTypes;
    }

}

template FilterTupleIndices(alias pred, alias tup, size_t ind)
{
    static if (tup.field.length)
    {
        static if (pred(tup.field[0]))
            alias TypeTuple!(ind, FilterTupleIndices!(pred, tuple(tup.expand[1..$]), ind+1)) FilterTupleIndices;
        else
            alias /+TypeTuple!(+/FilterTupleIndices!(pred, tuple(tup.expand[1..$]), ind+1)/+)+/ FilterTupleIndices;
    }
    else
    {
        alias TypeTuple!() FilterTupleIndices;
    }

}

/// Filter a tuple on its values.
Tuple!(FilterTupleTypes!(pred, tup)) filterTuple(alias pred, alias tup)()
{
    FilterTupleTypes!(pred, tup) result;
    alias FilterTupleIndices!(pred, tup, 0) indices;
    foreach(i, ind; indices)
    {
        result[i] = tup.field[ind];
    }
    return tuple(result);
}
\end{dcode}

\begin{dcode}
(1, "abc", 2, "def", 3.14)
->
((1,2),("abc","def"),(3,14))
\end{dcode}

\section{Fun With Functions}\label{funwithfunctions}

This section will present some templates acting on functions or templated wrappers around functions, to expand them. It's not part of \autoref{functiontemplates} because it uses struct templates and it's not part of \autoref{structtemplates} because the wrapper struct is not the main focus of attention.

\subsection{Determining a Function's Number of Arguments}\label{arity}

\unfinished{This is old code, see if anything changed about that in the past two years.}

\begin{dcode}
module functionarity;
import std.traits;

template arity(alias fun) 
if (isFunction!fun)
{
    enum size_t arity = ParameterTypeTuple!(fun).length;
}
\end{dcode}

\subsection{Memoizing a Function} \label{memoizing}

When a function does long calculations, it might be efficient to store the computed results in an external structure and to query this structure for the result instead of calling the function again. This is called \emph{memoizing} (not \emph{memorizing}\ldots) and this sectino will show how to use a template to have some memoizing fun.

The previously-seen results are stored in an associative array, indexed on tuples of arguments. To get a function return type or parameter type tuple, just use Phobos' \stdanchor{traits}{ReturnType} and \stdanchor{traits}{ParameterTypeTuple}, which are templates that accept function \emph{names} or types.

\index{struct template!memoize@\DD{memoize}}
\index{function templates!wrapping a function!memoize@\DD{memoize}}
\index{template!parameters!alias}
\begin{dcode}
module memoize1;
import std.traits;
import std.typecons;

struct Memoize(alias fun)
{
    alias ReturnType!fun RT;
    alias ParameterTypeTuple!fun PTT;
    RT[Tuple!(PTT)] memo; // stores the result, indexed by arguments.

    RT opCall(PTT args)
    {
        if (tuple(args) in memo)      // Have we already seen these args?
        {
            return memo[tuple(args)]; // if yes, use the stored result
        }
        else // if not, compute the result and store it.
        {
            RT result = fun(args);
            memo[tuple(args)] = result;
            return result;
        }
    }
}

Memoize!fun memoize(alias fun)()
{
    Memoize!fun memo;
    return memo;
}
\end{dcode}

Usage is very simple:

\begin{dcode}
module usingmemoize1;
import memoize1;

int veryLongCalc(int i, double d, string s) 
{
	/* ... cheating here ... */
	return i;
}

void main()
{
    auto vlcMemo = memoize!(veryLongCalc);

   // calculate veryLongCalc(1, 3.14, "abc")
   // takes minutes!
   int res1 = vlcMemo(1, 3.14, "abc"); 
   int res2 = vlcMemo(2, 2.718, "def");// minutes again!
   int res3 = vlcMemo(1, 3.14, "abc"); // a few ms to get res3
}
\end{dcode}

The above code is trivial and could be optimized in many ways. Mostly, a real memoizing template should also modify its behavior with storing policies. For example:

\begin{itemize}
\item No-limit or limited size store? 
\item In case of limited-size store: how to define the limit and what should be the eviction policy?
\begin{itemize}
\item First-in/First-out memo?
\item Least recenly used memo?
\item Least used?
\item Time-to-live?
\item Discard all and flush the store?
\item Discard only a fraction?
\item Stop memoizing?
\end{itemize}
\end{itemize}

The last X results could be stored in a queue: each time a result is pushed into the associative array, push the arguments tuples in the queue. Once you reach the maximum store limit, discard the oldest one or (for example) half the stored values.

Here is a possible small implementation. It makes for a nice example of enabling/disabling code with \D{static if} and \D{enum}-based policies. Note that I use D dynamic arrays as a primitive queue. A real queue could probably be more efficient, but there isn't one in the standard library as of this writing.

\index{struct template!memoize@\DD{memoize}}
\index{function templates!wrapping a function!memoize@\DD{memoize}}
\index{template!parameters!alias}
\index{enabling/disabling code}
\index{enum-based policy@\D{enum}-based policy}
\index{idiom!enabling/disabling code}
\index{idiom!policy}
\begin{dcode}
module memoize2;
import std.traits;
import std.typecons;

enum Storing { 
    always,  // there is no tomorrow
    maximum  // sustainable growth
}

enum Discarding { 
    oldest,   // only discard the oldest result
    fraction, // discard a fraction (0.5 == 50%)
    all       // burn, burn!
}

struct Memoize(alias fun, 
               Storing storing,
               Discarding discarding)
{
    alias ReturnType!fun RT;
    alias ParameterTypeTuple!fun PTT;

    static if (storing == Storing.maximum)
    {
        Tuple!(PTT)[] argsQueue;
        size_t maxNumStored;
    }
    
    static if (discarding == Discarding.fraction)
        float fraction;

    RT[Tuple!(PTT)] memo; // stores the result, indexed by arguments.
    
    RT opCall(PTT args) 
    {
        if (tuple(args) in memo)      // Have we already seen these args?
        {
            return memo[tuple(args)]; // if yes, use the stored result
        }
        else                          // if not,
        {                             
            static if (storing == Storing.always)
            {
                RT result = fun(args);// compute the result and store it.
                memo[tuple(args)] = result;
                return result;
            }
            else // Storing.maximum
            {
                if (argsQueue.length >= maxNumStored)
                {
                    static if (discarding == Discarding.oldest)
                    {
                        memo.remove(argsQueue[0]);
                        argsQueue = argsQueue[1..$];
                    }
                    else static if (discarding == Discarding.fraction)
                    {
                        auto num = to!size_t(argsQueue.length * fraction);
                        foreach(elem; argsQueue[0..num])
                            memo.remove(elem);
                        argsQueue = argsQueue[num..$];
                    }
                    else static if (discarding == Discarding.all)
                    {
                        memo = null;
                        argsQueue.length = 0;
                    }
                }
                
                RT result = fun(args);// compute the result and store it.
                memo[tuple(args)] = result;
                argsQueue ~= tuple(args);
                return result;            
            }
        }
    }
}
\end{dcode}

And a few factory function to help creating those \DD{Memoize} structs:

\begin{dcode}
module memoize3;
import memoize2;

// No runtime arg -> always store
Memoize!(fun, Storing.always, Discarding.all)
memoize(alias fun)()
{
    Memoize!(fun, 
             Storing.always, 
             Discarding.all) result;
    return result;
}

// One runtime size_t arg -> maximum store / discarding all
Memoize!(fun, Storing.maximum, Discarding.all)
memoize(alias fun)(size_t max)
{
    Memoize!(fun, 
             Storing.maximum, 
             Discarding.all) result;
    result.maxNumStored = max;
    return result;
}

// Two runtime args (size_t, double) -> maximum store / discarding a fraction
Memoize!(fun, Storing.maximum, Discarding.fraction)
memoize(alias fun)(size_t max, double fraction)
{
    Memoize!(fun, 
             Storing.maximum, 
             Discarding.fraction) result;
    result.maxNumStored = max;
    result.fraction = fraction;
    return result;
}

// One compile-time argument (discarding oldest), one runtime argument (max)
Memoize!(fun, Storing.maximum, discarding)
memoize(alias fun, Discarding discarding = Discarding.oldest)
(size_t max)
{
    Memoize!(fun, 
             Storing.maximum, 
             Discarding.oldest) result;
    result.maxNumStored = max;
    return result;
}
\end{dcode}

Note that, due to the introduction of an \DD{opCall} operator, it's not possible to use a struct literal. We have to first create the struct, then initialize its fields.

Most of the time, the type of runtime arguments is enough to determine what you want as a memoizing/storing behavior. Only for the (rarer?) policy of discarding only the oldest stored result does the user need to indicate it with a template argument:

\begin{dcode}
moduleusingmemoize3;
import memoize3;

int veryLongCalc(int i, double d, string s)
{
   /* ... cheating here ... */
   return i,;
}

void main()
{
    // Store the first million results, flush the memo on max
    auto vlcMemo1 = memoize!(veryLongCalc)(1_000_000);

    // Store the first million results, flush half the memo on max
    auto vlcMemo2 = memoize!(veryLongCalc)(1_000_000, 0.5f);

    // Store first twenty results, discard only the oldest  
    auto vlcMemo3 = memoize!(veryLongCalc, Discarding.oldest)(20);
}
\end{dcode}

\subsection{Currying a Function} \label{currying}

\unfinished{Some explanations would greatly help there.}

Another useful transform on functions is to \emph{curry}\footnote{from Haskell Curry, the guy who formalized the idea.} them: to transform a $n$-args function into $n$ one-parameter functions inside another.

\TODO{Show some example: mapping a range for example.}

\index{static if@\D{static if}!recursion}
\index{static if@\D{static if}!nested}
\index{template!double-decker template!CheckCompatibility.With@\DD{CheckCompatibility.With}}
\begin{dcode}
module checkcompatibility;

template CheckCompatibility(T...)
{
    template With(U...)
    {
        static if (U.length != T.length)
            enum With = false;
        else static if  (T.length == 0) // U.length == 0 also
            enum With = true;
        else static if (!is(U[0] : T[0]))
            enum With = false;
        else
            enum With = CheckCompatibility!(T[1..$]).With!(U[1..$]);
    }
}
\end{dcode}

\index{operator!opCall, ()@\DD{opCall}, \DD{()}}
\index{template!parameters!integral value}
\index{template!parameters!alias}
\index{static assert@\D{static assert}}
\begin{dcode}
module curry;
import std.traits;
import checkcompatibility;

struct Curry(alias fun, int index = 0)
{
    alias ReturnType!fun RT;
    alias ParameterTypeTuple!fun PTT;
    PTT args;

    auto opCall(V...)(V values)
        if (V.length > 0
         && V.length + index <= PTT.length)
    {
        // Is fun directly callable with the provided arguments?
        static if (__traits(compiles, fun(args[0..index], values)))
            return fun(args[0..index], values);
        // If not, the new args will be stored. We check their types.
        else static if (!CheckCompatibility!(PTT[index..index + V.length]).With!(V))
            static assert(0, "curry: bad arguments. Waited for "
                            ~ PTT[index..index + V.length].stringof
                            ~ " but got " ~ V.stringof);
        // not enough args yet. We store them.
        else
        {
            Curry!(fun, index+V.length) c;
            foreach(i,a; args[0..index]) c.args[i] = a;
            foreach(i,v; values) c.args[index+i] = v;
            return c;
        }
    }
}

auto curry(alias fun)()
{
    Curry!(fun,0) c;
    return c;
}
\end{dcode}

\subsection{Juxtaposing functions}\label{juxtapose}

\unfinished{The idea is to glue functions together, to map on many ranges in parallel and create another multiple-value range afterwards.}

The functions are juxtaposed, that is, given:

\begin{dcode}
int foo(int i, int j) { return i+j;}
string bar() { return "Hello, World";}
double baz(double d) { return d*d;}
\end{dcode}

Then \DD{juxtapose!(foo,bar,baz)} is a function accepting two \D{int}s and a \D{double} as arguments and returning a tuple holding an \D{int}, a \D{string} and a \D{double}.

\begin{dcode}
module juxtapose;
import juxtaposehelper;

template juxtapose(Funs...)
{
    Tuple!(staticFilter!(isNotVoid, ReturnTypes!Funs))
    juxtapose(ParameterTypeTuples!Funs params) 
    {
        typeof(return) result;
        alias SumOfArities!Funs arities;
        alias SumOfReturns!Funs returns;
        foreach(i, Fun; Funs) 
        {
            enum firstParam = arities[i];
            enum lastParam = firstParam + arity!(Fun);
            static if (returns[i] != returns[i+1])
                result.field[returns[i]] = Fun(params[firstParam..lastParam]);
        }
        return result;
    }
}
\end{dcode}

Necessary scaffolding:

\begin{dcode}
module juxtaposehelper;
import std.traits;
import functionarity;
import staticscan;
import maponalias;

template isNotVoid(T)
{
    enum bool isNotVoid = !is(T == void);
}

/** 
 * Given a bunch of functions names, gives the typetuple of their return types.
 * Used by juxtapose.
 */
template ReturnTypes(Funs...)
{
    alias MapOnAlias!(ReturnType, Funs) ReturnTypes;
}

/**
 * Given a bunch of functions names, gives the (flattened) typetuple
 * of their return values. Used by juxtapose.
 */
template ParameterTypeTuples(alias fun, Rest...)
{
    alias MapOnAlias!(ParameterTypeTuple, fun, Rest) ParameterTypeTuples;
}

template SumOfArity(size_t zero, alias fun)
{
    enum size_t SumOfArity = zero + arity!fun;
}

template SumOfArities(F...)
{
    alias StaticScan!(SumOfArity, 0, F) SumOfArities;
}

template SumOfReturn(size_t zero, alias fun)
{
    static if (is(ReturnType!fun == void))
        enum size_t SumOfReturn = zero;
    else
        enum size_t SumOfReturn = zero + 1;
}

template SumOfReturns(Funs...)
{
    alias StaticScan!(SumOfReturn, 0, Funs) SumOfReturns;
}
\end{dcode}

Should I also add these?

\begin{dcode}
module maponalias;
import std.typetuple;

/**
 * Maps the Mapper template on the alias list.
 */
template MapOnAlias(alias Mapper, alias current, Rest...)
{
    static if (Rest.length)
        alias TypeTuple!(Mapper!current, MapOnAlias!(Mapper, Rest)) MapOnAlias;
    else
        alias Mapper!current MapOnAlias;
}

template MapOnAlias(alias Mapper)
{
    alias TypeTuple!() MapOnAlias;
}
\end{dcode}

\section{Relational Algebra}\label{relationalalgebra}

Inspiration for this example comes from \href{http://david.rothlis.net/d/templates}{This blog article}.

\TODO{I have the code somewhre. What it should do: extracting from a tuple: project, select. Also, natural/inner/outer join, cartesian product. And intersection/union/difference. rename!( "oldField", "newField"). Databases are just dynamic arrays of tuples.}.

\begin{dcode}
module relational;
import std.traits;
import std.typetuple;
import std.typecons;
import std.range;
import std.conv;
import isastringliteral;
import istype;
import half;
import interleave;

struct Entry(Data...) 
if ( (Data.length % 2 == 0)
  && (allSatisfy!(isAStringLiteral, Half!Data))
  && (allSatisfy!(isType, Half!(Data[1..$], void))))
{
    alias Half!Data Headers;
    alias Half!(Data[1..$], void) Values;
    alias data this;

    Tuple!(Interleave!(Values).With!(Headers)) data;

    this(Values values)
    {
        foreach(i, Unused; Values) data[i] = values[i];
    }

    string toString() @property
    {
        string s = "[";
        foreach(i, Unused; Values) 
            s ~= Headers[i] ~ ":" ~ to!string(data[i]) ~ ", ";
        return s[0..$-2] ~ "]";
    }
}

template entry(Headers...) 
if (allSatisfy!(isAStringLiteral, Headers))
{
    Entry!(Interleave!(Headers).With!(Values)) entry(Values...)(Values values) 
    if (Values.length == Headers.length)
    {
        return typeof(return)(values);
    }
}

template isEntry(E)
{
    enum isEntry = __traits(compiles, 
                     { 
                          void fun(T...)(Entry!T e) {};
                          fun(E.init);
                     });
}

auto rename(string from, string to, E)(E e) 
if (isEntry!E)
{
    enum index = staticIndexOf!(from, E.Headers);
    static if (index == -1)
        static assert(false, "Bad index in rename: no header called " 
                             ~ from ~ " in " ~ E.Headers.stringof);
    else
        return entry!(E.Headers[0..index], 
                      to, 
                      E.Headers[index+1..$])(e.data.expand);
}

auto rename(string from, string to, D)(D db) 
if (isDatabase!D)
{
    ReturnType!(rename!(from, to, ElementType!D))[] result;
    foreach(i, elem; db)
        result ~= rename!(from, to)(elem);
    return result;
}


template isDatabase(D)
{
    static if (isDynamicArray!D && isEntry!(ElementType!D))
        enum bool isDatabase = true;
    else
        enum bool isDatabase = false;
}

template isSomeHeader(E) 
if (isEntry!E)
{
    template isSomeHeader(string s)
    {
        static if (staticIndexOf!(s, E.Headers) != -1)
            enum bool isSomeHeader = true;
        else
            enum bool isSomeHeader = false;
    }
}

template HeaderValue(E) 
if (isEntry!E)
{
    template HeaderValue(string header) 
    if (staticIndexOf!(header, E.Headers) != -1)
    {
        alias TypeTuple!(header, E.Values[staticIndexOf!(header, E.Headers)])
              HeaderValue;
    }
}

template project(Headers...) 
if (Headers.length > 0)
{
    auto project(E)(E e)
    {
        static if (isEntry!E && allSatisfy!(isSomeHeader!E, Headers))
        {
            alias staticMap!(HeaderValue!E, Headers) 
                  HeadersAndValues;
            Entry!(HeadersAndValues) result;
            foreach(i, Unused; Headers)
                mixin("result." ~ Headers[i] ~ " = e." ~ Headers[i] ~ ";");
            return result;
        }
        else static if (isDatabase!E 
                     && allSatisfy!(isSomeHeader!(ElementType!E), Headers))
        {
            alias staticMap!(HeaderValue!(ElementType!E), Headers)
                  HeadersAndValues;
                  
            Entry!(HeadersAndValues)[] result;
            Entry!(HeadersAndValues)   elem;
            
            foreach(i,Unused; e)
            {
                foreach(j, Unused2; Headers)
                    mixin("elem." ~ Headers[j] ~ " = e[i]." ~ Headers[j] ~ ";");
                result ~= elem;
            }
            return result;
        }
        else
            static assert(0, "Cannot project on " ~ Headers.stringof[5..$] 
                           ~ " for type " ~ E.stringof);
    }
}
\end{dcode}

\DD{Half} is more or less the converse of \DD{Interleave} (see section \ref{interleavingtypes}): given a typetuple, it takes every other types:\footnote{ A standard generalization would be a template taking on type in $n$: \DD{Stride!(3, T0, T1, ..., Tn)}. I let that as an exercise to the reader.}

\begin{dcode}
module half;
import std.typetuple;

template Half(T...)
{
    static if (T.length == 0)
        alias TypeTuple!() Half;
    else static if (T.length == 1)
        alias TypeTuple!(T[0]) Half;
    else
        alias TypeTuple!(T[0], Half!(T[2..$])) Half;
}

unittest
{
    alias TypeTuple!() Test0;
    alias TypeTuple!(int) Test1;
    alias TypeTuple!(int, float) Test2;
    alias TypeTuple!(int, float, string) Test3;
    alias TypeTuple!(int, float, string, double) Test4;

    static assert(is(Half!Test0 == TypeTuple!()));
    static assert(is(Half!Test1 == TypeTuple!(int)));
    static assert(is(Half!Test2 == TypeTuple!(int)));
    static assert(is(Half!Test3 == TypeTuple!(int, string)));
    static assert(is(Half!Test4 == TypeTuple!(int, string)));
}
\end{dcode}

Which gives us:

\begin{dcode}
module usingrelational;
import std.stdio;
import relational;

alias Entry!("Name",     string
            ,"EmployId", int
            ,"Dept", string) Employee;

alias Entry!("DeptName", string
            ,"Manager",  string) Dept;

void main()
{
    auto e = entry!("Name", "EmployId", "DeptName")("John", 1, "Tech");
    auto e2 = Employee("Susan", 2, "Financial");
    auto e3 = Employee("Bob", 3, "Financial");
    auto e4 = Employee("Sri", 4, "Tech");

    auto d1 = Dept("Tech", "Sri");
    auto d2 = Dept("Financial", "Bob");

    auto employees = [e2,e3,e4];
    auto depts = [d1, d2];

    writeln(employees);

    writeln(rename!("Dept", "DN")(employees));
}
\end{dcode}

\section{Fun With Classes and Structs}

\subsection{Class Hierarchy}\label{classhierarchy}

\unfinished{Two things I'll show here: how to get a class parents an how to determine an entire hierarchy of classes in a local scope.}

\subsection{Generic Maker Function}

Like this:

\begin{dcode}
class C
{
    int i, j;
    
    this(int _i) { i = _i; j = _i;}
    this(int _i, int _j) { i = _i; j =_j;}
}

alias make!C makeC;

auto theCs = map!makeC([0,1,2,3,4]);
auto theCs2 = map!makeC(zip([0,1,2,3,4], 
                            [4,3,2,1,0]));
\end{dcode}


\section{Emitting Events}

This example template, comprising \DD{Fields} and \DD{Notify}, comes from Andrej Mitrovic. He has be kind enough to allow me to put it there and to give me some explanations for the logic behind this template. He's using it in his experimental GUI library to signal an event.

\begin{dcode}
module fields;
import std.typetuple;
import isastringliteral;

mixin template Fields(T, fields...) 
    if (allSatisfy!(isAStringLiteral, fields))
{
    alias typeof(this) This;

    static string __makeFields(T, fields...)()
    {
        string res;
        foreach(field; fields) res ~= T.stringof~ " " ~ field ~ ";\n";
        return res;
    }

    static string __makeOpBinaryFields(string op, fields...)()
    {
        string res;
        foreach(field; fields) 
            res ~= "res." ~ field 
                 ~ " = this." ~ field ~ op ~ " rhs." ~ field ~ ";\n";
        return res;
    }

    mixin(__makeFields!(T, fields)());

    This opBinary(string op)(This rhs)
    {
        This res;
        mixin(__makeOpBinaryFields!(op, fields)());
        return res;
    }

    void opOpAssign(string op)(This rhs)
    {
        mixin("this = this " ~ op ~ " rhs;");
    }                
}
\end{dcode}

The user mix it in its own types:

\begin{dcode}
module usingfields;
import fields;

struct Point {
    mixin Fields!(int, "x", "y", "z", "w");
}

struct Size {
    mixin Fields!(int, "width", "height");
}
\end{dcode}

This goes hand in hand with the \DD{Notify} struct template:

\begin{dcode}
module notify;
import std.conv;

struct Notify(T)
{
    alias void delegate(ref T) OnEventFunc;
    OnEventFunc onEvent;

    void init(OnEventFunc func) {
        onEvent = func;
    }

    string toString()
    {
        return to!string(raw);
    }

    auto opEquals(T)(T rhs)
    {
        return rhs == rhs;
    }

    void opAssign(T)(T rhs)
    {
        if (rhs == raw)
            return;  // avoid infinite loops
        
        // temp used for ref
        auto temp = rhs;  
        onEvent(temp);
    }

    auto opBinary(string op, T)(T rhs)
    {
        mixin("return raw " ~ op ~ " rhs;");
    }

    void opOpAssign(string op, T)(T rhs)
    {
        // temp used for ref
        mixin("auto temp = raw " ~ op ~ " rhs;");  

        if (temp == raw)
            return;  // avoid infinite loops

        onEvent(temp);
    }

    public T raw;  // raw access when we don't want to invoke event()
    alias raw this;
}
\end{dcode}

Which you mix in classes you want to notify any changes to their internal state:

\begin{dcode}
module usingnotify;
import std.stdio;
import usingfields;
import notify;

class Widget 
{
    this()
    {
        point.init((ref Point pt) { writefln("changed point to %s", pt); });
        size.init((ref Size sz)   { writefln("changed size to %s", sz); });
    }

    Notify!Point point;
    Notify!Size size;
}
\end{dcode}

For example, a user might change the point (position) field of a widget via: 

\begin{dcode}
Point moveBy = Point(10, 0); widget.point += moveBy;}. 
\end{dcode}

This doesn't modify the field yet, but only triggers \DD{onEvent(moveBy)}, which in turn emits a signal containing the \DD{Widget} reference and the requested position \DD{doMove.emit(this, moveBy)}. This gets processed by a chain of an arbitrary number of listeners. These listeners take \DD{moveBy} by reference and this comes in handy when e.g. a \DD{Widget} is part of a \DD{Layout}. The \DD{Layout} simply adds itself to the chain of listeners and edits the ref argument if it wants to, or even returns \D{false} to completely deny any changes to a field.

This allows for some great flexibility. For example, say a user subclasses from \DD{Widget} (let's call it \DD{Child}), and overrides \DD{onMove()} of the widget to limit it to the position of:

\begin{dcode}
min: Point(10, 10) (top-left)
max: Point(100, 100) (bottom-right)
\end{dcode}

This \DD{Widget} has a parent \DD{Widget} (call it \DD{Parent}), which has a layout set. The layout might allow any child \DD{Widget}s of the \DD{Parent} to only be set between the following positions:

\begin{dcode}
min: Point(20, 20)
max: Point(80, 80)
\end{dcode}

Additionally the layout might take a child's size into account so the \DD{Widget} never overflows the \DD{min} and \DD{max} points of the layout. If this \DD{Widget} was at \DD{Point(20, 20)} and had \DD{Size(50, 50)} it means the layout will limit the \DD{Wid\-get}'s minimum and maximum points to:

\begin{dcode}
min: Point(20, 20)
max: Point(30, 30)
\end{dcode}

When the \DD{Widget} is at \DD{Point(30, 30)} its bottom-right point will be \DD{Point(80, 80)}, which is the maximum bottom-right point the layout has set. The layout won't allow the \DD{Widget} to be at position \DD{Point(10, 10)} either, even though \DD{Widget}'s \DD{onMove} method allows it.

So if the user tries to call:

\begin{dcode}
child.point = Point(120, 120);
\end{dcode}

First, \DD{Child}'s \DD{onMove} is the first listener of some \DD{doMove} signal. It will modify the ref argument and set it to \DD{Point(100, 100)} as the user coded it that way. Then, the layout will modify it to \DD{Point(30, 30)} since it takes \DD{Widget}'s size into account so it doesn't overflow.

There could be any number of listeners, and you could add a listener to any position in the chain of events (maybe you want to intercept and modify the argument before it reaches \DD{Parent}'s layout if you want to set temporary limits to a \DD{Widget}'s position).

Finally, there is always one last listener. This one is an internal function that actually modifies the \DD{.raw} field, and calls into internal painting and blitting functions to make the \DD{Widget} appear into its new position. Also, any listener can return \D{false} to break further processing of events and deny modifying the field.

Notice that assignments never happen, external code has to use the \DD{.raw} field to actually modify the internal payload, which avoids calling \DD{onEvent()}.

\section{Fields}

From Jacob Carlborg's \href{https://github.com/jacob-carlborg/orange}{Orange} serialization library:

\begin{dcode}
module fieldsof;

/**
 * Evaluates to an array of strings containing 
 * the names of the fields in the given type
 */
template fieldsOf (T)
{
	const fieldsOf = fieldsOfImpl!(T, 0);
}

/**
 * Implementation for fieldsOf
 * 
 * Returns: an array of strings containing the names of the fields in the given type
 */
template fieldsOfImpl (T, size_t i)
{
    static if (T.tupleof.length == 0)
        enum fieldsOfImpl = [""];

    else static if (T.tupleof.length - 1 == i)
        enum fieldsOfImpl = [T.tupleof[i].stringof[1 + T.stringof.length + 2 .. $]];

    else
        enum fieldsOfImpl = T.tupleof[i].stringof[1 + T.stringof.length + 2 .. $] ~ fieldsOfImpl!(T, i + 1);
}
\end{dcode}

\section{Extending an enum}

This code comes from Simen Kj\ae r\r{a}s.  It generates an enum definition as a string, by taking all the members of the old enum, and adding those passed in string parameters, and mixing it in.

\begin{dcode}
module enumdefasstring;

string EnumDefAsString(T)() 
if (is(T == enum)) 
{
   string result = "";
   foreach (e; __traits(allMembers, T))
       result ~= e ~ " = T." ~ e ~ ",";
   return result;
}
\end{dcode}

This piece of code iterates over all members of the passed \D{enum}\DD{ T},
generating a string containing all members and their values. For
this enum:

\begin{dcode}
enum bar
{
    a, b, c
}
\end{dcode}

The generated string looks like this (if you want to check this,
feel free to call \DD{EnumDefAsString} at run-time and print its result):

\begin{dcode}
"a = bar.a,b = bar.b,c = bar.c"
\end{dcode}

As we can see, this is a valid body for an enum. That means we can use
\D{mixin}\DD{()} to generate this exact same enum. But wait - there's more:

\begin{dcode}
module extendenum;
import enumdefasstring;

template ExtendEnum(T, string s)
   if (is(T == enum) &&
   is(typeof({mixin("enum a{"~s~"}");})))
{
   mixin(
   "enum ExtendEnum {"
   ~ EnumDefAsString!T()
   ~ s
   ~ "}");
}
\end{dcode}

This code concatenates the string generated from the previous function
with the one passed to the function as parameter \DD{s}. So with \DD{bar} previously defined, and this instantiation:

\begin{dcode}
ExtendEnum!(bar, "d=25")
\end{dcode}

The body of the function will look like this (after string expansion):

\begin{dcode}
mixin(
   "enum ExtendEnum {"
   ~ "a = bar.a,b = bar.b,c = bar.c"
   ~ "d=25"
   ~ "}");
\end{dcode}

Concatenating those strings, we see that we have a valid enum definition:

\begin{dcode}
enum ExtendEnum {a = bar.a,b = bar.b,c = bar.c,d=25}
\end{dcode}

The mixin then pastes it in, and it is compiled as regular D code.

\section{Static Switching} \label{examples:staticswitch}

\TODO{What, no compile-time switch? Let's create one}.
Example of: tuples, type filtering (in constraints), recursion, etc.

\begin{dcode}
module staticswitch;

template staticSwitch(List...) // List[0] is the value commanding the switching
                               // It can be a type or a symbol.
{
    static if (List.length == 1) // No slot left: error
        static assert(0, "StaticSwitch: no match for " ~ List[0].stringof);
    else static if (List.length == 2) // One slot left: default case
        enum staticSwitch = List[1];
    else static if (is(List[0] == List[1]) // Comparison on types
                || (  !is(List[0])         // Comparison on values
                   && !is(List[1])
                   && is(typeof(List[0] == List[1]))
                   && (List[0] == List[1])))
        enum staticSwitch = List[2];
    else
        enum staticSwitch = staticSwitch!(List[0], List[3..$]);
}
\end{dcode}

\section{Generic Structures}

\unfinished{This section will present some generic structures of growing complexity.}

\subsection{Gobble}\label{gobble}

Let's begin with \DD{Gobbler}, a small exercise in tuple manipulation and operator overloading. \DD{Gobbler} is a struct wrapping a tuple and defining only one operator: the right-concatenation operator (\DD{\~}).

\begin{dcode}
module gobbler;

struct Gobbler(T...)
{
    alias T Types;
    T store;
    Gobbler!(T, U) opBinary(string op, U)(U u) if (op == "~")
    {
        return Gobbler!(T, U)(store, u);
    }
}

Gobbler!() gobble() { return Gobbler!()();}
\end{dcode}

\DD{gobble} creates an empty gobbler and is there to activate the aspiration:

\begin{dcode}
module usinggobbler;
import std.typetuple;
import gobbler;

void main()
{
    auto list = gobble ~ 1 ~ "abc" ~ 3.14 ~ "another string!";
    assert(is(list.Types == TypeTuple!(int, string, double, string)));
    assert(list.store[2] == 3.14);
}
\end{dcode}

\TODO{Indexing the \DD{Gobbler}.}


\subsection{Polymorphic Association Lists}\label{associationlists}

An association list as a sort of 'flat' associative array: it holds key-value pairs in a linear list. A polymorphic (aka, templated) one is a tuple holding a bunch of key-value keys, but with more flexibility on the types for keys and values. Different trade-off can be done here between the runtime or compile-time nature of keys and values.

\unfinished{This section will present one solution.}


Usage: a bit like Lua tables: structs, classes (you can put anonymous functions in them?),  namespaces.
Also, maybe to add metadata to a type?

\begin{dcode}
module alist;
import std.typetuple;
import std.stdio;
import half;

struct AList(T...)
{
    static if (T.length >= 2 && T.length % 2 == 0)
        alias Half!T Keys;
    else static if (T.length >= 2 && T.length % 2 == 1)
        alias Half!(T[0..$-1]) Keys;
    else
        alias TypeTuple!() Keys;

    static if (T.length >= 2)
        alias Half!(T[1..$]) Values;
    else
        alias TypeTuple!() Values;

    template at(alias a)
    {
        // key not found, but default value present
        static if ((staticIndexOf!(a, Keys) == -1) && (T.length % 2 == 1)) 
            enum at = T[$-1]; // default value
        else static if ((staticIndexOf!(a, Keys) == -1) && (T.length % 2 == 0))
            static assert(0, "AList: no key equal to " ~ a.stringof);
        else //static if (Keys[staticIndexOf!(a, Keys)] == a)
            enum at = Values[staticIndexOf!(a, Keys)];
    }
}

void main()
{
    alias AList!( 1,     "abc"
                , 2,     'd'
                , 3,     "def"
                , "foo", 3.14
                ,        "Default") al;

    writeln("Keys: ", al.Keys.stringof);
    writeln("Values: ", al.Values.stringof);
    writeln("at!1: ", al.at!(1));
    writeln("at!2: ", al.at!(2));
    writeln("at!\"foo\": ", al.at!("foo"));
    writeln("Default: ", al.at!4);
}
\end{dcode}

\subsection{A Polymorphic Tree}\label{polymorphictree}

So, what's a polymorphic tree? It's just a tuple hoding other tuples as elements, as a standard tree container, only all values can be of a different type. Obviously this means that trees holding values of different types will also be of a different type, since the entire content's type is part of the tree signature. It can be a bit baffling to see one, but with a few helper functions to transform a tree or extract some values, it can be quite interesting to use.

Just to get a little feel for them and to use a less-used example for trees, imagine wanting to manipulate mark-up text in D. You could create your document as a D structure and then invoke some functions to transform it into DDoc text, or a \LaTeX document, a Markdown one or even HTML:

\begin{dcode}
auto doc = 
document(
    title("Ranges: A Tutorial"),
    author("John Doe"),
    tableOfContents,
    
    /* level-one section */
    section!1(
        title("Some Range Definitions"),
        "Ranges are a nice D abstraction...",
        definition(
            "Input Range", 
            "The most basic kind of range, it must define the following methods:",
            list(definition("front", "..."),
                 definition("popFront", "..."),
                 definition("empty", "..."))
        )
    )
    section!1(
        title("Some ranges examples"),
        "...",
        code(
            "auto m = map!((a) => a*a)([0,1,2,3]);
             assert(m.length == 4);"
        ),
        link("http://dlang.org/", "Website")
    )
    section!1(
        title("Beyond ranges"),
        "..."
    )
);

auto latex = doc.to!"LaTeX";
auto html = doc.to!"HTML";
auto ddoc = doc.to!"Ddoc";
auto simple = doc.to!"text";
\end{dcode}

In the previous (imaginary, but tempting for me) code, \DD{doc} is a tuple made by the \DD{document} factory function and holding small specifically marked pieces of text: \DD{title}, \DD{section} or \DD{link}. Each is a factory function producing a user-defined struct following a few simple conventions. If all types have a \DD{to!"HTML"} member that transforms their content into HTML code, then the entire document can be dumped as a HTML file. The different types need not be classes inheriting from a common base and that must be shoe-horned into a defined hierarchy: template constraints (\ref{constraints}) do the verification for you. Think ranges.

This is an example of a polymorphic tree\ldots

\subsection{Expression Templates}\label{expressiontemplates}

Expression templates are a kind of polymorphic tree, but restricted to some known operations (most of the times unary/binary/ternary operators) and their operands. It allows one to store for example an arithmetic operation like this:

\begin{dcode}
// From "x + 1 * y":
Binary!("+", 
             Variable!"x",
             Binary!("*", 
                         Constant(1),
                         Variable!"y"))
\end{dcode}

The advantages are that you can then manipulate the resulting tree to simplify the expression or avoid temporary evaluations. The previous expression could be simplified to hold the equivalent of \DD{x + y} (getting rid of the multiplication by one.

More generally, you can encode a programming language expression in such a tree:

\begin{dcode}
AST!"
if (x == 0) 
then 
{ 
    writeln(x);
} 
else 
{ 
    ++x;
    foo(x,y);
}"
=>
If(Comparison!("==", Symbol!"x", value(0)), // Condition
// then branch
   Block!( FunctionCall!("writeln", Symbol!"x") ),
// (optional) else branch
   Block!( Unary!("++", Symbol!"x"),
           FunctionCall!("foo", Symbol!"x", Symbol!"y")))
\end{dcode}

This way lies madness and the power of macros, because you can then manipulate the resulting Abstract Syntax Tree in any way you wish, rewrite the code it represents, convert it back into a string and write it into the file that will be given to the compiler. 

So,

\begin{enumerate}
\item Define a compile-time parser,
\item feed it (a reasonable part of) the D grammar,
\item define some new authorized constructs and the associated AST and the way this new constructs can be behind-the-scene assembled from existing part of the D language (aka, macros),
\item write code in your new D extension, your \emph{precious},
\item feed it with the macros to a program that will create the resulting AST, modifying it like you wish and reassemble it into \emph{bona fide} D code.
\item and will then feed it to the standard D compiler.
\end{enumerate}

And \emph{voila}, your own toy D extension. Or, you know, you could just bug Walter till he adds the syntax you want into the language.

\section{Statically-Checked Writeln}\label{staticallycheckedwriteln}

This is an example of verifying a limited (!) Domain-Specific Language (DSL) at compile-time in D. The goal is to take a format string for \stdanchor{stdio}{writef} or \stdanchor{stdio}{writefln} and to check the arguments' types before passing them to \DD{writef}(\DD{ln}).

For example, when writing:
\begin{dcode}
writefln("For sample #%d, the results are (%s, %f)", num, name, f);
\end{dcode}

We know that \DD{\%d} means the argument must be an integral type, \DD{\%f} asks for a floating-point type and so on. That means in the previous sample, we know that:

\begin{itemize}
\item There must exactly 3 args, no more, no less.
\item The first one must have an integral type.
\item The second one can be of any type (more exactly, of any type that can be converted into a \D{string}).
\item The third one must be of some floating point type.
\end{itemize}

These four conditions can be checked at compile-time, that's what we will do here. I won't code the entire POSIX specification for \DD{printf}, table \ref{table:formatters} shows what will be checked.

\begin{table}[htb]
\begin{tabular}[c]{cll}
\hline
\multicolumn{1}{c}{Formatter} & \multicolumn{1}{c}{Asks For} & \multicolumn{1}{c}{Equivalent Constraint} \\ 
\hline
\DD{\%d}, \DD{\%i} & an integral type & \DD{isIntegral} \\
\DD{\%u}, \DD{\%x}, \DD{\%X}, \DD{\%o} & an unsigned integral type & \DD{isUnsigned} \\
\DD{\%f}, \DD{\%F}, \DD{\%e}, \DD{\%E}, \DD{\%g}, \DD{\%G} & a floating point type & \DD{isFloatingPoint} \\
\DD{\%c} & a char type & \DD{isSomeChar} \\
\DD{\%s} & any type & \DD{isAnyType} \\
\DD{\%\%} & not a formatter, just the '\DD{\%}' char & no check \\
\hline\end{tabular}
\caption{Standard formatters recognized by \DD{cwritef}}
\label{table:formatters}
\end{table}

For those interested in the details, \href{http://en.wikipedia.org/wiki/Printf_format_string}{this Wikipedia article} makes for a nice reference. Note that not all formatters are implemented in \std{stdio}, for example the \DD{\%p} formatter for \D{void}\DD{*} pointers seems not to work.

Most of the previous typechecking templates are in \std{traits}: \DD{isIntegral}, \DD{isFloatingPoint}, \DD{isUnsigned} and \DD{isSomeChar} are already implented in Phobos. The only one left is \DD{isAnyType}, a quite complacent template:

\begin{dcode}
module isanytype;

template isAnyType(T)
{
    enum isAnyType = true;
}
\end{dcode}

The only way for it to fail would be to give it a non-type.

Continuing with the previous chapters' example-driven development, here is what I want to obtain (\DD{cwritefln} stands for checked-\DD{writefln}):

\label{usingcheckedwrite}
\begin{dcode}
module usingcheckedwrite;
import checkedwrite;

void main()
{
    cwritefln!"For sample #%d, the results are (%s, %f)"( 0, "foo", 3.14); // OK

 // NOK: bad number or args: waited for 3 args, got 2.
 // cwritefln!"For sample #%d, the results are (%s, %f)"( 0, "foo");

 // NOK: arg #3 of type double does not verify check isFloatingPoint
 // cwritefln!"For sample #%d, the results are (%s, %f)"( 0, 3.14, "foo");
}
\end{dcode}

Now, given a formatting string, the first thing is to extract the formatters and construct the constraints list. Here I'll use a string mixin and just need to build a string representing the desired final code:

\begin{dcode}
module getformatters;
import std.conv;
import std.traits;

string getFormatters(S)(S s) if (isSomeString!S)
{
    dstring ds = to!dstring(s);
    bool afterPercent = false;
    bool error;
    string result = "alias TypeTuple!(";
    foreach(elem; ds)
    {
        if (error) break;
        if (afterPercent)
        {
            switch (elem)
            {
                case '%':
                    afterPercent = false;
                    break;
                case 'd':
                case 'i':
                    result ~= "isIntegral,"; // integers
                    afterPercent = false;
                    break;
                case 'u':
                case 'x':
                case 'X':
                case 'o':
                    result ~= "isUnsigned,"; // unsigned integral
                    afterPercent = false;
                    break;
                case 'f':
                case 'F':
                case 'e':
                case 'E':
                case 'g':
                case 'G':
                    result ~= "isFloatingPoint,"; // floating point
                    afterPercent = false;
                    break;
                case 'c':
                    result ~= "isSomeChar,"; // char
                    afterPercent = false;
                    break;
                case 's':
                    result ~= "isAnyType,"; // any string-convertible type
                    afterPercent = false;
                    break;
                /* flags, width, */
                case '+':
                case '-':
                case '#':
                case '.':
                case ' ':
                case '0':
                    ..
                case '9':
                    break;
                default:
                    error = true; // Error!
                    break;
            }
        }
        else
        {
            if (elem == '%') afterPercent = true;
        }
    }
    
    // Get rid of the last comma:
    if (result.length > 17) result = result[0..$-1];
    // finishing the alias code
    result ~= ") ArgsChecks;"; 
    
    if (afterPercent // finished the string but still in "afterPercent" mode 
     || error) 
        result = "static assert(0, \"Bad format string: \" ~ a);";
    
    return result;
}
\end{dcode}

It's quite a long sample, but the logic behind it is straightforward: it iterates on all characters and looks for \DD{\%x} patterns. I included here a basic treatment for flags and such, but as I said earlier, this example does not deal with the entire POSIX specification: the goal is \emph{not} to validate the formatting string, but to extract the formatters. When it determines the string is malformed, the generated code will be a \D{static assert}.

So, at the end, we get ready-to-be-mixed-in strings, like these:

\begin{dcode}
"alias TypeTuple!() ArgsChecks;" // no formatter
"alias TypeTuple!(isIntegral,isAnyType,isFloatingType) ArgsChecks;" // the previous example
"static assert(0, \"Bad format string: %s and %z\");" // Bad string
\end{dcode}

Once the tuple of checks is done, we need a template that verifies each argument in turn with the corresponding template. To get a better error message, I use an \D{int} template parameter, to count the number of args checked.

\begin{ndcode}
module verifychecks;
import std.conv;
import std.traits;
import std.typetuple;
import isanytype;
import getformatters;

template ArgsChecks(alias a) if (isSomeString!(typeof(a)))
{
    mixin(getFormatters(a));
}

template VerifyChecks(int which, Checks...)
{
    template on(Args...)
    {
        static if (Checks.length != Args.length)
            static assert(0, "ctwrite bad number of args: waited for " ~ to!string(Checks.length) 
                           ~ " args, got " ~ to!string(Args.length) ~ ".");
        else static if (Checks.length == 0) // end of process
            enum on = true;
        else static if ({ alias Checks[0] C; return C!(Args[0]);}()) // recurse
            enum on = VerifyChecks!(which+1, Checks[1..$]).on!(Args[1..$]);
        else
            static assert(0, "cwrite bad arg: arg #" ~ to!string(which) 
                           ~ " of type " ~ Args[0].stringof 
                           ~ " does not verify check " ~ __traits(identifier, Checks[0]));
    }
}
\end{ndcode}

The \DD{Verify} template is another example of a double-decker template, as seen in section \ref{templatesintemplates}, to get a nice calling syntax:

\begin{dcode}
Verify!(0, isIntegral, isFloatingPoint).on!(int, double)
\end{dcode}

The most subtle part is on line 19: 

\begin{dcode}
else static if ({ alias Checks[0] C; return C!(Args[0]);}()) // recurse
\end{dcode}

We want to apply the first checking constraint, \DD{Check[0]}, on the first argument type, \DD{Args[0]}. Halas, the D grammar does not allow the following construct:

\begin{dcode}
else static if (Checks[0]!(Args[0])) // recurse
\end{dcode}

The standard way to do this would be:

\begin{dcode}
alias Checks[0] Check;
// and then
else static if (Check!(Args[0]))
\end{dcode}

But that would put a \DD{Check} symbol in the template local scope, therefore breaking the eponymous template trick. It'd be possible to define a \DD{VerifyImpl} template (see section \ref{impltrick} on page \pageref{impltrick}), but using a local delegate works as well:

\begin{dcode}
{ alias Checks[0] C; return C!(Args[0]);}()
\end{dcode}

The \DD{\{...\}} part defines the delegate and \DD{()} calls it, returning either \D{true} or \D{false}. This is then inserted inside the \D{static if}.\footnote{ Now that I think about it, that trick could be inserted in the Eponymous Templates section\ldots}

Anyway, once the checking code is done, the rest is easy:

\begin{dcode}
module checkedwrite;
import std.stdio;
import std.traits;
import verifychecks;

void cwritef(alias a, Args...)(Args args) 
if (isSomeString!(typeof(a))
 && VerifyChecks!(1, ArgsChecks!(a)).on!(Args))
{
    writef(a, args);
}

void cwritefln(alias a, Args...)(Args args)
if (isSomeString!(typeof(a))
 && VerifyChecks!(1, ArgsChecks!(a)).on!(Args))
{
    writefln(a, args);
}
\end{dcode}

Usage is then as shown in page \pageref{usingcheckedwrite}.

\section{Extending a Class}\label{extendingaclass}

There is regularly a wish in the D community for something called Universal Function Call Syntax (UFCS):\index{syntax!Universal Function Call Syntax}\index{UFCS} the automatic transformation of \DD{a.foo(b)} into \DD{foo(a,b)} when \DD{a} has no member called \DD{foo} and there \emph{is} a free function called \DD{foo} in the local scope\index{scope!local scope}. This already works for arrays\index{arrays!UFCS} (hence, for strings) but not for other types.

There is no way to get that in D for built-in types except by hacking the compiler, but for user-defined types, you can call templates to the rescue.

\DD{opDispatch} can be used to forward to an external free function. A call \D{this}\DD{.method(a,b)} becomes \DD{method(}\D{this}\DD{,a,b)}.

\begin{dcode}
module forwarder;

mixin template Forwarder()
{
    auto opDispatch(string name, Args...)(Args args)
    {
        mixin("return " ~ name ~ "(args);");
    }
}
\end{dcode}

In D, a void \D{return} clause is legal: 

\begin{dcode}
return;
// or return void;
\end{dcode}

So if \DD{name(}\D{this}\DD{,a,b)} is a \D{void}-returning function, all is OK.

The main limitation of this trick is that it doesn't work across modules boundaries. Too bad.

\section{Pattern Matching With Functions}

\unfinished{The idea is to group a bunch of templates together and use their pattern matching ability. Maybe to be put in \autoref{functiontemplates}?}

\section{Generating a Switch for Tuples}
Case 0:, etc.

Or more generally, the idea to craft specific runtime code given compile-time information.
See also \autoref{sortingnetworks}.