Can we fix reverse operator overloading (opSub_r et. al.)?

Lars T. Kyllingstad public at kyllingen.NOSPAMnet
Tue Jul 7 01:35:53 PDT 2009


Andrei Alexandrescu wrote:
> Don wrote:
>> Currently, template versions of opXXX_r appear to be useless.
>> Consider:
>>
>> struct A
>> {
>>    int opSub(T)(T x) { return 1; }
>>    int opSub_r(T)(T x) { return -1; }
>> }
>>
>> A a;
>> int x = a - a; // is this a.opSub(a) or a.opSub_r(a) ???
>>
>> This is annoying and rather silly. I can't imagine a case where you 
>> would template opXXX_r, without also templating opXXX. And by 
>> definition, a.opSub(a) is identical to a.opSub_r(a). Templated opSub_r 
>> has a broken design in both D1 and D2.
>>
>> We could fix it by adding a rule to operator overloading:
>>
>> [New rule] 1. If a and b have the same type, the expression is written 
>> as a.opfunc(b).
>> [Existing rules] 2. If any a.opfunc or b.opfunc_r functions exist, 
>> then overloading is applied across all of them and the best match is 
>> used.
>> ...
>>
>> Patching this is pretty easy. For example, in DMD2.031, opover.c, line 
>> 263, simply add:
>>
>>      if ((t1 == t2)) {
>>         //  x OP x can only be x.opOP(x), not x.opOP_r(x)
>>         s_r = NULL;
>>     }
> 
> Good point. This also reminds me that the entire operator overloading 
> feature must be thrown away and redesigned.
> 
> Andrei


I assume that means you haven't written the "operator overloading" 
chapter of your book yet? ;)

-Lars



More information about the Digitalmars-d mailing list