c# - Why doesn't `IList<T>` inherit from `IReadOnlyList<T>`?

Question

When IReadOnlyList<T> was introduced in .NET 4.5, for a moment I thought the missing part of the puzzle was finally inserted in place: a way to pass a true readonly indexable interface where previously I would have to use my own read-only interfaces and create wrapper classes around everything.

I was expecting the interface to be placed inside the "natural" hierarchy, which would ideally be:

IEnumerable<T> 
.GetEnumerator()
      -> IReadOnlyCollection<T> : IEnumerable<T>
      .Count
            -> IReadOnlyList<T> : IReadOnlyCollection<T>
            .Item[...]
                     -> IList<T> : IReadOnlyList<T>
                     .Add(...)
                     .Clear()
                     .Contains(...)
                     (etc)

But, as it turns out, IList<T> doesn't inherit from IReadOnlyList<T>.

Is there a reason for this?

Some clarification:

Note that IReadOnlyList<T> is merely a contract which states that the list provides a way to get the list count and read the value at a certain index. It's poorly-named, because it doesn't enforce that the actual implementation is readonly.

A List<T> implements IEnumerable<T>, an IList<T> inherits from IEnumerable<T>, but this doesn't mean that these classes can only be enumerated.

So, if you want to pass a list to a method, and only allow it to be indexed (read), but not modified, you need to wrap it in a new instance. At the same time, you can pass it to a method which accepts IEnumerable<T> or IList<T> without having to wrap it. This is what I find to be broken.

I also believe the proper name should had been something like ICountable for IReadOnlyCollection and IIndexable for the IReadOnlyList:

IEnumerable<T> 
.GetEnumerator()
      -> ICountable<T> : IEnumerable<T>
      .Count
            -> IIndexable<T> : ICountable<T>
            .Item[...]
                     -> IList<T> : IIndexable<T>
                     .Add(...)
                     .Clear()
                     .Contains(...)
                     (etc)

Answer 1

@w.b put a link to New interfaces IReadOnlyList and IReadOnlyDictionary in the comments that contains an answer:

Why did we not change the existing interfaces to extend the read-only interfaces?

It looks like a reasonable assumption that it works because the read-only interfaces are purely a subset of the read-write interfaces. Unfortunately, it is incompatible because at the metadata level every method on every interface has its own slot (which makes explicit interface implementations work).

---

Immo Landwerth | .NET Framework Team (BCL) | http://blogs.msdn.com/b/bclteam/

To explain this a bit more clearly:

Suppose that a program written for .NET 4.0 contains a class MyList<T> that implements IList<T>. It clearly cannot implement IReadOnlyList<T> as that interface doesn't exist.

Now suppose the system administrator installs .NET 4.5 and suppose that .NET 4.5 made IList<T> implement IReadOnlyList<T>.

If the program would then be loaded, the runtime would detect that MyList<T> claims to implement IList<T>, but doesn't actually implement all the methods: it doesn't implement IReadOnlyList<T>'s methods. The program would no longer work.

The C# compiler might be able to match the methods by name, but the runtime doesn't do this. Since .NET 4.5 was supposed to have backwards binary compatibility, interfaces couldn't be extended to implement other interfaces, not even if those other interfaces contain a strict subset of the required methods.