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

[tsbockman]

On Friday, 12 March 2021 at 19:50:57 UTC, Atila Neves wrote:
> On Wednesday, 10 March 2021 at 22:51:58 UTC, tsbockman wrote:
>> 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.
>
> I didn't object to the syntax,

I didn't mean to imply that you objected, just that you confirmed 
that by-value parameter syntax is being used where the parameter 
is actually semantically by-reference.

> especially since it's the same syntax used right now for moves.

No, it's not. You are conflating "moves" with "custom move 
operators definitions", a proposed implementation detail of the 
lowering for actual moves.

This is the syntax for moves and copies, depending on the 
surrounding context:

     B b = a;
     C c = b;
     return f(c);

The closest thing we have to a dedicated move syntax is this:

     import std.algorithm.mutation : move;
     move(a, b);

As for the proposed move operator syntax - no, we do not 
currently use that syntax for move operators. None of the various 
methods of moving things call them:

//////////////////////////////
struct S {
     int x;
     this(int x) @safe {
         this.x = x; }
     this(S s) @safe {
         x = s.x * 2; }
     void opAssign(S s) @safe {
         x = -s.x; }
}

S g(S s) {
     return s; }

void main() @system {
     import std.stdio : writeln;
     import std.algorithm.mutation : move;

     S s = 1, t = s, u;
     writeln(t);
     move(t, u);
     writeln(u);
     writeln(g(u));
}
//////////////////////////////

Output:

     S(1)
     S(1)
     S(1)

Even if I manually call S.opAssign, a copy is performed for the 
parameter, so it's *really* not a move operator. We don't have 
custom move operators at all right now; that's the point of this 
DIP, isn't it?