Normally, when developers write code, they use placeholders that will eventually contain values and manipulate those values in particular ways; we call those placeholders "variables" and, if those variables are part of a class instance, "fields." Generics, also known as parametric types, provide the ability for developers to write code using placeholders for the types of those variables or fields. Generics allow the compiler to continue to exercise full static type-checking, yet write classes that can be used with a variety of different types, all statically checked at compile-time.

In languages like C# and Visual Basic, writing genericized code for anything but the simplest of cases becomes frustrating and difficult, because those languages require explicit type descriptors that must be used anywhere a type is used. For example, a generic "queue" class, a first-in-first-out (FIFO) data structure that maintains an order of items pushed into it, would look something like this in C#:

public class Queue<T>
{
    public void Clear();
    public bool Contains(T t);
    public int Count { get; }
    public T Dequeue();
    public void Enqueue(T o);
    public T Peek();
}

Its cousin written in Visual Basic would look not much simpler, but with different punctuation marks:

Class Queue(Of T)
    Public Overridable Sub Clear()
    Public Overridable Function Contains(t As T) As Boolean
    Public Overridable ReadOnly Property Count As Integer
    Public Overridable Function Dequeue() As T
    Public Overridable Sub Enqueue(t As T)
    Public Overridable Function Peek() As T
End Class

Later, the developer may want to take that Queue and put a bunch of Person objects into it, which, because the Queue is instantiated with a Person type at its construction, means the compiler can ensure that only Person objects are put into the Queue. Any attempt to put a non-Person object into that Queue will fail at compile-time and thus prevent a bug from occurring.

Queue<Person> line = new Queue<Person>();
Line.Enqueue(new String("Will this fail?"));

For most C# and VB developers, the story around generics more or less ends here: Parameterized types provide type-safe collections, and beyond that, they get awkward and hard to use and thus rarely show up. For example, any attempt to put a Student (which derives from Person) into a Person-only Queue would work, but attempts to pass a Queue of Students where a Queue of Persons was expected would not, driving O-O developers mad.

Parameterized types have had a long, rich history in functional programming languages, and, thanks to type inference, often far exceed the O-O community in their usage. Because the compiler can infer generic types in some cases, sometimes the only thing to say about parameterized types is that they're there, and the developer need not worry about it beyond that.

But in many cases, F# code will want or need to make the parameterization more explicit, and the F# language provides some simple rules to do so.

type Stack<'T>() =
    let mutable data = []
    member this.Push(elem : 'T) =
        data <- elem :: data
    member this.Pop() =
        let temp = data.Head
        data <- data.Tail
        temp
    member this.Length() =
        data.Length
                                                          

type Stack<'a>() =
    let mutable data = []
    member this.Push(elem : 'a) =
        data <- elem :: data
    member this.Pop() =
        let temp = data.Head
        data <- data.Tail
        temp
    member this.Length() =
        data.Length

type TwoArgGeneric<'a, 'b>(a : 'a, b : 'b) =
    let vA = a
    let vB = b
    override tag.ToString() =
        System.String.Format("TwoArgGeneric({0},{1})", a, b)

let s1 = new Stack<System.String>()

type Reflector<'a>() =
    member r.GetMembers() =
        let ty = typeof<'a>
        ty.GetMembers()

type Reflector2() =
    static member GetMembers<'a>() =
        typeof<'a>.GetMembers()

let stringMembers = Reflector2.GetMembers<System.String>()

One thing the compiler has to be careful about is making promises it can't keep. For example, in the following code (which will not compile), the compiler can't be sure that this will work:

type InterestingType<'a>(data : 'a) =
    member it.DoIt() =
        data.DoSomething()

Specifically, because DoSomething() isn't a method that is guaranteed to appear on whatever type happens to be passed in for 'a when the InterestingType instance is created, the compiler can't be certain that the call will work. As a result, it fails to compile this code, complaining that "Lookup on Object of Indeterminate Type Based on Information Prior to This Program Point."

Several solutions present themselves. One is to eliminate the generic entirely and use traditional O-O techniques to handle this, by creating an interface that declares the DoSomething method, and force any types that are passed in to the InterestingType constructor to be instances of that interface:

[<Interface>]
type IDoSomething =
    abstract DoSomething : unit -> unit

type OOInterestingType(data : IDoSomething) =
    member it.DoIt() =
        data.DoSomething()

Doing this has some drawbacks, however, stemming from the fact that the type isn't known at compile-time — only a part of the type is known (it inherits from the IDoSomething interface). Although this is sufficient in this simple demo, it won't always do.

The second approach is to use a type constraint, which is a declaration, enforceable by the compiler, that must be met when used:

[<Interface>]
type IDoSomething =
    abstract DoSomething : unit -> unit

type InterestingType<'a when 'a :> IDoSomething>(data : 'a) =
    member it.DoIt() =
        data.DoSomething()

The when clause in the type parameter declaration tells the compiler that whatever type is passed in for this parameter must meet the requirement, which in this case, given the :> syntax, means that the 'a type must inherit from the named type (IDoSomething).

The following sections explore the many other kinds of type constraints that are enforced by the F# compiler.

type MustBeEquallable<'a when 'a : equality>(data : 'a) =
    member it.Equal(other : 'a) =
        data = other

type MustBeComparable<'a when 'a : comparison>(data : 'a) =
    member it.Greater(other : 'a) =
        data > other
    member it.Lesser(other : 'a) =
        data < other

type MustBeNullable<'a when 'a : null>(data : 'a) =
    class
    end

type MustBeConstructible<'a when 'a : (new : unit -> 'a)> =
    member it.NewIt() =
        new 'a()

type MustBeStruct<'a when 'a : struct>() =
    class
    end
type MustBeClass<'a when 'a : not struct>() =
    class
    end

In certain cases, the F# compiler can eliminate the generic type parameter entirely and simply replace the type parameter with the actual type at compile time. These kinds of type parameters are indicated with the caret symbol (^) instead of the single-quote character when declaring the type parameter, and they are most commonly used with the type constraints listed in the previous section. In particular, they are used frequently within the F# library and for that reason should at least be readable by F# developers.

As the name implies, the major difference between statically resolved type parameters and "regular" type parameters is that statically resolved type parameters are replaced at compile time (much as C++ template parameters are), rather than used at runtime to instantiate the generic type, as "classic" .NET generics are. As a result, there are a few differences between "regular" generics and statically resolved type parameter generics.

For starters, statically resolved type parameters cannot be used on types — only methods and functions (described in Part III, "Functional Programming") can have statically resolved type parameters. So, for example, it is possible to write a generic function that does some odd or highly specialized math:

let inline (+@) (x : ^a) (y : ^a) =
    x + x * y

let result = 1 +@ 2
System.Console.WriteLine("result = {0}", result)

In addition, as the preceding example demonstrates, statically resolved type parameters can be used on inline functions, where "regular" generic parameters cannot. (Functions and inline functions are described more in Chapter 13.)

Because statically resolved type parameters are compile-time resolved, they allow for an additional generic constraint type.

type MustBeDoItable<'a when 'a : (member DoIt : unit -> unit)>() =
    class
    end

F#'s support for parameterized types is rich and powerful, particularly when combined with constraints and statically resolved type parameters, and makes writing reusable code just that much more powerful. But just writing reusable code is only part of the reusability story; the code must be packaged into a form that promotes reusability and reduces name conflicts, which is the subject of the next chapter.