On 05/21/2013 08:24 PM, Maxim Fomin wrote:
...
According to the spec (overload page and TDPL) operators are rewritten
specifically named *member* functions and calling *member* function is
not the same thing as syntax to call free functions like member
functions due to:
- non-member (UFCS) functions cannot be virtualized and overridden
- they do not appear in get members traits
- they cannot access all fields in general.
This is not too relevant for the current discussion since we are
discussing operator overloading using opDispatch, which can be a member
function.
Using your rewriting notation
Not really.
operator overloading is defined as (a -
expression, b - some member function other than opDispatch, c -
opDispatch): if (a && b) then a->b else error. Opdispatch is defined as:
if(!b && c) then b->c else error.
I guess I understand what you mean, but you are missing the
specification of Eg. the opSlice rewrite which would render the
discussion meaningful.
Also, the language spec does not suggest a differentiation as is present
in those rules between a and b.
So, compiler works according to the spec.
By the way, your logic for a->b->c leads to following flaw:
class A
{
void opSlice(){}
void opDispatch(){}
}
..
a[] // unconditionally calls opDispatch since '[]'->'opSlice'->'opDispatch'
Using your notation, if you assume there is both a rewrite
'[]'->'opSlice' and 'opSlice'->'opDispatch' then yes.
The assumption of existence of a rewrite 'opSlice'->'opDispatch' is what
introduces the flaw.
The spec correctly states that there is no 'opSlice'->'opDispatch'
rewrite in this case, as it can be resolved otherwise.
