dpratt71 said:
wkempf said:
*snip*
Interesting that you should bring up the concept of an IReadOnlyCollection from which ICollection would derive. This idea was really the starting point of the thought process of my original post in this thread. Basically, I asked myself what it was that I wanted IReadOnlyCollection to give me that I didn't get from IEnumerable+LINQ.

Your point about "complexity" is not without merit and is something that I had considered. On the other hand, unless you are referencing a sealed class, I don't think there are ever any guarantees about such things. To put it another way, I think it is the responsibility of the language to help us validate the correctness of our program, but it is entirely our responsibility to determine the fitness of tool "X" for task "Y". I haven't met a language yet that doesn't make it trivially easy to do something really stupid Wink

Hey, maybe we can get the Spec# folks to incorporate algorithmic complexity as a contract Wink
There are complexity guarantees documented on the various interfaces here.  Exposing an IEnumerable<T> means that a large number of operations consumers are going to want to perform are going to have O(N) complexity.  LINQ may "cheat" and give you better performance, but the complexity that consumers MUST assume is O(N).  Now, expose a ReadOnlyCollection<T>, and most of those same operations are now O(1).  A hypothetical IReadOnlyCollection would provide the same complexity guarantees you have with ReadOnlyCollection<T>, but without the existense of mutating methods, making for a "cleaner" design.  Again, though, in practice the current design is "good enough", and certainly preferable to IEnumerable<T>.