opXAssign overloading

[Bill Baxter]

On Tue, Oct 13, 2009 at 2:30 AM, Don <nospam at nospam.com> wrote:
> 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?

Well, I have implemented an N-d array-like type as a class before.
I don't think it's the best way to do it, but someone might like to
have a general array class they could override to behave as a matrix.
There is such a thing in Numpy.  I don't think it's the greatest idea
in the world, but if you do make such a thing, then you want to be
able to make += identity preserving and = not.   And that's how stuff
works in Python in general.   += modifies an object,  = changes its
identity.    So I wouldn't say it's nonsense to have such a rule.
What you can say is that this better be true (to within numerical
precision)

x1 = x + y
x += y
 ==>  x1 == x

--bb
x+