Thread overview
[Issue 7535] Position of method in code inside class/struct decides that code is proper or invalid
Jun 26, 2017
Vladimir Panteleev
Dec 17, 2022
Iain Buclaw
November 18, 2014
https://issues.dlang.org/show_bug.cgi?id=7535

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh@quickfur.ath.cx

--- Comment #1 from hsteoh@quickfur.ath.cx ---
Bug is still present in git HEAD. Tested on Linux/64.

--
June 26, 2017
https://issues.dlang.org/show_bug.cgi?id=7535

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

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

--- Comment #2 from Vladimir Panteleev <dlang-bugzilla@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.

--
December 17, 2022
https://issues.dlang.org/show_bug.cgi?id=7535

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P3

--