Togaroga

C# is well known for its nominative type system. This means that C# identifies types and their relationships based on their names. That is why C# does not allow you to create two types with the same name, even if they have a different public interface – the C# compiler only cares about the name of the type.

There is another type system called a structural type system. A structural type system recognizes the relationships between types based on the structure (i.e. the public members) of those types – names do not come into consideration. For example, if C# had a structural type system, these two classes would be considered compatible:

class Foo
{
    public String Name { get; set; }
}
class Bar
{
    public String Name { get; set; }
}

Because both of these types are declared with a String property called Name, a structural type system would happily work with both of these types as if only one type were declared. This means that instances of Foo could be assigned to a reference typed as Bar and instances of Bar could be passed to methods expecting a argument of type Foo. (This is similar to duck typing except that duck typing binds member calls at execution time whereas a structural type system does static type checking at compile time.)

Many developers do not realize that C# already supports structural typing in certain scenarios (most of them are well-concealed to reduce confusion). Here is the most common place where C# employs structural typing concepts:

foreach (Object o in someCollection) { }

Did you know that when the C# compiler encounters a foreach in your code it uses a structural approach to determine whether or not what you are enumerating a valid collection?

Consider this example:

class Foo { }

class Example
{
    static void Main()
    {
        Foo foo = new Foo();
        foreach (var f in foo) { }
    }
}

This code does not compile, but fortunately the compiler’s error message gives us some indication of how to fix the problem:

foreach statement cannot operate on variables of type ‘Foo’ because ‘Foo’ does not contain a public definition for ‘GetEnumerator’

Notice that the compiler doesn’t say that we ought to implement IEnumerable – rather it tells us that our Foo class doesn’t provide a GetEnumerator method. This is because the compiler is only concerned about the structure of Foo, not it’s nominative relationships to an interface that would ensure that the GetEnumerator method was present.

Let’s fix the error by adding a GetEnumerator method to Foo like the compiler requested:

using System.Collections;

class Foo
{
    public IEnumerator GetEnumerator()
    {
        return null;
    }
}
class Example
{
    static void Main()
    {
        Foo foo = new Foo();
        foreach (var f in foo) { }
    }
}

Interestingly enough, this does compile – structural typing at work!

Here is another example of C#’s existing support for structural typing:

var list = new List<String> {
    "hello", "world"
};

When the C# compiler encounters a collection initializer like this one, it uses a structural approach to determine if the type that is being initialized is actually a collection. Rather than using a nominative approach and checking to see if the type implements ICollection<T>, the compiler actually only checks to see if the type implements IEnumerable<T> (a nominative type check) and if the type exposes a public Add method. It is this last check for Add that is structural in nature since the compiler is checking for the presence of a method, not a nominative relationship on the type itself.

The purpose of this article was to show two areas where C# supports structural typing. I would be interested in discussing any other hidden areas of C# that are structural in nature – are you familiar with any that I didn’t cover?

Stay tuned for a follow-up article discussing two structural features I would like to see implemented in C# 5.

Edit: Here is the follow up article: Two structural additions to C#.