I always wonder about posts like this. It's obvious from the post your replying to that I fully understand why IEnumerable<T> doesn't have a Count property or provide random access. That kinda was the entire point of my post, don't ya think?
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.