Why doesn't IDictionary<T, U> implement IReadOnlyDictionary<T, U>?

[IrvingDecarlo]

I've been wondering this for quite a while... why doesn't the IDictionary<T, U> interface inherit from IReadOnlyDictionary<T, U>?

All of IReadOnlyDictionary<>'s properties and methods already exist in IDictionary<>, therefore, IDictionary<> could inherit from IReadOnlyDictionary<> without any complications. However, it doesn't... why is that?

Time and again I stumble upon a problem when creating extension methods for IReadOnlyDictionaries, since, using this snippet as an example:

public static U GetValue<T, U>(this IReadOnlyDictionary<T, U> dict, T key) => dict[key];

void Test()
{
    Dictionary<int, int> dict = new Dictionary<int, int>();
    IDictionary<int, int> idict = dict;
    dict.Add(1, 10);
    int value = dict[1]; // Compiles normally as the Dictionary class has a getter, naturally.
    value = idict[1]; // Also compiles, as IDictionary<> has a getter too.
    value = dict.GetValue(1); // Compiles normally, as the Dictionary class implements both IDictionary<> and IReadOnlyDictionary<>.
    value = idict.GetValue(1); // Won't compile since IDictionary<> does not implement IReadOnlyDictionary<>, while having all its properties and methods.
}

The value = idict.GetValue(1); won't compile since IDictionary<> doesn't inherit from IReadOnlyDictionary<>, while having all its properties and methods. The obvious work around that would be to create a duplicate extension method extending IDictionary<>, which would work at first, but then there'd be another issue:

public static U GetValue<T, U>(this IReadOnlyDictionary<T, U> dict, T key) => dict[key];
public static U GetValue<T, U>(this IDictionary<T, U> dict, T key) => dict[key];

void Test()
{
    Dictionary<int, int> dict = new Dictionary<int, int>();
    IDictionary<int, int> idict = dict;
    dict.Add(1, 10);
    int value = dict[1]; // Compiles normally as the Dictionary class has a getter, naturally.
    value = idict[1]; // Also compiles, as IDictionary<> has a getter too.
    value = dict.GetValue(1); // Will not compile as the call is ambiguous, since the Dictionary class implements both IDictionary<> and IReadOnlyDictionary.
    value = idict.GetValue(1); // Now it compiles, as there is an extension method just for the IDictionary<>.
}

You can see that now the Dictionary class cannot be extended by these methods, since their call is ambiguous. So, in order to make it work, the extension method would have to accept a generic object type which has to implement both IDictionary<> and IReadOnlyDictionary<>, which is represented here:

public static U GetValue<T, U, V>(this V dict, T key) where V : IDictionary<T, U>, IReadOnlyDictionary<T, U> => dict[key];
// Will not compile since the call to dict[] is ambiguous between IDictionary<> and IReadOnlyDictionary<>, since they have the very same property.

void Test()
{
    Dictionary<int, int> dict = new Dictionary<int, int>();
    IDictionary<int, int> idict = dict;
    dict.Add(1, 10);
    int value = dict[1]; // Compiles normally as the Dictionary class has a getter, naturally.
    value = idict[1]; // Also compiles, as IDictionary<> has a getter too.
    value = dict.GetValue<int, int, Dictionary<int, int>>(1); // Compiles.
    value = dict.GetValue<int, int, Dictionary<int, int>>(1); // Also compiles.
}

Despite everything, it still will not work as now the ambiguity has fallen to dict[], since both IDictionary<> and IReadOnlyDictionary<> have the property. So, in order to make this work fully, the following has to be done:

public static U GetValue<T, U, V>(this V dict, T key) where V : IDictionary<T, U>, IReadOnlyDictionary<T, U> 
    => ((IReadOnlyDictionary<T, U>)dict)[key];
// Compiles as the dictionary is casted to one of the two types. IReadOnlyDictionary was chosen for this example.

void Test()
{
    Dictionary<int, int> dict = new Dictionary<int, int>();
    IDictionary<int, int> idict = dict;
    dict.Add(1, 10);
    int value = dict[1]; // Compiles normally as the Dictionary class has a getter, naturally.
    value = idict[1]; // Also compiles, as IDictionary<> has a getter too.
    value = dict.GetValue<int, int, Dictionary<int, int>>(1); // Compiles.
    value = dict.GetValue<int, int, Dictionary<int, int>>(1); // Also compiles.
}

This will compile and work, but look at all the workaround that had to be done just because IDictionary<> does not inherit from IReadOnlyDictionary<>. A cast had to be used, grotesque calls to the extension method were made... all this because IReadOnlyDictionary<> isn't implemented by IDictionary<>.

I would understand if IDictionary<> was used only as a setter, while IReadOnlyDictionary<> was the getter. Everything would then be justified, as the derived class would have to implement either or both, depending on its goal. But that's not the case, as the IReadOnlyDictionary<> interface has only methods read-only methods and properties, while IDictionary<> has for both cases.

This even doesn't make much sense when building the interface itself. As it currently stands, the IDictionary<> and IReadOnlyDictionary<> interfaces are basically the following:

public interface IDictionary<T, U> : ICollection<KeyValuePair<T, U>>
{
    U this[T key] { get; set; }

    void Add(T key, U value);

    bool ContainsKey(T key);
}

public interface IReadOnlyDictionary<T, U> : IReadOnlyCollection<KeyValuePair<T, U>>
{
    U this[T key] { get; }

    bool ContainsKey(T key);
}

Witness how the IDictionary<> and IReadOnlyDictionary<> interfaces have redundant methods and properties. Why not just do this:

public interface IDictionary<T, U> : ICollection<KeyValuePair<T, U>>, IReadOnlyDictionary<T, U>
{
    new U this[T key] { get; set; }

    void Add(T key, U value);
}

public interface IReadOnlyDictionary<T, U> : IReadOnlyCollection<KeyValuePair<T, U>>
{
    U this[T key] { get; }

    bool ContainsKey(T key);
}

See how the ContainsKey method was absorbed into IDictionary<>. Sure, the new had to be used in the this[]'s case, but that could happen in any derived class that wished to add a new implementation to an already existing non-virtual method. Therefore, I see it as a less significant "issue" (if we can even call it that) than that of having interfaces with redundant implementations.

You could also mention that the IDictionary<> interface implements ICollection<>, while IReadOnlyDictionary<> implements IReadOnlyCollection<>. I would then ask the same question I've asked, but regarding ICollection<>'s case instead. ICollection<> does everything that IReadOnlyCollection<> does and more, why not just make it implement it too?

[Clockwork-Muse]

Duplicate (although specific) of #31001

[huoyaoyuan]

Answer in short: because it is a binary breaking change.

Although having the same signature, the members like IReadOnlyCollection<T>.Count and ICollection<T>.Count are different members in binary. A class can implement them in different ways. The non-readonly versions came first and we can't modify them.

[IrvingDecarlo]

Not sure if I understand... if ICollection<T> implemented IReadOnlyCollection<T> then its .Count property could be removed, as it would inherit IReadOnlyCollection<T>.Count. Therefore, only a single implementation of it would exist, while ICollection<T> would remain practically untouched.

Time and again I split my interfaces in such style. Let's say for instance that I have an IFile interface with the following components:

interface IFile
{
    string Path { get; set; }

    string ReadFile();

    void WriteFile(string text);
}

Then I realize that I'd often have to work with read-only and, because of that, I'd have to make a new interface. Since the IFile and the proposed IReadOnlyFile interfaces would have many common components, I then decide to do the following:

interface IFile : IReadOnlyFile
{
    void WriteFile(string text);
}

interface IReadOnlyFile
{
    string Path { get; set; }

    string ReadFile();
}

Classes that would implement IFile wouldn't break, since it would still have the very same components. It's a modification that wouldn't change anything for such classes in practice, as the IFile interface would still be the thing it was before, but with some of its members defined by another interface that is implemented by it.

I understand that such a change could potentially break projects now as conflicts could indeed happen. But why wasn't such a modification made when the read-only interfaces were introduced?

Also, please let me know if I'm overlooking something rather obvious. I know this isn't the first time such a question is asked and, if it was something that could easily be fixed, then I'm sure that it would've already been fixed.

[Clockwork-Muse]

Classes that would implement IFile wouldn't break, since it would still have the very same components.

This is only true if you recompile from source. For all packages involved (think nuget dependencies). This is what the other issue is talking about when they refer to "binary compatibility". So if your code was recompiled to use this change, but you were using packages that hadn't, things would explode.

I understand that such a change could potentially break projects now as conflicts could indeed happen. But why wasn't such a modification made when the read-only interfaces were introduced?

Because there would have been issues with doing it when the interfaces were introduced, too.

if it was something that could easily be fixed, then I'm sure that it would've already been fixed.

Part of the problem here is that nothing's actually broken, risks involved are somewhat high, and there hasn't been a huge call to do this yet. And that aside, you still have to get somebody interested enough to make the change, on top of whatever more pressing issues they have to deal with.

[IrvingDecarlo]

Ah, I see. Now I understand. It seemed something so trivial, but now I realize the problems that would come along with it. Thank you for clarifying this to me, this question puzzled me for months!