Compiler Error CS0702

  • Thread starter Thread starter PIEBALD
  • Start date Start date
OK, a different tack...

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

I suspect it's also checked at runtime.
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.
Absolutely.

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 ;)

Jon
 
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
 
(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.
 
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>
 
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.
 
Back
Top