DMD 0.177 release

[Andrei Alexandrescu (See Website For Email)]

Walter Bright wrote:
> Andrei Alexandrescu (See Website for Email) wrote:
> 
>> That makes me wonder - if a = b is used without picking up its result 
>> (the usual case), and if opAssign() returns an S, will the compiler 
>> optimize away the extra copy at zero cost?
> 
> 
> No. The caller and callee don't know about each other.
> 
>> What I think happens is that the function will take a pointer to the 
>> destination which is zero, so a comparison will be made. But perhaps 
>> the optimizer will take care of eliminating that?
> 
> 
> You could have a null pointer passed to the return result, but that 
> would entail an extra check on the part of the callee.
> 
> This is why a lot of C++ code tends to return references instead of values.

I guess compiling internally two versions, one that returns S and one 
that returns void, might be worth looking into. Because right now user 
code for opAssign() can't be politically correct and efficient at the 
same time.

Here's a better alternative:

Require opAssign() to always return void and have the compiler return a 
reference to the left-hand side. That is, transform:

a = b;

into:

(a.opAssign(b), a);

with the mention that a only gets evaluated once.

This way assignment _always_ returns its left-hand side and user code 
cannot subvert that behavior. Also the code will be efficient because no 
more spurious copies are being made.


Andrei