implicit cast and overload priority

[Jonathan M Davis]

On Saturday, February 15, 2025 1:12:43 PM MST Paul Backus via Digitalmars-d-learn wrote:
> On Saturday, 15 February 2025 at 15:40:51 UTC, Dom DiSc wrote:
> > On Friday, 14 February 2025 at 15:58:26 UTC, Paul Backus wrote:
> >> Oops--it turns out both overloads are equally specialized!
> >
> > This is what I want to be fixed. For a human it is obvious
> > which of the two is a better match. Lets add a rule so that the
> > compiler can also see it!
>
> The problem with this approach is that, if you keep adding more
> and more rules, you eventually end up with so many that no human
> can remember them all, and code becomes much harder to understand.
>
> In C++, for example, overload resolution is extremely
> complicated, because they added a bunch of rules to make these
> kinds of "obvious" examples work:
>
> https://en.cppreference.com/w/cpp/language/overload_resolution

Honestly, I would argue that in most cases, if you're overloading on integer
types, you're just asking for trouble - _especially_ when VRP comes into
play, because then you get nonsense like foo(1) calling the bool overload.

So, while I can understand being annoyed that the compiler doesn't choose
the signed overload when you give it a signed number, I'd argue that it's
far better for it to give an error about it than try to make it work,
because the odds are just too high that you're going to end up with
unexpected behavior if you're overloading on integer types to that fine a
degree. Even with D's simplified overload resolution, you're still at a real
risk of calling the wrong overload and ending up with subtle bugs.

And in the cases where D _has_ tried to make the "obvious" stuff work - e.g.
something like

    ubyte[] arr = [1, 2, 3];

it's resulted in all kinds of confusing inconsistencies in the language. So,
while we learned from C++ with this stuff to some degree, we've still made
plenty of mistakes with this sort of thing.

- Jonathan M Davis