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?

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

I'm not a language designer, so knowing what I would do is sort of

pointless. I don't have the kind of knowledge and experience that would
allow me to provide a reliable answer to that question. Unless you're an
experienced language designer, I doubt you do either, for what it's worth.

OK, I won't press you further. I'll just say that _designing_ something is a
lot easier than implementing it. :)

The only language I've designed and implemented so far is a simple scripting
language for a telnet client I wrote.

[Jon Skeet [C# MVP]]

On Apr 18, 1:22 pm, PIEBALD <PIEB...@discus sions.microsoft .comwrote:

doing this in C# would mean removing:

o lock statements
o using statements
o foreach statements
o collection initializers
o type shorthands (string for System.String, int for System.Int32 etc)

.... and no doubt others that I can't think of off the top of my head

Well, you got me there; I can see how using, and foreach would be affected.
I'm not so convinced about lock, collection initializers, and type
shorthands, but I probably don't need to be.

I might as well fill in the details for interested parties:
o lock is equivalent to a try/finally with Monitor.Enter/Monitor.Exit
o collection initializers rely on IEnumerable and Add methods
o type shorthands are specified in terms of what framework type they
represent

(On another note; I really don't see what type shorthands add to the
language anyway other than syntactic sugar, but we needn't go there.)

They're *all* just syntactic sugar. There's an awful lot of syntactic
sugar in C#, particularly in C# 3. Don't assume that "syntactic sugar"
is a bad thing - it makes the language sweeter :)

Jon

[Jon Skeet [C# MVP]]

On Apr 18, 1:48 pm, PIEBALD <PIEB...@discus sions.microsoft .comwrote:

I'm not a language designer, so knowing what I would do is sort of
pointless. I don't have the kind of knowledge and experience that would
allow me to provide a reliable answer to that question. Unless you're an
experienced language designer, I doubt you do either, for what it's worth.

OK, I won't press you further. I'll just say that _designing_ something is a
lot easier than implementing it. :)

I'd disagree with that, actually. Designing a fairly general purpose
language which balances power with readability, avoids brittleness, is
unambiguous etc is a very tricky thing indeed. The C# 3 designers have
(for the most part) painted an incredibly elegant picture. The
different language features all come together for LINQ, but each is
also individually useful outside LINQ. All this without ruining the
language in other ways.

Don't forget that a mistake in one version of the language is likely
to haunt future versions. (For example, I know my view that classes
should be sealed by default is also held by at least one of the C#
language designers - but even if *all* the designers agreed on that
now, there's no way on earth they'd change it at this point - it would
cause hideous amounts of breakage.)

Designing a very simple language may indeed be easier than
implementing it - but designing a general purpose language like C# is
a different matter.

Jon

[Peter Duniho]

On Fri, 18 Apr 2008 13:48:00 -0700, PIEBALD
<PI*****@discus sions.microsoft .comwrote:

OK, I won't press you further. I'll just say that _designing_ something
is a
lot easier than implementing it. :)

Yikes. Like Jon, I completely disagree with that. I have every
confidence that, given a correct design provided to me, I can implement
whatever that design might be. However, producing a correct design is
much more challenging.

I have no doubt that, if I wanted to, I could write a C# compiler. Today,
with the skills I have now. It might not be the best compiler around
(okay, it probably wouldn't be :) ), but it would work and it would comply
with the design.

But I am definitely not experienced enough to be designing an actual
language. The skills I currently have are inadequate to the task, and I
would either spend a huge amount of time (years) learning what I need to
know (either by trial and error, or through study of practices of other
language designers), or I would produce a very inferior design.

Frankly, having used a wide variety of languages over my career as a
programmer, I'm very impressed with C# even today (that is, now that the
honeymoon is over, so to speak :) ). I admit, I was a little put off
initially by its similarity to VB, but using C# gave me a greater
appreciation for some of the design choices made in VB, and I really like
how C# just "feels" simpler and more precise. Where it restricts the
programmer, it does so in ways that avoid too much inconvenience while
helping to prevent relatively common-but-serious bugs.

I don't think just anyone could come up with a language design that
provides all that. It's clear that some very smart people, looking very
hard at a wide variety of existing languages and their positive and
negative characteristics , came up with C# and while they may not always
have compromised in exactly the way everyone else would have, I always
feel confident that they made a particular compromise with the best
intentions and for good reasons. I've yet to see a counter-example to
that impression.

Pete

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

classes should be sealed by default

Ew, I think very few classes should be sealed; you just don't know what the
user wants to do with it.

However, I understand that things like sealed can help the compiler to
optimize the code, so I don't mind so much.

On the other hand, I think all classes should be partial by default.

Well, wait, no I _really_ think that there should be very few things that
are default.
For instance I don't think classes and members should have default access
modifiers, they should be explicit.
Well, basically I mean a sort of "ivory tower" language design (hmmm...
Pascal?), and I will admit that many real-world considerations must be made.

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

Don't assume that "syntactic sugar"

is a bad thing - it makes the language sweeter :)

Yes, but when the dessert trolley comes around and all I need is one thin
mint...

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

or I would produce a very inferior design.

Right (me too), but it would be easy. I agree that a _good_ design requires
a lot of real-world compromises.

And I certainly agree with the rest of that too; I liked C# from the time I
first read a spec of it circa 1999 (I was using C at the time).

[Jon Skeet [C# MVP]]

On Apr 18, 2:51 pm, PIEBALD <PIEB...@discus sions.microsoft .comwrote:

classes should be sealed by default

Ew, I think very few classes should be sealed; you just don't know what the
user wants to do with it.

Search for "inheritanc e tax" on my blog: http://msmvps.com/jon.skeet

Inheritance is a powerful tool, but classes should be designed for
inheritance up front; inheritance tends to expose implementation
details (or at least make those implementation details important).
It's not so bad if none of the methods are virtual, but as soon as
they are, life becomes trickier.

However, I understand that things like sealed can help the compiler to
optimize the code, so I don't mind so much.

My reasons for preferring sealed classes have nothing to do with
optimisation, but instead with design.

On the other hand, I think all classes should be partial by default.

Why? Partial is only a compile-time notion within the same assembly. I
find it quite rare that I can create a new file, but not modify
another file contributing to the same assembly. So, the cost of making
a non-partial class partial later on is minimal.

In contrast, there's a cost to a class being partial when it doesn't
have to be. If I look at a class which is non-partial, I know
immediately that all the code for the class is in that same file;
there's no need to dig around elsewhere. If it's partial, I need to
find all the other source files before I can get a good idea of the
shape of the class.

Well, wait, no I _really_ think that there should be very few things that
are default.
For instance I don't think classes and members should have default access
modifiers, they should be explicit.

I'm in two minds about that, but I can certainly see its appeal. If we
*are* to have default access modifiers, I think C# takes exactly the
right approach by making everything as private as possible by default.
However, forcing developers to consider it to start with would also be
a good idea.

Well, basically I mean a sort of "ivory tower" language design (hmmm...
Pascal?), and I will admit that many real-world considerations must be made.

That's certainly true in many cases, but I suspect that it wouldn't
have caused too many complaints if C# had gone the "everything
explicit" route to start with.

Jon

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

OK, a different tack...

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

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.

namespace W
{
public enum X { X }

public class Y1<T{}
public class Y2<Twhere T : struct {}
public class Y3<Twhere T : class {}

public class Z
{
object V1 = new Y1<X>() ; // this succeeds
object V2 = new Y2<X>() ; // this succeeds
object V3 = new Y3<X>() ; // this fails (as it should)
}
}

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

[Jon Skeet [C# MVP]]

On Apr 19, 7:00*am, PIEBALD <PIEB...@discus sions.microsoft .comwrote:

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