[Achieve][Jon Skeet: Coding Blog]Generic constraints for enums and delegates

Generic constraints for enums and delegates

As most readers probably know, C# prohibits generic type constraints from referring to System.Object, System.Enum, System.Array, System.Delegate and System.ValueType. In other words, this method declaration is illegal:

public static T[]GetValues<T>() where T : struct, System.Enum
{
    return (T[]) Enum.GetValues(typeof(T));
}

This is a pity, as such a method could be useful. (In fact there are better things we can do... such as returning a read-only collection. That way we don't have to create a new array each time the method is called.) As far as I can tell, there is no reason why this should be prohibited. Eric Lippert has stated that he believes the CLR doesn't support this - but I think he's wrong. I can't remember the last time I had cause to believe Eric to be wrong about something, and I'm somewhat nervous of even mentioning it, but section 10.1.7 of the CLI spec (ECMA-335) partition II (p40) specifically gives examples of type parameter constraints involving System.Delegate and System.Enum. It introduces the table with "The following table shows the valid combinations of type and special constraints for a representative set of types." It was only due to reading this table that I realized that the value type constraint on the above is required (or a constructor constraint would do equally well) - otherwise System.Enum itself satisfies the constraint, which would be a Bad Thing.

It's possible (but unlikely) that the CLI doesn't fully implement this part of the CLR spec. I'm hoping that Eric's just wrong on this occasion, and that actually there's nothing to stop the C# language from allowing such constraints in the future. (It would be nice to get keyword support, such that a constraint of "T : enum" would be equivalent to the above, but hey...)

The good news is that ilasm/ildasm have no problem with this. The better news is that if you add a reference to a library which uses those constraints, the C# compiler applies them sensibly, as far as I can tell...

Introducing UnconstrainedMelody

(Okay, the name will almost surely have to change. But I like the idea of it removing the constraints of C# around which constraints are valid... and yet still being in the key of C#. Better suggestions welcome.)

I have a plan - I want to write a utility library which does useful things for enums and delegates (and arrays if I can think of anything sensible to do with them). It will be written in C#, with methods like this:

public static T[]GetValues<T>() where T : struct, IEnumConstraint
{
    return (T[]) Enum.GetValues(typeof(T));
}

(IEnumConstraint has to be an interface of course, as otherwise the constraint would be invalid.)

As a post-build step, I will:

• Run ildasm on the resulting binary
• Replace every constraint using EnumConstraint with System.Enum
• Run ilasm to build the binary again

If anyone has a simple binary rewriter (I've looked at PostSharp and CCI;

both

both look way more complicated than the above) which would do this, that would be great. Otherwise ildasm/ilasm will be fine. It's not like consumers will need to perform this step.

As soon as the name is finalized I'll add a project on Google Code. Once the infrastructure is in place, adding utility methods should be very straightforward. Suggestions for utility methods would be useful, or just join the project when it's up and running.

Am I being silly? Have I overlooked something?

A couple of hours later...

Okay, I decided not to wait for a better name. The first cut - which does basically nothing but validate the idea, and the fact that I can still unit test it - is in. The UnconstrainedMelody Google Code project is live!

Published Thu, Sep 10 2009 21:09 by skeet

Filed under: C#, Wacky Ideas, Stack Overflow

via msmvps.com

Posted via web from 米良的实验室