Operator overloading -- lets collect some use cases

[Don]

Weed wrote:
> Don пишет:
>> Weed wrote:
>>> Don пишет:
>>>> Weed wrote:
>>>>> Frits van Bommel пишет:
>>>>>> 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:
>>>>> The += operator too should return the object (usually "this")
>>>> ALWAYS 'this'. It's another feature of operator overloading which is
>>>> redundant.
>>>
>>> Not always. Can be more convenient to create the new object and to
>>> return it.
>>>
>>> For example: if it is necessary to return the object containing the
>>> sorted data those sorting hurriedly at creation of the returned object
>>> can give a scoring in performance than if the data is sorted in the
>>> current object after their change.
>> But then if you have
>>  y = x+=b;
>>
>> surely that would give you x and y being different?
>> Wouldn't you want x to also point to the new object? (OK, as Stewart
>> pointed out, you can't!) Otherwise, you have to perform _both_ sorts!
> 
> I agree, my point of view disputable.
> 
> The programmer can have a desire to return not current object: the
> returned and this will be equivalent but are not identical. Do not
> forget that this object may be not a class - it can be struct and such
> return can in certain to save a few resources.
> But if us will force to return this under the threat of a compile error
> I will not cry.:)
> 
> And you have certainly noticed that here the solution inaccuracy again
> appears to divide structures and classes by a principle "on value" and
> "reference". :)

Yah. They're almost the same, but not quite. It's interesting that value 
semantics are IMPOSSIBLE with classes (I didn't know that until 
Stewart's post), whereas reference semantics with structs are possible 
(but ugly) with structs.

In my experience with D, I use structs + templates far more frequently 
than classes + polymorphism. And I suspect that if interfaces were a bit 
more powerful and efficient, struct+interface might replace even more of 
the use cases for class-based run-time polymorphism. So I must admit, 
I'm quite biased against classes.