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

[tsbockman]

On Wednesday, 10 March 2021 at 23:00:35 UTC, Max Haughton wrote:
> 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) { ... }
>>
>> 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.

I agree that move semantics should be fairly invisible outside 
the custom move operators themselves, but I don't understand how 
that is an argument either for or against using the `ref` keyword 
like all other by-reference value type parameters must.

Either way the custom move operator (if one is needed) must be 
defined explicitly, and either way calls to it must be implicitly 
inserted by the compiler at special points that can only be 
correctly and completely predicted by understanding the rules in 
the DIP, and not from standard overload resolution rules.

> Definitely needs to be carefully considered.

Thank you for taking the time to do so. Please consider that the 
more that surprising special cases like this are added to the 
language, the harder it gets for non-experts to read and 
comprehend D code, for newcomers to learn the language, and 
especially for meta-programmers to write clean and correct code.

There is a consequence to adding exception to otherwise simple 
rules like, "Value type parameters that are passed by reference 
are labeled `ref` or `out`." In generic code (like most of 
Phobos) exceptions lead to bugs, bugs lead to frustration, 
frustration leads to `static if` branches, and too many `static 
if` branches leads to templates getting down-graded to string 
mixins (probably still with bugs).