Home Dashboard Directory Help
Search

【C#】Enum declaration only accepts value type alias (e.g. Short, Int, Long) instead of .NET ValueType (e.g. System.Int16, System.Int32, System.Int64) by Martin_Xie


Status: 

Closed
 as Won't Fix Help for as Won't Fix


1
1
Sign in
to vote
Type: Bug
ID: 557064
Opened: 5/5/2010 1:54:58 AM
Access Restriction: Public
0
Workaround(s)
view
0
User(s) can reproduce this bug

Description

Symptom    
If you use System.Int16/Int32/Int64 instead of Short/Int/Long to declare Enum, it will get compilation error.

Root Cause    
It's by design. Using value type alias is required exactly in Enum declaration.

It is "by design".
1.     The syntax is correct. C# specification explicitly states that the enum's underlying type must be byte, sbyte, short, ushort, int, uint, long or ulong.
2.     Although the underlying type of “Short” and "System.Int16" are one and the same, they are not as identical as you assume. The System.Int16 is a type, and the Short is a type keyword.
3.     ValueType is sealed. You cannot inherit from any class that derives from System.ValueType.
4.     But, it allows you to use the keyword to control. The intent is to prevent your using names of any types that derive from System.ValueType when declaring other types. The original intent is to provide a tightly controlled mechanism that allows you to declare types that inherit from System.ValueType.
However, MSDN says "The C# type keywords and their aliases are interchangeable", which often let customers feel confused/inexplicable. They think it’s a compiler or grammar bug.

Business Impact / Customer Experience    
Since the “Short” and "System.Int16" are the same one underlying type and can be interchangeable, many customers feel confused/inexplicable why it cannot be interchangeable in Enum declaration. They think it’s a compiler or grammar bug.
The Voice of customers:
This sounds like a small compiler bug (small becuase its easy to workaround).
Here is what MSDN says "The C# type keywords and their aliases are interchangeable."
In my view this is a real but tiny, compiler (or perhaps grammar) bug.
The fact that the compiler lets you use "short" here and not "System.Int16" is a quirk of the compiler (perhaps not a bug, but a quirk).

Quick Facts and Supporting Data
http://social.msdn.microsoft.com/Forums/en/csharplanguage/thread/70b8b7f1-a561-4117-8c78-41880e723da2
• Replies: 42
• Views: 685
Details
Sign in to post a comment.
Posted by Ananth Balasubramaniam on 7/7/2010 at 5:08 PM
@Alex Turner: Yes, it does. Due to this "quirk", it is impossible to use an alias as the governing type for an enum. An alias cannot be defined for "int" and therefore aliases are in this context, useless.

Consider this "real" case.

using cl_int = Int32;

public enum cl_bool : cl_uint
{
False = 0,
True = 1
};

Now I'm forced to declare the governing type for cl_bool as int (and my expressive alias is useless), because

a. I can't declare an alias for int, only Int32
b. I can't use Int32, only int as the governing type for my enum.

Isn't that counter-intuitive/contradictory? This isn't about expressiveness, it's about consistent usage of the language and its constructs. Surely you'd want to fix that?
Posted by Microsoft on 6/25/2010 at 8:53 AM
Thanks for the suggestion for Visual Studio!

As you point out, we could enable support for saying Int16 instead of int here, but this would not provide any extra expressiveness to C# programs (and it's more characters to type!). We'd be unlikely to invest our resources to add this support to Enums.

Alex Turner
Program Manager
Visual Basic and C# Compiler
Posted by Microsoft on 5/5/2010 at 9:13 PM
Thank you for reporting this issue.
We are routing this issue to the appropriate group with the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 5/5/2010 at 5:02 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)
Sign in to post a workaround.