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

[Max Haughton]

On Wednesday, 17 March 2021 at 06:35:16 UTC, vitamin 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":
>>
>> https://github.com/dlang/DIPs/blob/a9c553b0dbab1c2983a801b5e89b51c5c33d5180/DIPs/DIP1040.md
>
>
>
> Hello,
>
> I like this dip but, must be move/copy methods ctors? Because 
> there need to be distinctions between copy/move ctors and other 
> ctors, all copy/move ctors are non templates and that make some 
> problems.
>
> Something like opMoveCtor and opCopyCtor are easier 
> differentiate from others ctors and can be template:
>
> void opMoveCtor(T, this This)(T rhs){  //traits like 
> hasMoveConstructor can work without instantion of opMoveCtor
>
> }
>
> instead of
>
> this(typeof(this) rhs){/*...*/}
> this(const typeof(this) rhs)const {/*...*/}
> this(immutable typeof(this) rhs)immutable {/*...*/}
>
> //and all other combination including inout and sometimes 
> shared.

Some thoughts: ignore the implementation for now, but think about 
how the method based approach would change the language 
specification - the whole thesis of this particular DIP is 
(beyond move semantics themselves) to make move semantics (in a 
sense) more natural than the C++ solution, whereas with a method 
the decision to pass-by-move is now performed based on the 
presence of specific template arg to the operator.

Also it's a constructor, so why not call it one as we do now.

And for the specialisations, when you need to do these for the 
most part you end up doing them explicitly anyway (unless you are 
DbI-ing like a madman I guess).

Anyway those are my slightly rambling thoughts for now, more 
coming later.