A possible solution for the opIndexXxxAssign morass

[Steven Schveighoffer]

On Thu, 15 Oct 2009 02:58:51 -0400, Don <nospam at nospam.com> wrote:

> Andrei Alexandrescu wrote:
>> Also, the much-discussed identity:
>>  x @= y    <-->    x = x @ y
>>  is difficult to enforce statically in practice. I think some types  
>> would want to define both to achieve good efficiency. It would be hard  
>> for the compiler to render one unnecessary or to prove that the two are  
>> equivalent.
>
> Yes, it could not be enforced. But note that there would be no ambiguity  
> as to which should be used in any given expression.
> I would propose that the opXXXAssign() variants should exist *only* for  
> performance optimisation, and be completely divorced from the "+="  
> syntax (effectively, += would be discarded after the parsing step).
> My ancient Bugzilla proposal actually included opSubAssign() and  
> opSubAssign_r() for  x = x - y; and x = y - x;
> If   the x @= y    <-->    x = x @ y transformations became legal, this  
> would allow unnecessary temporaries to be completely eliminated.
>
> The suggested transformation would be that x = x + y would be  
> transformed into x.opAddAssign(y) whenever it exists, and x = y + x  
> would become x.opAddAssign_r(y)
> The transformations would therefore be entirely predictable.

Oh, I didn't realize that's what you meant.  I thought that opXxxAssign  
was to be eliminated and x += y was to be transformed into  
x.opAssign(x.opXxx(y).  I like this proposal better -- opXxxAssign can  
exist for optimization reasons, and enforcing the relationship between @=  
and = @ by parsing one into the other.

By parsing x += y into x = x + y, and allowing overloading of a chain of  
operations, you may even get more mileage out of something like x += y + z  
+ w;

Someone earlier suggested opXxx(a1, a2, ...) could be interpreted as an  
operator for dealing with chained operations.  You could also maybe have  
an opChain or something that takes as arguments the operands and the  
operators to maybe perform some optimization (i.e. like reordering matrix  
operations).

You should update your DIP to specify that opXxxAssign should be allowed  
for optimization purposes (BTW, classes could benefit from this, because  
then x += y *would* be the same as x = x + y).

-Steve