[Issue 7535] Position of method in code inside class/struct decides that code is proper or invalid

via Digitalmars-d-bugs digitalmars-d-bugs at puremagic.com
Sun Jun 25 18:56:15 PDT 2017


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

Vladimir Panteleev <dlang-bugzilla at thecybershadow.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dlang-bugzilla at thecybershad
                   |                            |ow.net

--- Comment #2 from Vladimir Panteleev <dlang-bugzilla at thecybershadow.net> ---
I'm pretty sure this is not reasonably possible to make work.

The expression &operator.Dispatch is ambiguous, as it can refer to either the
static or non-static method. Now, the D compiler has some internal capabilities
of working with overload sets. However, in this case, this ambiguous expression
is passed as a template value parameter to opOpAssign. Because it is passed as
a regular parameter (and not e.g. alias), then it must have a type, so the
compiler is forced to pick one overload at this point (assuming this didn't
happen earlier, for the & operator). Only when the append occurs inside the
opOpAssign implementation can the overload set be reasonably resolved to the
one or other overload; however, at that point, the opOpAssign method had
already been instantiated with a concrete type, so it is too late to do
anything.

So, for this to work, the compiler would need to speculatively instantiate the
function with the type of each overload in the overload set, which would almost
surely be prohibitively complicated and expensive.

The other option would be to prefer non-static overloads when a class instance
(not just type) is supplied before the dot, however I believe that the overload
resolution rules are currently complicated enough to warrant this arguably
strange and easily avoidable use case.

I'll leave this open because picking an overload by a "whichever comes first"
rule is problematic - probably neither of the presented test cases should
compile.

--


More information about the Digitalmars-d-bugs mailing list