So the invention of lists made IEnumerable classes useless and waste of time?

Question

So with the introduction of lists we can easily do, what we used to do with IEnumerable classes. So now IEnumerable classes mostly used only to understand how internally the lists work. Am i right?

Answer 1

No. While a list is enumerable, the reverse is not quite true.

IEnumerable as an interface states that you can iterate over a series of elements, whereas IList states that the element's order is preserved and you can randomly access them [in an efficient fashion – in .NET]. Although both of these revolve around a collection-ish data structure, the promises the interfaces make are different. That said, many types offer both and therefore implement both interfaces (List<T>, T[], ...).

Think of a data reader or a function computing a series of values (Fibonacci, prime numbers, ...), sets or trees for instance. None of there are lists, yet you can iterate over them using a method that takes an IEnumerable rather than and IList as a parameter.

Despite not strictly matching the tags, it may be worth mentioning that the interface semantics are slightly different in Java. The List interface does not specifiy random access. The Iterable interface though, which is the counterpart of IEnumerable, is similar.

Answer 2

I would suggest that interfaces like IEnumerable, ICollection and IList (in generic and non-generic forms, though ICollection and ICollection<T> have little relation to each other) are best thought of ways by which objects can allow themselves to be used by code which is designed to do various things with sequences of items (which may be countable or addressable by index). Code which simply wants to create a counted ordered sequence of items which is addressable by index can simply use List<T>, and can use that type whether or not it needs something which is counted and addressable by index, but an object which wants to make itself usable by code expecting a sequence of items can implement one of the above interfaces directly, rather than having to copy its contents to a new List<T> every time anybody wants enumerate them.

Note that one major advantage of IEnumerable<T> is that types which implement it do not have to hold the "entire contents" in memory, and can instead generate elements "on the fly". If one has a method that does something with all the items in an IEnumerable<T>, and one wants to perform that action on every item in a 1,000,000-item list where Fnord is greater than 23 (which is true of 95% of the items), having the method accept IEnumerable<T> will avoid any need to create a 950,000-item list containing all the items where Fnord is greater than 23.