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.
