Copy Constructor DIP

RazvanN razvan.nitu1305 at gmail.com
Wed Jul 11 07:37:16 UTC 2018


On Tuesday, 10 July 2018 at 20:58:09 UTC, Manu wrote:
> On Tue, 10 Jul 2018 at 03:50, RazvanN via Digitalmars-d 
> <digitalmars-d at puremagic.com> wrote:
>>
>> Hi everyone!
>>
>> I managed to put together a first draft of the DIP for adding 
>> the copy constructor to the language [1]. If anyone is 
>> interested, please take a look. Suggestions and comments about 
>> technical aspects and wording are all welcome.
>>
>> Thanks,
>> RazvanN
>>
>> [1] https://github.com/dlang/DIPs/pull/129
>
> I feel there's some things missing.
>
> 1. Explain the need and reasoning behind `@implicit`... that's 
> weird

It is a simple way of defining a copy constructor without the 
need of
adding new keywords and with minimal additions to the parser.

> and I don't like it at face value.
> 2. It looks like copy constructors are used to perform 
> assignments
> (and not constructions)... but, there is also opAssign. What 
> gives?
>     Eg:
>       S b = a; // <- copy construction? looks like an 
> assignment.
>     And not:
>       S b = S(a); // <- actually looks like a construction, but 
> this
> syntax seems to not be intended (and rightly so, it's pretty 
> terrible)
> 3. In C++, copy constructors and copy assignment operators come 
> in
> pairs (which is totally lame!), but we don't see that same 
> pattern
> extend here, and it's not clear at all why.
> 4. Given the special rules where assignments are lifted to
> constructions, I want to know when that occurs (maybe that is 
> already
> spec-ed wrt postblit?)
>
> - Manu

Copy construction is used solely when the object was not 
initialized and it
cannot be used otherwise. Consider this example:

struct A
{
     immutable int a = 7;
     @implicit this(ref A another)
     {
          this.a = A.a;      // first assignment over .init state 
- ok
     }

     void opAssign(A rhs)
     {
         this.a = rhs.a;
     }
}

void main()
{
     A a = A(2);
     A b = a;             //  initialization -> calls copy 
constructor
     b = a;               // cannot call copy constructor because 
it will
                          // modify immutable; call opAssign.
}

The first assignment of b calls the copy constructor and the 
immutable field is
initialized; later assignments to b.a will result in "modify 
immutable" error.
The second assignment of b cannot call the copy constructor 
because it would then modify an initialized immutable field. 
However, with opAssign the compiler knows that A.a cannot be 
modified because it is immutable.



More information about the Digitalmars-d mailing list