Operator overhaul

[Don]

Andrei Alexandrescu wrote:
> bearophile wrote:
>> Andrei Alexandrescu:
>>> There would be composition (of the kind usually addressed through 
>>> expression templates), but we don't have a good solution to that
>>> yet.
>>
>> You really want to make D an awesome language :-)
>>
>> I though that in D the expression templates stuff was left to be done
>> by the AST macros, but if they don't come until D3, then a more
>> specialized functionality may be used in the meantime... (if
>> necessary even to be later removed in D3).
> 
> I agree. Anyhow, the floor is open for suggestions on how to overhaul 
> the entire operator business. I'll tell you what is, to me, clearly dead 
> wrong: whenever one implements any class that wants to overload a bunch 
> of operators (number-like classes etc.) inevitably it boils down to 
> repetitive code like this:
> 
> struct Whatever
> {
>     Whatever opAdd(Whatever rhs) { return member + rhs.member; }
>     Whatever opSubtract(Whatever rhs) { return member - rhs.member; }
>     ...
> }
> 
> and lines and lines of brain damaged repetition, repetition, repetition. 
> If we add opWhateverAssign that will get even worse. The challenge is, 
> then, to define a way to overload operators that makes the classic 
> applications of the feature short and sweet.

My earlier contribution is in bugzilla 124, which would eliminate all 
unnecessary temporaries, though it doesn't address the repetitive code 
issue (in fact it makes the repitition slightly worse).

It seems clear that we need to restrict some of the useless freedoms 
that exist at present:
(1) a OP= b  _must_ mean a = a OP b (allowing the compiler to convert 
from one to the other);
(2) The return value of x OP= y must be x.

Beyond this it's not quite so obvious.

I wish we could get rid of opPostInc/Dec, with their ridiculous 
semantics. (Convert it to preInc, generate an error if the return value 
is used).