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

[Max Haughton]

On Wednesday, 10 March 2021 at 22:51:58 UTC, 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"?

I'm still fairly open minded about this, however aesthetically at 
least I really like the idea of move semantics being fairly 
invisible - e.g. it's not passing a struct by move but rather 
being up to the struct. When you take into account the object 
lifetime in a move it's not pass by value of reference.

Definitely needs to be carefully considered.