It looks like a weird design choice, because a Dictionary and an ImmutableDictionary are quite different write-wise. (Read-wise, they both implement IReadOnlyDictionary, which is fine*)In fact, the current implementation of IDictionary<TKey, TValue>.Add() in the ImmutableDictionary class throws a NotSupportedException (see here).So, what was the point in doing this? If a method returns an IDictionary that is in fact an ImmutableDictionary, you're going to have some troubles when adding elements in it, for instance.*except for the name of the interface, which is subject to debate
Why is ImmutableDictionary implementing IDictionary?
c#;immutability
For the reasons why, take a read of the Interoperating with existing collections part of this MS blog post.The developers of these immutable types had a choice, which I'll express here in a succinct, but somewhat loaded, way:Make them easy to useDo it properlyOriginally, they went down the do it properly route. The IList<T> interface is a classic example of how to break the Liskov substitution principle as it positively encourages creating types that are not substitutable for each other (without checking the state of flags to determine which particular style of implementation one is handling). However, this meant they didn't interoperate nicely with existing code, nor could useful interfaces like IList<T> be used with them. So they took the decision to favour usefulness over purity. It remains a controversial decision, but was probably the correct - pragmatic - one to take.