DMD 0.177 release

[Walter Bright]

Stewart Gordon wrote:
> Walter Bright wrote:
>> Stewart Gordon wrote:
>>> Walter Bright wrote:
>>>> I don't think that'll work. He'll wind up being forced to set all 
>>>> the fields.
>>> Doesn't follow - there might not be any to set other than those that are
>>> an inherent part of the assignment operation.
>>
>> But if there *are* other fields that shouldn't be set, a rule to 
>> preclude those cases would be a problem.
> 
> Exactly.  *If* there are other fields that shouldn't be set.  Do you 
> even understand a word of what Chris is proposing?
> 
> The programmer would have a choice - opAssign returning void to modify 
> in-place the object referenced by the lvalue, or returning a new object 
> that will be assigned to the lvalue.  What is this precluding?

opAssign has 3 externally visible characteristics:

1) the parameter
2) the 'this' pointer
3) the return value

Your proposal mixes up 2 and 3. opAssign works like:

	a = b
becomes:
	a.opAssign(b)

The return value is not assigned to a, it is the value of the expression 
(a = b). Mixing up the return value and the assignment to a will cause 
problems, as the two are different things, and should be independent.