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

Rubn where at is.this
Sat Dec 22 13:51:52 UTC 2018

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

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.

More information about the Digitalmars-d mailing list