Operator overloading -- lets collect some use cases

[Don]

Andrei Alexandrescu wrote:
> Don wrote:
>> Frits van Bommel wrote:
>>> Don wrote:
>>>> Frits van Bommel wrote:
>>>>> Don wrote:
>>>>>> A straightforward first step would be to state in the spec that 
>>>>>> "the compiler is entitled to assume that X+=Y yields the same 
>>>>>> result as X=X+Y"
>>>>>
>>>>> That doesn't hold for reference types, does it?
>>>>
>>>> I thought it does? Got any counter examples?
>>>
>>> For any class type, with += modifying the object and + returning a 
>>> new one:
>>
>> Sure, you can do it (behaviour inherited from C++), but is that _EVER_ 
>> a good idea? I can't think of any cases where that's anything other 
>> than a bug-breeder.
>>
>>> You can't just arbitrarily substitute between these two.
>> I'm still looking for a use case where that substitution doesn't make 
>> sense. No-one has yet come up with such a use case. I postulate that 
>> it doesn't exist.
> 
> Well I forgot whether BigInt is a class, is it? Anyhow, suppose it *is* 
> a class and as such has reference semantics. Then a += b modifies an 
> object in-situ, whereas a = a + b creates a whole new object and happens 
> to bind a to that new object.

You're right, though BigInt is not a class. I have, though, seen a 
BigIntRef class (in Diemos, I think) which behaved in that way. AFAIK, 
the reason it existed was that the only way you can enforce value 
semantics in D1 is via copy-on-write, which results in many unnecessary 
heap allocations and copies.
So Fritz is correct, it could not be enforced for reference types.
The question then is, when are reference semantics desired for an object 
with arithmetical operator overloading?

For matrix slices, maybe? But even then I'm not certain you'd want to 
allow X=X+Y; you'd probably want to use X[]=X[]+Y[].