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

Simen Kjaeraas <simen.kjaras@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |simen.kjaras@gmail.com
         Resolution|---                         |DUPLICATE

--- Comment #1 from Simen Kjaeraas <simen.kjaras@gmail.com> ---


*** This issue has been marked as a duplicate of issue 12578 ***

--

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

--- Comment #2 from Victor Porton <porton@narod.ru> ---
This was marked duplicate as a duplicate of issue 12578. But I suggest to fix this issue (namely with property functions) independently on whether 12578 will be fixed. This issue can be fixed even is 12578 cannot or hard to fix (in the general case), because property functions are not "in fact" overloaded (in the call syntax).

--

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

--- Comment #3 from Simen Kjaeraas <simen.kjaras@gmail.com> ---
There is nothing special about @property functions in terms of overload resolution - they use the exact same code as other functions. For instance, this is perfectly valid:

@property
int fun() { return 0; }
@property
int fun(int value) { return 1; }
@property
int fun(string value) { return 2; }

unittest {
    auto a = fun;
    fun = 13;
    fun = "twenty-seven";
}

Fixing this issue for @property functions only will require duplicating code, complicating the compiler. It will also require fixing the exact issue in 12578, and then choosing not to apply the fix to other functions.

An argument could be made that the error message could be better. At least, it could be made to match the error message for same-name globals:

int i;
string i; //  variable foo.i conflicts with variable foo.i at foo.d(1)

--