opDispatch and operator overloads

[Timon Gehr]

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.