The problem with opX_r (or more powerful template specialization)

[Sean Kelly]

Bruno Medeiros wrote:
> Sean Kelly wrote:
>> Oskar Linde wrote:
>>>
>>> 1) Change the opX_r overloading rules, so that
>>>
>>> opX_r(T)(T x) {...}
>>> opX(T)(T x) {...}
>>>
>>> can coexist. opX_r is picked only of no opX overload is found.
>>
>> I thought operators worked this way:
>>
>>     x = y - z;
>>
>> 1. Call y.opSub(z) if it exists.
>> 2. If not, call z.opSub_r(y).
>>
>> ie. I had thought that the opX_r operations were for situations where 
>> the called object was on the right-hand side of the operation.  
>> Assuming this were true, there should be no problem in having opX and 
>> opX_r coexist peacefully.
>>
> 
> Nope. From the spec:
> "1. The expression is rewritten as both:
> a.opfunc(b)
> b.opfunc_r(a)
> If any a.opfunc or b.opfunc_r functions exist, then overloading is 
> applied across all of them and the best match is used."
> 
> So those two forms (direct and reverse) compete on equal priority.

So if a implemented an opSub(b) and b implemented an opSub_r(a) I'd get 
a compiler error about an ambiguous overload?  This seems somewhat 
sub-optimal.  Why was it implemented this way?


Sean