I’m one of those next-cool-thing addicts that can’t resist to play with the latest most unstable Whidbey CTP coming out of Redmond. One of the red-hot things is generics that will be included with C#^H^H the CLR v2.0. This intentional blunder is the central point of this editorial - clearing up misconceptions about generics.

When reading postings or talking to fellow early .NET 2.0 adopters you come to categorize those into the following distinct groups:

The C++ developers

The Non-C#, Non-VB.NET, Non-Managed C++ developer

The Java developer (yes, I know…)

Generics, huh?

Let’s start out with the die-hard C++ programmer, a guy who really is in love with the templating system in C++ (when referring to C++ I really mean the unmanaged C++ world). This is the most vocal among the four groups, and they’ll be very forthcoming in telling you how much better C++ templates are than generics in C#. I hate to break the news to them, but generics are intentionally different: firstly, and most importantly, C++ templates are compile time only, whereas generics are compile as well as runtime. Anders Hejlsberg did a great job of explaining that in [1], and the C# team has a FAQ online on this topic too [2].

Secondly, the being different goal also extends to simplicity of use. Do you remember yourself screaming bloody murder when C# came along with single inheritance? Right. How many people did and do care in real life? See. Same here in generics-land: certain power has been stripped from you because it would tip the balance from easy to use to intimidating and overly complicated. That’s why constraints don’t cover the whole complexity spectrum and don’t allow operator constraining and the like, such as non-default constructor constraints. Oh, you can fake operator constraints if you really, really care with the approach detailed in [1] and [3], but admittedly this won’t solve the problems for intrinsic types.

Speaking of operator constraints constraints (couldn’t resist), a general misconception in the C++ camp is that everything they are used to should be just as dangerous – pardon me, powerful – in other implementations. C++ templates allow you to do what you damn well please, but generics don’t – that very type checking is the one thing to single out that rid us of AVs, remember?

The Non-C#, Non-VB.NET, Non-Managed C++ developer. So who are they? Try one of 30+ (don’t quote me on the actual figure) other programming languages that follow the CLS (Common Language Specification) and produce code that can run on the CLR. It is rather similar if not exactly the same as with Edit and Continue support – “me too!” is heard all around the globe. So, do they get generics? Depends. Because of the many programming languages that exist for .NET, Microsoft decided to not put generics in the CLS. So it is entirely up to the language vendor in 2.0 to support generics or not.

Has the C#/VB.NET developer any beef with that? You bet. If you write a framework that has to be used in other programming languages, that framework has to be CLS compliant (“should be” is too soft in my view). And this means you cannot use generics on the public interfaces if you want to mark your assembly with the CLSCompliant attribute. The Non-CLS compliance of generics is pointed out in [4] and [5], with hints that generics will find their way into the Common Language Specification in the Orcas / Longhorn timeframe.

The Java developer. Now, how do they fit into the picture of the early adopter of .NET 2.0? I’m sure one thing .NET developers will hear a lot is that “Java had generics long before .NET.” Not so fast, Scotty. Just like there are differences between C++ templates and .NET generics, there are differences between Java generics and their counterparts in .NET. Once again, Anders Hejlsberg did a great job in [1] of explaining what is different: for one, .NET generics are actually typed, which means no boxing for value types (a very good thing!). Secondly, .NET generics are runtime too, not just compile time – you can reflect on generics in .NET, you can’t do that in Java. The lowdown: generics in Java spare you the task of casting, but that’s about it.

Finally, the group “Generics, huh?” Those are developers who for example still have the misconception that generics are a C#-only feature, like many programmers using 1.0 initially thought that features offered by the CLR were actually C# features. Let’s chalk that one up to miscommunication, but a repeated one.

You know that generics (will) exist, but have no clear idea what they are intended to be used for? I’d like to quote Anders Hejlsberg: “Generics is essentially the ability to have type parameters on your type.”[1] D’accord? Really simple but really powerful.

You know what generics are (if not, please see the previous paragraph), but have no idea what to use them for? If you are like one of my friends “I’m not in the business of writing frameworks, and the .NET framework already has generic collections, so what use are generics to me?”, rest assured that there are plenty of other non-class uses: generic methods (data access, anyone?) and generic delegates (in an instant makes callbacks that much more fun). Did you know about those two generics use cases?

To conclude this editorial, I’d like to firmly state that generics are positioned somewhere between being “just a fancy way of replacing typed collections” and the all-too-powerful for shooting yourself in the foot C++ templates. Well designed, tightly integrated in the CLR, the right dose of power – with one problem: too many different views of what generics are, what they are intended for, and what they can be used for. I for one am confident that they will be useful to programmers – yes, useful – nothing more, nothing less.

Bootnote: This blog entry originallly was intended to be an editoral, however, an editorial is an opinion piece, and the publisher wanted a different opinion. This is why the text is now in my blog where you can read (and flame) it freely.