Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C# use of enum type - should be optional #8244

Closed
JensMeinecke opened this issue Jan 29, 2016 · 1 comment
Closed

C# use of enum type - should be optional #8244

JensMeinecke opened this issue Jan 29, 2016 · 1 comment
Labels
Area-Language Design Resolution-Duplicate The described behavior is tracked in another issue

Comments

@JensMeinecke
Copy link

Something that's been bugging me a long time. Now that C# 6 has come up with using static concept, I have decided to bring this up for discussion:

When dealing with enums we have constructs similar to the following:

DialogResult result = DialogResult.Ok;

Now I fully understand why I have to put the first DialogResult in that declaration. But I don't understand why the enum type is required in the assignment part. If I omit it the compiler will complain, telling me that a DialogResult is expected. So if it know that we are dealing with DialogResult surely it could look in the DialogResult type and allow

DialogResult result = Ok;

This becomes particularly handy when dealing with [Flag] enums. Would your rather type all of this:

this.Anchor = AnchorStyles.Bottom | AnchorStyles.Left | AnchorStyles.Right | AnchorStyles.Top;

or all of this:

this.Anchor = Bottom | Left | Right | Top;

In the context of the assignment, it is pretty obvious what is meant. No need to guess.

Similarly with switch statement and comparisons:

switch(form.DialogResult)
{ 
      case Ok:
           ////
           break;
      case Cancel:
           ////
           break;
}

if (form.DialogResult == Ok)
{
  /// do something
}

and, of course, return values:

private DialogResult Result 
{      get { return Ok; } }

and function calls:

private SetResult(DialogResult result);
....
SetResult(Ok);

In other words in all context where an expression of the known type is expected, you can infer the type.

If there is a conflict you have to resolve the ambiguity explicitly:

class MyClass 
{
       int Left { get; set;}
       int Right {get; set;}

      void SetAnchorSide(int margin) {....}

      void SetAnchorSide(AnchorStyles side) { ...}

     void SomeCode()
     {
          // Ambiguous - could refer to either this.Left of AnchorStyles.Left
          SetAnchor(Left); 

         // Use either of the following two
         SetAnchor(AnchorStyles.Left);
         SetAnchor(this.Left);
    }
}
@alrz
Copy link
Member

alrz commented Jan 29, 2016

Dup of #952

@gafter gafter added the Resolution-Duplicate The described behavior is tracked in another issue label Feb 8, 2016
@gafter gafter closed this as completed Mar 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Language Design Resolution-Duplicate The described behavior is tracked in another issue
Projects
None yet
Development

No branches or pull requests

4 participants