One of the big justifications for generics I heard at the PDC was that generics make operations on primitive types much faster, because they eliminate boxing/unboxing overhead. Anders Hejilsberg did a demo comparing the relative performance of List<int> vs an ArrayList containing ints, and the generic was almost twice as fast.
However, it seems like generics are almost useless for doing more interesting things on primitive types (like combining them!). Take the following simple function:
public T Add<T> ( T t1, T t2 ){ return t1 + t2; }
This function will not compile. You get a compiler error that says something like “Cannot apply operator '+' to types T and T“.
This is a reasonable error. The Official Way Around this class of problems is to use type constraints to tell the compiler the set of operations that your generic expects its generic parameters to support. This works great when T is complex object -- presumably, you have the freedom to define an operational interface and constrain your generic in terms of that interface. However, this doesn't work with primitive types. How, using type constraints, am I supposed to express “the set of operations common to primitive numeric types“ when those primitive numeric types don't implement a common interface precisely because they are primitive?
I suppose you could solve this problem by boxing your primitive ints into objects that implement an operation interface, but this solution negates any potential performance gains that a generic solution would give you.
Why isn't there a formalization of the set of operations common to numeric types?
