You're reading too much into the "reply to" box from C9. I was just commenting on the whole thread, not just replying to you.
My point about why Count isn't there was a response to TommyCarlier who explictly lamented the fact that it's not there by default on an IEnumerable<T>.
The optimisation you mention of casting to an ICollection<T> is fine, because it first checks that the cast is valid, and ensures that if the cast is valid that it doesn't mutate the collection - my point was more general and related to CannotResolveSymbol's
post who noted that exposing IEnumerable<T> isn't a guarrantee that the inner property won't be mutated by the caller.
You say that noone was suggesting you wrap the collection in a ReadOnlyCollection, but W3bbo's code example does exactly that, so your point is invalid.
Please don't take the C9 "reply to" as nessisarrilly a refutation of what you said. I just clicked on the reply closest to the bottom of the screen, and I meant nothing by it.
Edit: I note actually that the order complexity of ReadOnlyCollection isn't O(_val.Count), but actually a minor overhead, since the ReadOnlyCollection defers all of the accesses of the list to the contained list and throws an exception on all mutation
attempts, so it's not quite as bad as I made it sound.
I wouldn't have made the connection to TommyCarlier's post, because he only talks about Count, while you talk about both Count and random access. It's also interesting to note, that thanks to LINQ, IEnumerable<T> now has both of the features you say
were deliberately left out. Yes, I understand the difference between the two designs, but you're glossing over the reasoning here.
W3bbo's code example didn't do what you did. He didn't wrap the collection in a ROC just to expose it to the user as an IEnumerable<T>. What he did was the most appropriate way to expose a collection that's supposed to be read-only. He wrapped it in a ROC
and exposed a ROC. There are reasons to expose an IEnumerable<T>, as you pointed out with several examples like the file enumerator. However, exposing a read-only collection isn't a reason for making it an IEnumerable<T>.