Discussion Thread: DIP 1040--Copying, Moving, and Forwarding--Community Review Round 1

[Arafel]

On 10/3/21 23:51, tsbockman wrote:
> On Friday, 5 March 2021 at 23:03:57 UTC, tsbockman wrote:
>> On Friday, 5 March 2021 at 12:19:54 UTC, Mike Parker wrote:
>>> This is the discussion thread for the first round of Community Review 
>>> of DIP 1040, "Copying, Moving, and Forwarding":
>>
>> From the DIP:
>>> A Move Constructor for struct S is declared as:
>>>     this(S s) { ... }
>>> A Move Assignment Operator for struct S is declared as:
>>>     void opAssign(S s) { ... }
>>
>> Is the parameter to these methods really pass-by-value?
>> ...
>> If the parameter is, in fact, intended to be pass-by-reference, then I 
>> must strenuously object to the chosen syntax.
> 
> Over in the feedback thread, Atila Neves also concluded that the syntax 
> is misleading here:
> 
> On Wednesday, 10 March 2021 at 21:27:25 UTC, Atila Neves wrote:
>> I eventually understood what this meant, but this confused me when I 
>> read it the first time. I'd reword it to mention that the syntax looks 
>> like a by-value parameter but ends up being passed by reference. It 
>> also confused me that the 2nd function had `ref` in there.
> 
> Am I the only one who thinks that it would be better to have syntax that 
> accurately reflects the semantics, instead of just documenting "this 
> syntax is a lie"?

There is another issue with the proposed semantics, unless I'm missing 
something.

How can I implement both an "identity assignment operator" [1] and a 
"move assignment operator"? The proposed syntax is co-opting an existing 
pattern for a different use case.

Let's say I have a struct that includes an associative array, where I 
implement deep copy for the assignment operator.

Will in this case my deep copy be reused automatically for movement? 
That's obviously not what I want, for that I'd just want to copy the 
reference to the existing AA.

If anything, this should be added to the breaking changes and 
deprecations, or at least mentioned as something to check for.

I could have used a `ref` parameter, but this wouldn't work with 
rvalues, and in any case the syntax is currently allowed, unlike 
constructors (bug 20424 [2]) which are mentioned in the DIP... although 
even there I tend to agree with comment #5, but I digress.

[1]: https://dlang.org/spec/operatoroverloading.html#assignment
[2]: https://issues.dlang.org/show_bug.cgi?id=20424