Operator overloading -- lets collect some use cases

[Weed]

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.

I am absolutely agree with that that the interfaces too are necessary
for structs.

But whether you by means of templates and mixin repeat an OOP
programming paradigm?