opXAssign overloading

[Don]

Robert Jacques wrote:
> On Tue, 13 Oct 2009 00:31:32 -0400, dsimcha <dsimcha at yahoo.com> wrote:
> 
>> It seems that D's operator overloading is a bit silly in some cases 
>> w.r.t.
>> opAddAssign, opSubAssign, etc.  Consider the following example:
>>
>> struct Foo {
>>     Foo opAdd(Foo rhs) {
>>         return this;
>>     }
>> }
>>
>> void main() {
>>     Foo foo;
>>     Foo bar;
>>     foo = foo + bar;  // Works.
>>     foo += bar;  // Doesn't work.
>> }
>>
>> I'm thinking (not sure if this was proposed here before a while back 
>> and I
>> just forgot where I heard it from) that the default behavior of
>> someObject.opXAssign(otherStuff); should be to expand into someObject =
>> someObject.opX(otherStuff); if opXAssign is not overloaded.  Besides the
>> programmer being too lazy to explicitly overload opXAssign, I just found
>> another use case.
>>
>> Suppose you have a bunch of classes and you're overloading operators 
>> such that
>> each call builds another layer of decorators.  For example:
>>
>> class SomeClass {
>>     SomeClass opAdd(SomeClass rhs) {
>>        // SomeDecorator is a subclass of SomeClass.
>>        return new SomeDecorator(this, rhs);
>>     }
>> }
>>
>> In this case, you *can't* overload SomeClass.opAddAssign in any 
>> reasonable way
>> because you can't assign SomeDecorator to this, but translating
>> someInstance.opAddAssign(someOtherInstance) into someInstance =
>> someInstance.opAdd(someOtherInstance) makes perfect sense.
> 

> Also, if you template both opX and opX_r you will always get a overload 
> conflict.

Yes, I posted a patch for that to the ng. It's very simple.


There has been some discussion as to whether arithmetic operator 
overloading makes sense at all for reference types. My feeling is that 
if  x = x + y; has a different meaning to x += y; then operator 
overloading doesn't make sense.

But, perhaps with the decorator idea you are close to having a use case 
for classes where operator overloading makes sense?