Generics CLS compliant in Whidbey

I am super excited about the fact that generics will be CLS complaint for Whidbey… With this change generics are now completely first class in Whidbey… It means that the frameworks Microsoft and 3rd parties produce can full leverage this new feature in order to provide the most value to our customers.   I would suggest you follow the Generics Design Guidelines when using generics in public APIs.


As always, we’d love to hear your feedback and comments on this.  Is it a good change?  Are there places in Whidbey that you’d like to see us use generics better?


Comments (11)

  1. Brad,

    I’ve always thought of the CLS as being a low entry bar for languages to get to to call themselves a .NET language (obviously they need an appropriate compiler). In other wordds the CLS was the *minimum* amount of the type system they had to support.

    Now I’m not an expert in all the languages that target the CLR so maybe some of the languages don’t support the while CLS – I really have no idea. But I’ve always spun this as the amount of the type system to expose on your public API if you want *any* .NET language to be able to use your component.

    Although I love the idea of generics being used in BCL classes I think putting them in the CLS (given the above reasons for its existance) seems onerous on all languages to have to support consumption of generic types.

  2. Kevin Dente says:

    GREAT CHANGE. As an ISV who provides frameworks and controls with our products, we won’t be forced to decide between "rich vs reach" in our API design. As a veteran of the "ole automation debacle", back when Powerbuilder supported some but not all COM features, I’m very appreciative.

  3. That Generics Design Guidelines link doesn’t reflect the latest thoughts on type parameter naming (TKey, TValue instead of K,V), so I regard the rest of it as suspect too. Is there an official up-to-date copy of this document somewhere? If not, there should be.

  4. I’d like to see a WinForms control that was a generic type and the value property could be set based on the generic type. The designer should handle setting the generic type up (and should of course support nullable types).

    This would be perfect for DateTimePicker (that actually works and supports nulls) and all different types of combo controls (with name/value pairs which you currently only support in for some very very stupid reason).

    Just all kinds of posibilities if the designer supported Generic typed controls and components in WinForms and

  5. Since generics cause code to be generated at run-time, doesn’t this mean .NET applications will steadily become slower and slower in the future, especially at startup, as more and more libraries use generics? Why is no one talking about this potential problem with the basic design?

  6. Joe Duffy says:

    Frank, I wouldn’t categorize this as a problem as much as a conscious design decision.

    We only JIT one unique type for all combinations of reference type arguments for a given generic type. Therefore, the only "bloat" is with value type arguments, and even then it’s not really a problem unless you start using every tons of permutation consisting of value types. (For example, Dictionary<int,int>, Dictionary<int,long>, Dictionary<float,int>, Dictionary<int,float>, and so on.)

    If this is unacceptable, there’s always NGen to avoid the time penalty of having to JIT at runtime… although you can’t escape the (minor) working set hit.

    As I stated earlier, this is a conscious design decision resulting from our use of type generation instead of erasure. You should read JoelPob’s excellent article on this very topic for more information:

  7. Anonymous Delegate says:

    — quote — I’d like to see a WinForms control that was a generic type and the value property could be set based on the generic type — quote — .

    Sounds like the <a href="">Avalon content control</a>

  8. Tobias Burger says:

    I’d like to see DataSets (especially typed DataSets) using nullable types.

  9. Lonnie McCullough says:

    All I want is a typedef statement in C# ( or its equivalent ) so that I don’t have to deal with the angle brackets if I don’t want to. I don’t mind using generics at all I just want to be able to refer to:




    with the declaration looking oh so similar to C++:

    typedef ArrayList<People> PeopleList;

    Is this too much to ask at this late stage in the game?

  10. I worry about a compile time only solution as you quickly end up needing the symbolic name when debugging, in static representations (such as config files), via reflection, etc.

    But you can always do this if you’d like:

    public class PeopleList : List<People> { }

    I think it gives you most of what you want.

  11. Lonnie, you can do that like so:

    public class PeopleList : List<People> {}

    This leaves you open to define other methods for the PeopleList class as well.

Skip to main content