DMD 0.177 release
Walter Bright
newshound at digitalmars.com
Wed Dec 13 16:39:07 PST 2006
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.
More information about the Digitalmars-d-announce
mailing list