DIP 1015--Deprecation of Implicit Conversion of Int. & Char. Literals to bool--Formal Assement

[Rubn]

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