[Issue 12698] Overloads from multiple modules implicitly merge into a single overloadset

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12698

Jonathan M Davis <jmdavisProg at gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg at gmx.com

--- Comment #1 from Jonathan M Davis <jmdavisProg at gmx.com> ---
Well, if there are overloads in two different modules, and a particular
invocation of that function only can match one of them, then overload sets
don't really get involved. I suspect that the issue is that because
std.file.copy explicitly lists "in char[]", whereas std.algorithm.copy is
templatized, std.file.copy is considered to match, whereas std.algorithm.copy
isn't - and the overload sets are only brought in if it could match both. As
such, it would be a side effect of how Kenji chose to solve the issue of making
templated functions overloadable with non-templated functions.

After having to work around how the overloading rules now work, it's my
conclusion that it only works to overload templated functions with a
non-templated function when what they work with is completely disjoint, which
tends to mean that it doesn't make sense to overload templated functions with
non-templated functions. But if the repercussions of those overload rules leaks
into the compiler's decision to use overload sets or not, then we have a big
problem.

I suspect that part of the problem stems from the fact that the compiler seems
to want to decide whether it wants to use a templated function or not before
decided which overload to use - to the point that they aren't even considered
if a match is found before then - whereas IMHO, each of the templated overloads
should be on equal footing with all other overloads. The current situation
seems too much like two-phase lookup in C++, which is a monstrosity that we at
least tried to kill off in D.

Regardless, it looks like different sets of function overload rules are mixing
very badly right now.

--