Immutable Collections Should Not Implement Mutable Interfaces

I just read the new blog post about .NETs new mutable collections. It mostly looks really nice, but there is a major problem: They implement mutable interfaces like IList<T> which has an Add() method.

The blog post states this:

Implementing the mutable interfaces

Several people raised the issue that our immutable collection types implement the mutable interfaces. For example, this is what the declaration of ImmutableList<t> looks like:

public sealed class ImmutableList<T> :
        IImmutableList<T>,
        IEnumerable,
        IEnumerable<T>,
        IReadOnlyCollection<T>,
        IReadOnlyList<T>,
        ICollection,
        ICollection<T>,
        IList,
        IList<T>
{
   ...
}

It’s worth pointing out that this declaration does not have a correctness issue – you cannot mutate an instance of ImmutableList<t> by casting it to a mutable interface. For example, calling IList<T>.Add would throw NotSupportedException<t>.

Now, why is that such a big issue?

Well. It’s not (in a strict sense). I thought so first. When I saw the throw NotSupportedException(); my internal alert system was blinking “LSP violation” in red and the siren was going all crazy.

But then I started to read more carefully about the interfaces in MSDN. The documentation for the Add() method state that NotSupportedException can be thrown if the collection is read only. It’s therefore not a Liskovs Substitution Principle violation.

You could argue that any interface containing an Add() method is incorrectly defined if that Add() method may not be used for all implementations. It would have been better with an interface like IReadOnlyList that exposes an item accessor.

public interface IReadOnlyList<T> : IEnumerable<T>
{
    T this[int index] { get; }
    int Count { get; }
}

public interface IList<T> : IReadOnlyList<T>
{
    T this[int index] { get; set;  }
    void Add(T item);
    void Remove(T item);
}

(I’m not satisfied with the naming as ‘is-a’ relationships also applies to interfaces, but you might understand what I’m going for.)

Ask yourself. If you got a list through a method like IList<User> GetUsers();, would you ever think that you may NOT use the Add/Remove methods? No, you wouldn’t as the defacto standard has been to expose those through the IEnumerable<T> interface. IEnumerable<T> isn't a good choice in all situations, but it's the best choice that .NET provides for read-only collections.

The implication of using the mutable interfaces for the immutable types is that our code would have to be something like this when we want to get a mutable collection:

public void ProcessUsers(IList<T> users)
{
    if (myList.IsReadOnly)
        throw new InvalidOperationException
        ("We require a proper list, one were the Add method works");

    // [...]
}

As of now, there is no interface that we can use to communicate that we need to work with mutable collections. And no, using concrete types is not an option. Understand? You force us to either start using our own collection interfaces or resort to runtime errors.

The only reason to the decision that I could find is the following:

However, we received the feedback that people had a hard time figuring out how to pass an immutable list to an existing method that took, for example, IList<t>.

Ask yourself WHY they used IList<T> when an immutable object is required. They could have simply used IEnumerable<T>. My best bet is that they required something that they can traverse multiple times or wanted to know the length of the list. As in such, the real solution would probably have been to create something like IReadOnlyList<T>.

Please .NET team, do not use the mutable interfaces, even if it’s technically valid to do so.