On Wednesday, 14 November 2018 at 02:45:38 UTC, Walter Bright
wrote:
On 11/13/2018 3:29 PM, Rubn wrote:
> enum A : int { a = 127 }
`a` is a manifest constant of type `A` with a value of `127`.
Remember that `A` is not an `int`. It is implicitly convertible
to an integer type that its value will fit in (Value Range
Propagation). Other languages do not have VRP, so expectations
from how those languages behave do not apply to D. VRP is a
nice feature, it is why:
enum s = 100; // typed as int
enum t = 300; // also typed as int
ubyte u = s + 50; // works, no cast required,
// although the type is implicitly
converted
ubyte v = t + 50; // fails
In your articles, it is crucial to understand the difference
between a manifest constant of type `int` and one of type `A`.
At least can you understand where the problem lies? If you have
code like this:
foo(Enum.value);
Then it gets changed:
// ops might be calling a different function now
foo(runtimeCond ? Enum.value : Enum.otherValue);
Or how about if we just add another enum to our list:
enum Enum : int {
// ...
// add new enum here, shifting the values down
value, // 126 -> 127
otherValue, // 127 -> 128 - Ops now we are calling a
different function ~somewhere~
// ...
}
From your implementation perspective I can see why it is a good
thing. But from my user's perspective this just screams
unreliable chaotic mess, even in the most trivial examples.
What D does is only suitable for the absolute most trivial
example:
enum int s = 100;
ubyte v = s; // ok no cast required
But even just a slightly more trivial example like we have now,
and it falls apart:
enum int s = 100;
void foo(int);
void foo(byte);
foo(s); // Not suitable for determining overloads
// though is good for variable initialization
Not one's really asking to add another layer to anything. Merely
to not treat named enum types as if they are just constants like
anonymous enums.
ubyte a = Enum.value; // this is ok
foo(Enum.value); // this needs to be x1000 more reliable
