Is there any specific reason why indexing is not allowed in IEnumerable.
I found a workaround for the problem I had, but just curious to know why it does not allow i
The idea of interfaces is generally to expose a sort of base line contract by which code that performs work on an object can be guaranteed of certain functionality provided by that object. In the case of IEnumerable, that contract happens to be "you can access all of my elements one by one."
The kinds of methods that can be written based on this contract alone are many. See the Enumerable class for tons of examples.
But to zero in on just one concrete one: think about Sum. In order to sum up a bunch of items, what do you need? What contract would you require? The answer is quite simple: just a way to see every item, no more. Random access isn't necessary. Even a total count of all the items is not necessary.
To have added an indexer to the IEnumerable interface would have been detrimental in two ways:
IEnumerable interface, would be artificially restrictive as it could not deal with any type that did not implement an indexer, even though to deal with such a type should really be well within the capabilities of the code.LinkedList, Dictionary) would now have to either provide some inefficient means of simulating indexing, or else abandon the IEnumerable interface.All this being said, considering that the purpose of an interface is to provide a guarantee of the minimum required functionality in a given scenario, I really think that the IList interface is poorly designed. Or rather, the lack of an interface "between" IEnumerable