Discussion - Support alternate syntax for specifying an enum's type.

[Korporal]

Currently we can specify the underlying type for an enum using this kind of declaration:

enum Day : byte {Sat=1, Sun, Mon, Tue, Wed, Thu, Fri};

I'd like to propose a change that allows us to also write this:

enum Day : (byte) {Sat=1, Sun, Mon, Tue, Wed, Thu, Fri};

The type is still a byte but that syntactic form will then allow the compiler to tag the type in some way so that it can automatically infer a cast when we pass an enum value to a method where the argument's type is byte rather than reporting CS1503.

This would enable the enum designer to explicitly state "Automatically cast these values to byte when used in expressions expecting a byte" simply using the parenthetical form of declaration. The inferred cast would operate in the other direction too - where a byte is used where an enum value is expected.

This would not break existing code because the form (byte) is completely new.

The inferred cast would only be performed by versions of the compiler that also recognize the new syntactic form. That is to say an older compiler consuming a new assembly (that uses (byte) for some enum declaration) would behave as it does already.

One would need to use the newer compiler for both defining the enum and consuming it in order to get the automatic inferred casting.

[Pretasoc]

In my opinion implicit casts to an enum type is dangerous, since the the cast (how its currently performed) does not validate weather the byte value in your case correspons to an valid enum value. So this cast should remain explicit. If this feature is implemented - and i doen't see any need for it - the implicit cast should perform a check if the argument corresponds to a value defined by the enum.

[Korporal]

closed in error !

[Pretasoc]

We probably don't need a language change. With dotnet/roslyn#11159 and #192 you should be able to define your own implicit cast for your enum. If you combine this with #104 you can extend the enum type itself and define an implicit operator for all enums. But in the last case you cannot return the appropriate type, since the enums can differ in their underlying type. However i still not recommend to do this.

[Neme12]

since the the cast (how its currently performed) does not validate weather the byte value in your case correspons to an valid enum value

There is no need for such a validation because all values of the underlying type are valid enum values.
Some of those values might have one or more names associated with them.

[Pretasoc]

I know it is possible to assign any value of the underlying type to an enum. But in my opinion you use an enum to restrict the underlying type to some named cases. And in most cases such an unnamed enum value, will result in an ArgumentException when passed to a method.

[svick]

Why do you think an enum that can be implicitly casted to its underlying type is a common requirement? In what situations would that be useful?

[Korporal]

@svick - Not sure to whom your question is directed but I cannot see any post saying that this is common. I would add however that since the language supports explicit casting then clearly the original language designers had decided to support this so at some point it was recognized as something that developers would want to do.

Given this fact then (casting to some basic type) it seems natural to me to take it a step further and give developers some ability to avoid the explicit cast and improve code readability.

[svick]

@Korporal

Not sure to whom your question is directed but I cannot see any post saying that this is common.

If it's not common, then I don't see a reason to implement this feature. A proposal does not get implemented just because it's "natural", it has to actually be useful enough to warrant inclusion in the language.

[Korporal]

@svick

If it's not common, then I don't see a reason to implement this feature. A proposal does not get implemented just because it's "natural", it has to actually be useful enough to warrant inclusion in the language.

What is the definition then of "common" and how do you establish if something is or is not?

[Neme12]

@Korporal Are you saying you haven't even needed or found a use case for this feature?

[Korporal]

@Neme12

Are you saying you haven't even needed or found a use case for this feature?

No I said no such thing. However I have been in situations where this would have been helpful in improving code readability. One case springs to mind and that was in some FSM library I designed, we required the developer to define a "states" enum as part of their design. That enum (and it made great sense to define it as an enum) was used as an integer value into a 2D array of delegates (indexed by event ID and state ID - an int) used to select and invoke state transition handlers.

That code was cluttered with casts and it would have looked more elegant had we been able to index arrays directly with enum values where casting was implicit, being able to define the enum in some alternative way (as in my OP) would have led to improved code readability.

[Neme12]

That code was cluttered with casts

Why not just hide the cast in a function taking the enum and abstract over the array storage that way? Assuming Dictionary didn't work for you for some reason...

[Korporal]

@Neme12 - Yes there are several ways of dealing with this I agree about that. However when we define an enum we are defining a set of ints (or bytes or longs etc) that is exactly what is implemented under the hood. Having to create functions to "hide" this very simple operation is not a way of simplifying the code. A better way to hide it is to provide implicit conversion.

Because enum values are integers and can be "cast" to their integer values and this is fully supported as an inherent part of the language then introducing an option to invisibly perform the cast strikes me as a useful and hardly controversial change.

To be clear the compiler would still issue diagnostics when an enum value is used where an int is expected it would only perform an implicit cast if the enum itself were declared with the (int) kind of syntax (or any other kind of non breaking syntax that people find acceptable).

[CyrusNajmabadi]

Because enum values are integers and can be "cast" to their integer values and this is fully supported as an inherent part of the language then introducing an option to invisibly perform the cast strikes me as a useful and hardly controversial change.

Similar to the conversation about 'loop continue/break', having this be non-controversial to you doesn't necessarily mean the feature rises to the level where it is thought to be worth the language change.

My feelings here are similar to what they are over in that discussion. I think the language is working well here, and i think the code that is necessary to write in these cases is not onerous nor undesirable. So i would leave the language as-is and just say that you need to write this stuff out.

[Korporal]

@CyrusNajmabadi

Similar to the conversation about 'loop continue/break', having this be non-controversial to you doesn't necessarily mean the feature rises to the level where it is thought to be worth the language change.

I never said otherwise, all I've done is state my opinion (which is the only opinion I have) and responded to comments that others have made. Clearly you disagree that this is worth changing the language for and that is absolutely fine, but berating me for defending what I proposed can only discourage discourse.

I'd like to point out too that I did not propose "loop continue/break" I simply found the proposal something that I agreed with.

[CyrusNajmabadi]

and that is absolutely fine, but berating me for defending what I proposed can only discourage discourse.

I have no idea how you got "berating" from my response. :)

I was simply stating my positoin on things, and how i thought it was valuable to understand that being "hardly controversial" is not really a selling point for a language :)

I chose to reference the other issue simply because hte argument is the same. I thought relating the two would help bring clarity.

[alrz]

Once casted (implicit or otherwise) all type information is lost. I suggest you to use constants for this particular case. That force you to assign all values explicitly which I think make sense when you're actually dealing with integers, for example.

public static class Days {
  public const int 
    Sat = 1,
    Sun = 2,
    ... ;
}

[Korporal]

@alrz - That is in fact what I usually do but one must explicitly set each member and ensure any new members get values that are consistent with those already defined all the stuff that is automatic with an enum.

[AustinBryan]

Extension Everything in C# 8 should be able to give you the ability to do this anyways

[Korporal]

@AustinBryan - What is "extension everything"?

[Joe4evr]

@Korporal #164.