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

[Boris-Barboris]

On Saturday, 22 December 2018 at 03:37:22 UTC, Rubn wrote:
> On Saturday, 22 December 2018 at 00:08:51 UTC, Boris-Barboris 
> wrote:
>
> The DIP goes over why const wasn't used for the source. 
> Consider the following:
>
> struct A {
>     int* ptr;
> }
>
> Now to simulate the copy constructor:
>
> A copy(ref const A a) {
>     A result;
>     result.ptr = a.ptr; // error can't convert `const int*` to 
> `int*`
>     return result;
> }
>
> Const is infectious and just causes more problems making it 
> pretty much useless in the general case. It's only suitable for 
> a very narrow use case. A lot of people using D avoid const 
> entirely, except for really basic simple things involving 
> primitive types.

Exactly my intent, to cause problems in this case and force a 
cast.

For example, your code is actually not performing a copy of A. 
Your copy constructor is making a shallow copy, by duplicating 
only one vertex of the memory graph. If you were actually copying 
it, you would allocate a new int on the heap and initializa it 
from the const source.ptr without a problem.

Current blitting is perfect for shallow copies as it is.

If we are to give default semantical meaning to the copy 
constructor, that the programmer can generally rely on in the 
unfamiliar codebase, we need to restrict the developer. If we are 
to give it a semantic meaning of the function where you do 
whatever you want with source and dest, why should we call it a 
COPY constructor?