[draft issue] Allow implicit conversion of enum into underlying type

[LWChris]

Allow implicit conversion of enum into underlying type

Summary

Allow declaration of public implicit enum Foo [: UnderlyingType] which in turn allows members of Foo to

1. be passed as an argument into functions that require UnderlyingType or on that UnderlyingType implicitly casts into
2. assigned to variables of such types
3. compared to values of such types

Important: allowing the other direction (casting UnderlyingType to enum) is not part of this original proposal for reasons that I listed under alternatives.

Motivation

Especially in serialization and related areas there are often generic functions that require arguments to be passed as native value types such as int or byte. On the other hand certain transmissible values often have well-known meanings, which calls for them to be declared and organized as an enum.

C# does not allow implicit conversion of an enum to its underlying value type. So if you still want to use the enums, you have to explicitly cast back and forth everywhere:

public enum CommandId : byte
{
    NoOp = 0,
    // ...
    Reboot = 250,
    Shutdown = 251
}

public enum UartResult : byte
{
    Ok = 0,
    DeviceBusy = 1,
    // ...
    UnknownError = 255
}

public class UartConnection
{
    public void Transmit(byte value) { }

    public void Transmit(byte[] values) { }

    public byte Receive() { }

    public byte[] Receive(int count) { }
}

public class UartControlledDevice
{
    public bool Reboot() {
        m_UartConnection.Transmit((byte) CommandId.Reboot); // Here.
        var result = (UartResult) m_UartConnection.Receive(); // And here ...
        return result == UartResult.Ok; // ... or here.
    }
}

The Transmit case may be made more comfortable with an extension. Write code once, benefit everywhere.
For the Receive case, creating a like-named extension does not do anything. It has to have a different name to get resolved correctly.
For the == case there is no "write code once, benefit everywhere" solution available.

Even for Transmit where a "clean" workaround is possible, it quickly becomes obnoxious to create a cross product of 35 extensions for your 5 enums and 7 methods; this proposal would alleviate this by allowing you to declare your 5 enums implicit and be done. It also removed the obligation to add 5 or 7 more extension methods when the 8th method is added or a 6th enum is introduced.

Another half-baked workaround is to use a static class with static readonly fields. The downsides of this are that in the debugger you'll only see the value but not the member name, and obviously you can't use the static class as a field type for other places.

Detailed design

I'm proposing to create the possibility to add the implicit modifier keyword to an enum declaration. This will allow enum members to be used where the underlying type (or a type that the underlying type can be implicitly cast into) is required:

public implicit enum CommandId : byte
{
    // ...
}

public implicit enum UartResult : byte
{
    // ...
}

public class UartControlledDevice
{
    public bool Reboot() {
        m_UartConnection.Transmit(CommandId.Reboot); // Argument will be cast into byte
        var result = m_UartConnection.Receive();
        return result == UartResult.Ok; // RHS will be cast into byte
    }
}

Drawbacks

Compatibility wise: none that I could think of. An existing keyword is introduced in a place where it has been syntactically illegal beforehand, so there can't be any legal code that may conflict with this design proposal.

Usability wise: although I have never found any statement on why enums and their underlying types aren't compatible in C#, I assume there was/is a reason. This would have to be explained and re-evaluated.

If the only argument is "to make it harder to accidentally assign an invalid value", then this argument does not have any relevance for this proposal, because the proposal does not allow assigning the value 5 where the enum was expected. (On the other hand, in VB.NET even that works and I have never stumbled upon a serious problem with that behavior.)

Alternatives

As stated above, this proposal is explicitly only about allowing the "widening" direction enum → underlying type. It might be worth discussing the other way round.

My stance towards this a firm "no" though, since I can see many reasons why that would be much more problematic:

• It makes it easier to slack off and write worse code such as CommandId = 250 instead of CommandId = CommandId.Reboot
• It makes it easier to write wrong code such as CommandId = myCommand.Value; // oops, I meant .Id
• Places where invalid values may be set will be obscured CommandId = config.Value; // obscured whether 'Value' was an arbitrary byte or a "safer" CommandId
• return result == UartResult.Ok - cast result into UartResult, or cast UartResult.Ok into byte? This is probably not a big issue; just chose the widening (i.e. second) option like when comparing int and long.

If it is still considered, it might be worth discussing about using in and out keywords to selectively allow any direction:

• implicit enum CommandId : byte ⇒ CommandId ⇄ byte (maybe also implicit in out as well)
• implicit in enum CommandId : byte ⇒ CommandId → byte
• implicit out enum CommandId : byte ⇒ CommandId ← byte

If we decide "not now" but want to have this option in the future, we would need the original proposal to be implicit in from the start to have no naming conflicts.

Alternatively, we can have implicit enum now and always mean implicit in, and have the option for a future design to be:

• implicit [in] enum CommandId : byte ⇒ CommandId → byte
• implicit out enum CommandId : byte ⇒ CommandId ← byte
• implicit in out enum CommandId : byte ⇒ CommandId ⇄ byte

[jfrank14]

I would really like something like this. I've been using Visual Basic for 25 years and I'm not sure I've ever seen a case where an implicit conversion of an enum to an int caused a bug, but the constant casting in c# is a huge hassle.

[colejohnson66]

This is probably covered by the "extension everything" proposal: #5496 / #5497

public extension UartResultExtensions for UartResult
{
    public static implicit operator byte(UartResult value) => (byte)value;
    public static implicit operator UartResult(byte value) => (UartResult)value;
}

[colejohnson66]

Well, you don't have to write it every time; You would write a source generator that does it for you:

[ImplicitToFromUnderlying]
public enum UartResult : byte
{
    // ...
}

Honestly, the fact that "extension everything" is making progress combined with source generators being a thing, I highly doubt your proposal will go anywhere.

[LWChris]

I understand and agree with your assessment, although I have to admit that I despise the recent trend of "You can write additional code to extend the language with features" for every feature suggestion, including those that should be native to the language in question.

Providing building blocks is cool and all, but sometimes I (and others) would like to have something pre-built from those building blocks. Having to writing your own custom analyzers, source generators, and VS extensions should not become the expected norm in order to comfortably work with C#.

[colejohnson66]

Understandable, but just because you think feature X should be in the language doesn't mean that others would like it there. I have no opinion for or against your proposal; I'm just stating how things work.

[LWChris]

Likewise however, just because some people think it can be achieved by other means doesn't mean it shouldn't be there. 😀

But I know and accept that there are other people (the LDM members) who decide what eventually gets done, and that they may have different priorities than QoL improvements for managable annoyances. 😄

[franchyd]

Yeah, there are limitations to source generators, you cannot relegate every possible feature to them they cannot easily interconnect. See dotnet/roslyn#57239