DMD 0.177 release

[Andrei Alexandrescu (See Website for Email)]

Walter Bright wrote:
>> Why not just "C opAssign" and "S opAssign"? In the opCall discussion 
>> you said yourself that the return value will be optimized.
>>
>> Am I missing something?
> 
> Yes. The issue is that opAssign has both a return value *and* copies 
> values into it's 'this' pointer.

This is wrong. The assignment should return an lvalue, and the current 
semantics of opAssign do not allow that. Here is some code:

void Increment(inout int x) {
   ++x;
}

int a;
Increment(a = 5);

This code leaves a containing the value 6. This is because a is first 
assigned a 5, then a is passed __as an lvalue__ to Increment, which 
bumps it.

Now consider:

struct S {
   int a;
   S opAssign(int x) {
     a = x;
     return this;
   }
}

void Increment(inout S x) {
   ++x.a;
}

S a;
Increment(a = 5);

This is going to have very different (and useless and unwanted) semantics.

Again, the right thing to do: give the Caesar what belongs to the 
Caesar. Have the user do the assignment (and return void), and have the 
compiler pass the lhs lvalue around, when needed.


Andrei