Oh, and after reading the entire post, you've missed several things here in any event.
The only one who talked about casting the IEnumerable<T> was myself. Go read what I said carefully. I said that LINQ was doing the cast as an optimization. LINQ casts to an ICollection<T>, not to a List<T>. This cast is safe and not dodgy. What's dodgy
is relying on the computational complexity of an IEnumerable<T> exposed by someone like the original poster, when calling such LINQ methods as Count() and ElementAt(). When using LINQ you must expect the worst case scenario, because you're dealing with an
IEnumerable<T>. It's just a happy bonus when it performs better. That's why you shouldn't return an IEnumerable<T> just because you want a "read only" collection.No one
was suggesting you should wrap the collection in a ReadOnlyCollection that was returned to the user as an IEnumerable<T>. Where you got that nonsense is beyond me.
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.