Proposal: Operator overloading without temporaries

[Sean Kelly]

Don Clugston wrote:
> Background: Operator overloading, in the form it exists in C++ and 
> currently in D, inherently results in sub-optimal code, because it 
> always results in unnecessary temporary objects being created.
...
> If this were implemented, it would permanently eradicate (for D) the 
> most significant advantage which Fortran has managed to retain over 
> object-oriented languages. And I really don't think it would be 
> difficult to implement, or have negative side-effects.

Very nice.  And much better than expression templates.  I'm all for it.

> There are a couple of decisions to be made:
> (I) should the compiler use opAdd() and generate a temporary, if 
> opAddAssign_r() doesn't exist, to preserve existing behaviour? I think 
> the answer to this is YES.

Yes.

> (II) should the compiler use opAdd() and generate a temporary, if 
> oppAddAssign() doesn't exist, to preserve existing behaviour? Again, I'm 
> inclined to answer YES.

Yes.

> (III) If the code includes +=, and there is an opAdd() but no 
> opAddAssign(), should the compiler accept this, and just generate an 
> opAdd() followed by an assignment?? This would mean that opAdd() would 
> generate the += operation as well as +, while opAddAssign() would be a 
> performance enhancement. (It would still be possible to have 
> opAddAssign() without opAdd(), to have += but not +, but it would not be 
> possible to have + without +=). This would mean that += would be 
> *purely* syntactic sugar.
> 
> Decision III would be a little more difficult to implement and is of 
> less obvious merit, I only mention it as a possibility.

I'd say no to this initially, and see how things sort out.  It may be 
that this turns out to be desirable and it may not.  But theoretically, 
I'd prefer to know when an OpAssign fn is required that I haven't 
provided than to have the compiler silently accept the syntax anyway.


Sean