Change Which Enum Mapping is Used for Field-less Enums #4256
Description
Currently in C#, we have two separate mappings for enums.
If your enum has an underlying type, it gets mapped to an enum in C#.
If your enum has no underlying type, it gets mapped to a Dunet discriminated union instead.
This has the unfortunate effect that if you write a simple enum in C#:
enum Color { Red, Blue }
you don't get a simple enum in C#, you get a heavy Dunet class type instead. This is suboptimal.
I propose that we change the criteria from "is there an underlying type" to "does this enum have any fields".
If there are any fields, we map it to the Dunet type, if not, it's a simple enum.
There is no change to the Slice semantics, nor the encoding (which would still be based off whether or not there is an underlying value). This is purely about which mapping we get in C#.
One interesting case is for unchecked enum Foo { B, C }.
An unchecked enum, without an underlying type, and which currently has no fields.
By my proposal, this would be mapped to a normal enum Foo { B, C } in C#.
But what happens when I receive an unknown enumerator, which has some fields? (totally valid in Slice)
We could just return the discriminant, but throw away the fields. I think this is reasonable.
But, if we want to preserve the fields as a ReadOnlyMemory<byte> (like we currently do),
then we would need to make the following ammendment to my proposal:
We only use the Dunet representation if an enum has any fields,
+or if the enum is unchecked and could have fields (no underlying type).