Compiler Error CS0702

[=?Utf-8?B?UElFQkFMRA==?=]

I'd really like to be able to constrain a generic type to System.Enum or,
better, enum. But of course that results in "Compiler Error CS0702".

So far I've been checking the type parameter at runtime and throwing an
exception if the provided type is not an enum. That works, but it just
doesn't seem quite right.

After reading through section 4.4.4 of the C# 3.0 spec I see no reason why
constraining to System.Enum should not be allowed.

So my questions are:
Are there reasons why these types can't or shouldn't be supported as
constraints?
(If so, the documentation of Compiler Error CS0702 ought to state them.)
Is this simply a limitation of the compiler rather than of the language?
Are efforts being to made to support these types as constraints?

[Peter Duniho]

On Sat, 19 Apr 2008 07:00:01 -0700, PIEBALD
<PI*****@discus sions.microsoft .comwrote:

OK, a different tack...

You are approaching the definition of "insane".

Is a type parameter constraint anything more than a compile-time type
check?

No. That's the point of generics...it's all about what can be verified at
compile-time.

The compiler can already check the type as far as being value type or
reference type, even when the type used is an enum. So compile-time type
checking of enums is possible.

No one said it wasn't. The issue isn't what's possible. The issue is
what's consistent and workable in the context of the other rules of C#.

[...]
I don't see a conceptual reason why "where T : enum" _shouldn't_ be
supported.

Why not? Your example has nothing to do with the question, and Jon and I
have both already provided quite a lot of detail regarding the question.

Pete

[Peter Duniho]

On Sat, 19 Apr 2008 07:09:23 -0700, Jon Skeet [C# MVP] <sk***@pobox.co m>
wrote:

[...]

>I don't see a conceptual reason why "where T : enum" _shouldn't_ be
supported.

Likewise. I don't think any of us have come up with a reason why it
shouldn't be supported. I'd be interested to know the reason too - but
I don't think you'll find it here ;)

I'm surprised to see you write that. I admit that I haven't provided a
proof per se. But I think that the general issues surrounding the lack of
inheritance for value types and the desire for enums to be value types are
certainly relevant.

I agree that the compiler could support "enum" as a constraint, but it
would carry some implications for existing generic rules that would have
to be changed to allow that. There may in fact be good reasons for those
rules that carry greater weight than the benefit of supporting "enum" as a
constraint.

At the very least, I see enough evidence to grant the language designers
the benefit of the doubt.

Pete

[Jon Skeet [C# MVP]]

On Apr 19, 9:21*am, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

Likewise. I don't think any of us have come up with a reason why it
shouldn't be supported. I'd be interested to know the reason too - but
I don't think you'll find it here ;)

I'm surprised to see you write that. *I admit that I haven't provided a *
proof per se. *But I think that the general issues surrounding the lack of *
inheritance for value types and the desire for enums to be value types are*
certainly relevant.

It's quite possible that I haven't been reading your posts closely
enough. I'm away from home at the moment, so don't have the benefit of
my preferred newsreader :(

I quite agree with your point that there's no reason to expect it to
work within the current C# specification, but to my mind the question
of exactly why C# is specified that way is still an open one.

The idea of only assessing the validity of a type argument at
execution time (with a static constructor) is a grotty workaround,
IMO.

I agree that the compiler could support "enum" as a constraint, but it *
would carry some implications for existing generic rules that would have *
to be changed to allow that. *There may in fact be good reasons for those *
rules that carry greater weight than the benefit of supporting "enum" as a*
constraint.

There may well be - but I'd like to hear them rather than assuming
they exist.

At the very least, I see enough evidence to grant the language designers *
the benefit of the doubt.

I suspect there may well be very good reasons - but I just haven't
seen anything which convinces me yet.

When I get back home I may drop a line to the team to see if they'd be
willing to comment on it...

Jon

[=?Utf-8?B?UElFQkFMRA==?=]

(with a static constructor)

Thanks for mentioning that again.
I didn't see where it was mentioned in the spec, but your mention of it
prompted me to realize that the class I'm working on should be static.

[Jon Skeet [C# MVP]]

Jon Skeet [C# MVP] <sk***@pobox.co mwrote:

<snip>

I don't see a conceptual reason why "where T : enum" _shouldn't_ be supported.

Likewise. I don't think any of us have come up with a reason why it
shouldn't be supported. I'd be interested to know the reason too - but
I don't think you'll find it here ;)

I asked the C# team about this issue, and got this reply:

<quote>
First off, your conjecture is correct; the restrictions on constraints
are by and large artefacts of the language, not so much the CLR. (Were
we to do these features there would be a few minor things we=3Fd like to
change in the CLR regarding how enumerable types are specified, but
mostly this would be language work.)

Second, I would personally love to have delegate constraints, enum
constraints, and the ability to specify constraints that are illegal
today because the compiler is trying to save you from yourself. (That
is, making sealed types legal as constraints, and so on.)

However, due to scheduling restrictions, we will likely not be able to
get these features into the next version of the language.
</quote>

--
Jon Skeet - <sk***@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[=?Utf-8?B?UElFQkFMRA==?=]

However, due to scheduling restrictions, we will likely not be able to

That's what I thought. I'll keep my fingers crossed. Thanks for your effort.