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

[Boris-Barboris]

On Saturday, 5 January 2019 at 13:34:09 UTC, RazvanN wrote:
> On Friday, 21 December 2018 at 14:43:50 UTC, Boris-Barboris 
> wrote:
> As it was stated above, the transitive nature of const and 
> immutable
> makes it impossible to safely copy objects with indirections. 
> If you do
> not want to modify the source, then don't modify it from the 
> copy constructor.
> This can be seen as a feature, not a bug.

1). I personally do not want such feature, I find it dangerous.
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.
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.


> 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.