0

The question about why IList<T> doesn't inherit from IList was asked before and answered.

The correct answer I believe was that if IList<T> did inherit from IList, then one could cast to IList and add items not of the correct type.

Here now comes my question.

Why does List<T> implement both IList<T> and IList then? If you cast List<T> to IList and add items not of type T you correctly get an exception.

So what's the purpose of List<T> implementing IList?

Simo Ferrari
  • 87
  • 1
  • 6
  • 2
    methinks for backward compatibility – Grundy Jul 16 '15 at 14:20
  • 1
    "was asked before" -> link!!! – O. R. Mapper Jul 16 '15 at 14:20
  • 1
    possible duplicate of [Why generic IList<> does not inherit non-generic IList](http://stackoverflow.com/questions/14559070/why-generic-ilist-does-not-inherit-non-generic-ilist) – Ian Jul 16 '15 at 14:22
  • 1
    @Ian: It's not quite a duplicate, as it does not highlight the fact that `List` indeed *does* implement `IList`. – O. R. Mapper Jul 16 '15 at 14:25
  • Because its a concrete implementation thats implemented in away to prevents doing something dump. How do you make sure that any IList implementor does it when it would inherit from IList? – Ralf Jul 16 '15 at 14:32
  • @O.R.Mapper: Ok - you said it was asked before, could you find another more relevant duplicate? – Ian Jul 16 '15 at 14:36
  • @Ralf: To be fair, you cannot make sure that `IList` implementors do not do anything weird when implementing the interface as it is, either. – O. R. Mapper Jul 16 '15 at 14:49
  • @Ian: I did not. The OP said that, I *cited* their statement, and *I* asked *them* for a reference to one of the questions that discussed the issue, but did not provide enough information for the specific aspect the OP is asking about. – O. R. Mapper Jul 16 '15 at 14:49
  • @O.R.Mapper: Sorry, my mistake :) – Ian Jul 16 '15 at 14:50
  • @Ian: Granted, I "asked" in a very brief form. Sorry for the confusion ;) – O. R. Mapper Jul 16 '15 at 14:50
  • @O.R.Mapper No worries – Ian Jul 16 '15 at 14:51

1 Answers1

4

then one could cast to IList and add items not of the correct type.

This is only a partial justification: It is well possible to implement IList in a way so no items of an incorrect type can be added - as evidenced by the implementation that is List<T>.

However,, List<T> already exists as a part of the base class library. For our convenience, it implements IList and throws exceptions. If we want to use its IList implementation, we can do so within these constraints, and if we do not want to use it, we have no further work.

In contrast to this, IList<T> is an interface. If it inherited from IList, every implementor of IList<T> would have to implement all of the weakly-typed methods of IList, adding a lot of work that is often not desired.

Moreover, note that List<T> implements IList expilcitly. That means, the public interface of List<T> does not grow; you only get the IList methods if you explicitly cast to IList. In an interface, that is not possible, as an interface cannot enforce explicit implementation of another interface.

O. R. Mapper
  • 20,083
  • 9
  • 69
  • 114
  • Thank you for the in depth info. I can see the convenience of casting to an IList and using the methods in it that don't involve the specific type. However the code that may working against the IList interface may not know about the actual concrete implementation and assume all the methods would work. I completely agree with you explanation and I guess we should write code that prevents such a situation. – Simo Ferrari Jul 16 '15 at 20:31