Operator overhaul

[BCS]

Reply to Andrei,

> 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.
> 
> Andrei
> 

I want to do:

typedef real MyReal(int i)
{
   MyReal!(i) opAdd(MyReal!(i));  //default impl 
}

If left without a body this would /only/ redefine the allowed operators and 
the types they result in. The actual code gen would be exactly the same. 
Allowing bodies might be cool.