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

[Rubn]

On Saturday, 22 December 2018 at 09:01:09 UTC, Boris-Barboris 
wrote:
> 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.

Blitting can't copy from one object type to another though. This 
constructor will be able to do that.

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

Sure it's not a very accurate name, changing the name to be 
something else is fine. Just don't change the implementation to 
require const and make it that much harder to use.