Generics and CLS Compliance

Dan Fernandez blogs a reminder that generics are not CLS compliant in the .NET Framework 2.0. Apparently to make them so would put too large an onus on CLS language developers. This news worried me back when I first heard it, and it still worries me. It worries me on two fronts. As a component developer, it forces me to make some decisions when designing my APIs. Let's say I have an API that could take advantage of generics to make it more extensible or elegant. So do I

• Go whole hog and use generics, knowing that I'm preventing COBOL.NET or whatever languages don't support generics from calling the API. Given the fact that C#, VB.NET, C++ and J# probably represents 98% of the .NET code being written, maybe thats just fine. Of course, the moment I do this I'm virtually guaranteed to have some huge client will insist on support for Scheme.NET (or whatever).
  
• Don't use generics, knowing that the API will be compatible with the greatest number of languages. In this case, generics do me and my customers no good.
  
• Provide dual APIs or alternate methods, one using generics, the other not. Yucko. Anybody remember the days of Powerbuilder's half-assed COM support? Our COM APIs are still littered with hacks that provide alternate versions of methods to support partially compliant programming environments. I'd rather not go there again.

Frankly, none of these options are all that appealing.

On the second front, as a user of the .NET framework class library, I worry that the BCL developers are facing the same choices. What will they do? Will the .NET framework team be restrained from using generics to provide least common denomenator support (I haven't looked through the 2.0 framework enough to figure out the answer to this yet)? Will 3rd party control and component vendors?

I wish that at least support for consumption of generics was required for CLS compliance. Then I wouldn't have to make these decisions.