DIP 1018--The Copy Constructor--Community Review Round 1

[RazvanN]

On Saturday, 5 January 2019 at 14:03:34 UTC, Boris-Barboris wrote:
> 1). I personally do not want such feature, I find it dangerous.
I think that the discussion should transcend feelings and stick 
to what can be done.
> 2). That would make sense, if that was ever an ambiguous 
> choice. I cannot think of any case where you need to modify the 
> source outside of move operation, and that has nothing to do 
> with copy constructors. You are giving a choice in the 
> situation where only one, known answer is always right.
> We even know what's the problem is - our wonderful transitive 
> const, that proves itself inadequate for typical smart pointer 
> copying. Maybe instead of hacking in another poorly-integrated 
> feature, we should fix that first? There were plenty of topics 
> dedicated to head const semantics, why not address them now? It 
> will solve lots of other range-related problems as well.
I think that discussing whether const should be transitive or not 
is beyond the scope of this DIP.

> 3). As someone who would like to stick to C++, I think you 
> would say that you would feel right at home with the following 
> semantics:
>
> this(ref const typeof(this) rhs) - copy constructor
> this(ref typeof(this) rhs) - move constructor
>
> I'm not a fan of the proposed opMove.
>
But the opMove DIP proposes a different syntax: 
https://github.com/dlang/DIPs/pull/109/files#diff-50c61cb5afd3ffe27ddb9c5279fd9fc4R205

>
>> Agree, that was my initial design too, but in C++ you can 
>> define any number of
>> default parameters and people coming from that background 
>> might have some cases
>> where it is useful for them to have default parameters. Since 
>> this is the first
>> iteration of a copy constructor implementation, we should try 
>> to stick as much
>> as possible to the C++ design. Of course, in the case of const 
>> source we cannot
>> do that since const means something else in D.
>
> The key difference between copy\move constructors and other 
> constructors is that they are implicitly inserted by the 
> compiler in certain scenarios. Documentation that describes 
> such constructors should not be littered with alternative 
> exotic semantics that have nothing to do with implicitly 
> inserted function calls.
>
> this(ref typeof(this) rhs, int b) is just a constructor and 
> should not be mentioned anywhere in the copy constructor 
> documentation, nor in the DIP.

Since the copy constructor can also be used as a normal 
constructor (calling it explicitly), then there might be 
situations where you would need the extra parameters.