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

[Isaac S.]

On Monday, 12 November 2018 at 22:07:39 UTC, Walter Bright wrote:
> *snip*
> Both f(int) and f(short) match, because implicit conversions 
> rank the same.
> To disambiguate, f(short) is pitted against f(int) using 
> partial ordering rules,
> which are:
>
>    Can a short be used to call f(int)? Yes.
>    Can an int be used to call f(short)? No.
>
> So f(short) is selected, because the "Most Specialized" 
> function is selected
> when there is an ambiguous match.
> Note: the "most specialized" partial ordering rules are 
> independent of the arguments being passed.

Well frankly that's bad design. If I declare Foo as an int enum I 
(and any _reasonable_ programmer) would expect Foo to prefer the 
int overload.

Think of it this way, each enum can be thought of like this:

immutable struct EnumName(T) {
     T value;
     alias value this;
}

So, if a programmer declares an enum of type int (EnumName!int), 
the alias-this will convert the enum to an int. Thus, the 
programmer expects the value to implicitly
convert to an int; which is a _direct_ implicit conversion (IE: 
is weighed heavier than just an implicit conversion).

Regardless of what you believe, it is an inconsistent behavior to 
the programmer (IE: The person you should be considering as a 
language designer).

If this horrid design choice stays, this _will_ go down as a 
mistaken "feature" of the language that everyone has to account 
for otherwise it bites them (Example: C++ implicitly converting 
by default instead of requiring an implicit attribute).


If you really want this plaque in the language, at least make it 
not affect those that gave their enum a type. If you at least do 
that, someone can add it to DScanner to tell anyone that doesn't 
type their enum to expect illogical behavior.