Shortcutting enum access

[Mafii]

I would like to propose a swift-type way (I think swift has this feature) to use enums without fully qualifying their name.

If I want to assign a value to an enum, I can do it this way:

MyEnumType myEnumTypeValue = MyEnumType.SomeValue;

Then later, I might do this:

myEnumTypeValue = MyEnumType.SomeOtherValue;

I find that there is lots of noise that is not needed.

If I understood correctly (from explanations of a friend of mine who uses Swift),
in Swift, you can simple do this:

MyEnumType myEnumTypeValue = .SomeValue;

This is, in my opinion, very concise and readable. There is less noise for the reader, and the code gets shorter.

This is especially the case when doing switch statements or comparisons:

if (myEnumTypeValue == MyEnumType.SomeOtherValue || myEnumTypeValue == MyEnumType.SomeValue)
{
...

Or:

if (myEnumTypeValue == .SomeOtherValue || myEnumTypeValue == .SomeValue)
{
...

I would definitely prefer the second version for readability.

I can make a practical example with an actual enum:

enum Visibility {
  Visible,
  Hidden,
}

Visibility visibility = .Visible;

...

if (visibility == .Hidden)
{ 
...

Writing this code with the current C# syntax, it looks like this.

Visibility visibility = Visibility.Visible;

...

if (visibility == Visibility.Hidden)
{ 
...

There is just lots of uneeded noise.

I would like to see this as a new syntax in C#. The type of the enum would be inferred by context.

Advantages: Readability, Shorter Code

Disadvantages: May not be worth it, (any others?)

[HaloFour]

This is effectively a dupe of #354 with a slightly different syntax.

[Mafii]

I searched for this and didn't find any. Thanks for linking me there. Agree that is basically a dupe. I would prefer this syntax over the in #354 proposed one, it seems more intuitive to me (and is already present in a language similar to c#).

[HaloFour]

@Mafii

I'd argue that Java is more like C# and Java already allows omitting the enum type name in very specific circumstances (namely the following):

// given
public enum Visibility { VISIBLE, HIDDEN };

Visibility visibility = ...;
switch (visibility)
{
    case HIDDEN:
        // do stuff
        break;
    case VISIBLE:
        // do stuff
        break;
}

[Mafii]

@HaloFour I see what you mean with the Java similarities.

However, I don't think we should use the same syntax.

Disadvantages of using the syntax from Java is that they could aswell be variable names, which could make code harder to read sometimes. When is it an enum shortcut, when is it a variable?

I personally wouldn't know.

If the syntax is just used for switch, I think the Java syntax is fine. I would rather have the syntax as proposed tho when useable on variable initialization and comparison (and maybe when interacting with other operators).

For understanding the Java way, does Java allow this:

Visibility visibility = HIDDEN;

?

[Pzixel]

@Mafii do you see the big difference between
Visibility visibility = HIDDEN;
and
var visibility = Visibility.HIDDEN;

Because I don't. However, it may be useful in comparisons and switch blocks. However, in this case we need some special-case type inference for only equality and only for enum types.

[jnm2]

Also very useful when specifying enum values as method call arguments.

[Mafii]

@Pzixel as @jnm2 pointed out:

SomeMethod(.SomeEnumValue, .SomeOtherEnumValue)

Is definitely better (shorter, also easier to read imo) than

SomeMethod(MyEnum.SomeEnumValue, MyEnum.SomeOtherEnumValue);

Especially when it's a enum name like Visibility or Color, etc.

[mungojam]

Just checked and this is possible already with static usings, so:

using static MyEnum;
var test = SomeEnumValue;

[JoshuaKGoldberg]

@mungojam but wouldn't that conflict if any other locally available symbols have the same name? .SomeEnumValue explicitly marks it as being a member of the enum, without ambiguity.

[Mafii]

Another is initializing arrays:

MyEnum[] enumValues = new[]{ .SomeValue, .SomeOtherValue, .SomeThirdValue, .WhateverValue };

This is one of the situations where a lot of readability is gained with that change.

[Pzixel]

I think we can use @.SomeValue like in another similar proposal for lambdas.

[CyrusNajmabadi]

Another is initializing arrays:

Arrays do not have their type inferred outside in. That's why you can't write, for example:

SomeEnum[] a = new [] { };

Instead, the type of the anonymous array creation is determined by the element types. In your case we would not be able to determine that type.

[Pzixel]

@CyrusNajmabadi but you can

SomeEnum[] a = { @.SomeValue };

[alrz]

do you see the big difference between

Visibility visibility = HIDDEN;
and
var visibility = Visibility.HIDDEN;

For assignments, it becomes more useful in object initializers,

new C { Visibility = Visible };

The .Visible syntax is only useful when there exist a symbol with the same name in the scope,

class Visible {}
new C { Visibility = .Visible };

But I don't know if that really worth to introduce new syntax.

This could be considered for method arguments but in the presence of overloaded methods it becomes rather brittle and could cause binding to a different method silently.

[alrz]

the type of the anonymous array creation is determined by the element types. In your case we would not be able to determine that type.

We could, if we don't just depend on the target type, i.e. we look for enum members in all enums in the scope, much like how extension methods are handled.

[jnm2]

I dislike the dot syntax but very much want the other syntax.
The dot feels wrong. It doesn't match how C# already acts when simplifying names. The reward would not be great enough to justify adding syntax that also takes away our syntax options in the future for a potential much more important language feature.

[aka-nse]

How about var. instead of .? It is more verbose than single dot, but it is well known as a type inference keyword.

[jnm2]

I think of var as meaning "introduce variable," not "infer type." This is further reinforced by the fact that someClass is var foo does not behave the same as someClass is SomeClass foo.

[jnm2]

Anyway, a different solution is already being championed: #2926

[Thaina]

Personally I like to have any sign. Dot is fine but I am a bit agree with @jnm2 that it felt wrong

However I don't like a naked enum like Java. It make ambiguous when there are variable with the same name

Maybe Visibility v = @Visible;

[Pzixel]

@Thaina it's already the syntax for using reserved names as variables.

[Thaina]

@Pzixel I know but it should be avoid if possible because even it not ambiguous in compiler it still ambiguous in code

[Pzixel]

@Thaina no one care if it's should be avoided or not. If it's a valid syntax for existing construct you cannot reuse it, it's already reserved for something else.

[AustinBryan]

using static MyNamespace.MyClass.MyEnum;
var test = SomeEnumValue;

This works in Modern C# (one of my favorite features). Note, you have to use the full name.

I always love when someone asks for a feature and the language already supports what they want in an even better way 😜

[Jonatthu]

I do not think this is a better way ;( since requires you to write more code if there is more enums...

[theunrepentantgeek]

There's a better solution/syntax championed in #2926

[Thaina]

@AustinBryan It's not any better way when you need to using static on the top even if you just use it only one line along with the thing that very obvious about the enum type

Not only that you have made the whole mess if there would be name collision. Instead of just one scope you create a chance to collide with the whole file

The whole point here is to let a only specific line of code that very obvious about the enum type can write a shorthand for it without even need to using its namespace. Your argument miss the whole point of this feature

[ashelleyPurdue]

using static MyNamespace.MyClass.MyEnum;
var test = SomeEnumValue;

This works in Modern C# (one of my favorite features). Note, you have to use the full name.

I always love when someone asks for a feature and the language already supports what they want in an even better way 😜

Unfortunately, this isn't exactly the same. For example, say I do this:

using static System.Windows.HorizontalAlignment;
using static System.Windows.VerticalAlignment;

And then later do this:

textbox.HorizontalAlignment = Stretch;
textbox.VerticalAlignment = Stretch;

The compiler will complain that the name "Stretch" is ambiguous. It can't tell if it's from HorizontalAlignment or VerticalAlignment.

I'd like the compiler to just infer which enum I'm using, based on the type of variable I'm assigning it to. Kind of like type inference with var, but in reverse.

[jnm2]

I'd like the compiler to just infer which enum I'm using, based on the type of variable I'm assigning it to. Kind of like type inference with var, but in reverse.

👍

The C# spec jargon for this is 'target-typing.'

[theunrepentantgeek]

It looks as though the using static syntax can be used to bring an enumeration into scope - at least, it works in SharpLab:

using System;

namespace Foo 
{
    public enum Color { None, Red, Green, Blue }
}

namespace Bar
{
    using static Foo.Color; 
    
    public class C {
        public void M(out Foo.Color c) 
        {
            c = Red;
        }
    }
}

So one of the original examples could be written as

Visibility visibility = Visible;
...
if (visibility == Hidden)
{ 
...

[ashelleyPurdue]

That doesn't work if you have two enums that both share a member. For example, HorizontalAlignment and VerticalAlignment both have "Center" and "Stretch" members, so you'd need to disambiguate which one you're using.

[gafter]

Something like this is now championed at #2926