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