<p>This might be a old question: Why does <code>IEnumerable&lt;T&gt;</code> inherit from <code>IEnumerable</code>?</p>

<p>This is how .NET do, but it brings a little trouble. Every time I write a class implements <code>IEumerable&lt;T&gt;</code>, I have to write two <code>GetEnumerator()</code> functions, one for <code>IEnumerable&lt;T&gt;</code> and the other for <code>IEnumerable</code>.</p>

<p>And, <code>IList&lt;T&gt;</code> doesn't inherit from IList. </p>

<p>I don't know why <code>IEnumerable&lt;T&gt;</code> is designed in other way.</p>

The answer for
```
IEnumerable
```
is: "because it can without affecting type safety".
```
IEnumerable
```
is a "readonly" interface - so it doesn't matter that the generic form is more specific than the nongeneric form. You don't break anything by implementing both.
```
IEnumerator.Current
```
returns
```
object
```
, whereas
```
IEnumerator<T>.Current
```
returns
```
T
```
- that's okay, as you can always legitimately convert to
```
object
```
, although it may mean boxing.
Compare this with
```
IList<T>
```
and
```
IList
```
- you can call
```
Add(object)
```
on an
```
IList
```
, whereas that may well be invalid for any particular
```
IList<T>
```
(anything other than
```
IList<object>
```
in fact).
Brad Abram's
blogged with Anders' answer
about this very question.