Ben, the "drop-in" requirement is that you get strong typing without changing your code. You just write Current, swap your ArrayList for the template, and recompile. Now Current will produce the correct type automatically.
This is very important for value types. When you do a foreach loop over a value type collection, the compiler auto-generates Current accesses which are then typecast to the desired element type if necessary. In your proposed implementation, Current would return an Object. That means the value type would be boxed, then unboxed again. That's extremely expensive if you don't do much else in the loop.
In the released implementation, Current already returns the unboxed value type instance, straight from the backer array. So no boxing or unboxing occurs, and element access is much faster. There's no way around this issue, either, since the code generated for a foreach statement is built into the C# language.
As for casting I<T>Enumerator instances to IEnumerator, I'm confused. Why would you ever want to do this? All cases that I can think of are covered by the IEnumerator.GetEnumerator method.
As for collections that hold derived classes but should be interpreted as collections of base classes, I'm afraid I don't understand that either. When you have a Cricketer collection, you can use a Player reference to store Cricketer instances returned from collection members, as usual and without a type cast. Storing Player instances in this collection cannot be possible because Cricketer, being a derived class, may have extra data fields. You cannot auto-generate a derived type from a base type, you'd have to use specific conversion methods or the like.
Post Edited (Chris Nahr) : 11/25/2004 8:20:45 AM GMT