https://issues.dlang.org/show_bug.cgi?id=12698
Jonathan M Davis <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #1 from Jonathan M Davis <[email protected]> --- 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. --
