The problem with opX_r (or more powerful template specialization)

[Sean Kelly]

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.

> This would basically suggest that all opX_r operator overloads gets 
> demoted one priority step so that having both a matching opX and a 
> matching opX_r will pick the opX overload. Not as today, giving a 
> conflict error.

I suppose I really need to read up on D's operator overloading.  I had 
no idea this currently happened.


Sean