Why do C# collection initializers work this way?

Your observation is spot on – in fact, it mirrors one made by Mads Torgersen, a Microsoft C# Language PM.

Mads made a post in October 2006 on this subject titled What Is a Collection? in which he wrote:

Admitted, we blew it in the first
version of the framework with
System.Collections.ICollection, which
is next to useless. But we fixed it up
pretty well when generics came along
in .NET framework 2.0:
System.Collections.Generic.ICollection<T>
lets you Add and Remove elements,
enumerate them, Count them and check
for membership.

Obviously from then on, everyone would
implement ICollection<T> every time
they make a collection, right? Not so.
Here is how we used LINQ to learn
about what collections really are, and
how that made us change our language
design in C# 3.0.

It turns out that there are only 14 implementations of ICollection<T> in the framework, but 189 classes that implement IEnumerable and have a public Add() method.

There’s a hidden benefit to this approach – if they had based it on the ICollection<T> interface, there would have been exactly one supported Add() method.

In contrast, the approach they did take means that the initializers for the collection just form sets of arguments for the Add() methods.

To illustrate, let’s extend your code slightly:

class Test : IEnumerable
{
    public IEnumerator GetEnumerator()
    {
        throw new NotImplementedException();
    }

    public void Add(int i) { }

    public void Add(int i, string s) { }
}

You can now write this:

class Program
{
    static void Main()
    {
        Test test 
            = new Test 
            {
                1, 
                { 2, "two" },
                3 
            };
    }
}

Leave a Comment