The problem with opX_r (or more powerful template specialization)

[Bruno Medeiros]

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. The 
ones that have secondary priority are the commutative ones 
(commutative-direct, commutative-reverse), if the operator allows 
commutation.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D