Copy Constructor DIP

[Andrei Alexandrescu]

On 07/10/2018 06:50 PM, Manu wrote:
> On Tue, 10 Jul 2018 at 15:23, Jonathan M Davis via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>>
>> On Tuesday, 10 July 2018 14:58:09 MDT Manu via Digitalmars-d wrote:
>>> 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)
>>
>> S b = a;
>>
>> has never been assignment in either C++ or D. It's initialization /
>> construction, which means that it calls a constructor - be that a postblit
>> constructor or a copy constructor. Assignment only occurs when you're giving
>> an existing object a new value.
> 
> I know this, but it's not syntactically obvious, it just depends on
> the fact that you already know that fact... I feel a DIP about copy
> construction needs to have some text explaining that, and where the
> edges are.

The DIP is not a tutorial on existing related parts of the language. 
Copy initialization has been distinct from assignment for a long time in 
both C++ and D languages.

> Is an initialisation assignment can use a copy constructor, why can't
> a normal assignment implicitly use a copy constructor? (implicit
> destruct then copy-construct)

Because assignment and construction were, and are, distinct operation. 
There is no need for the DIP to explain.

>> And why would
>>
>> S b = S(a);
>>
>> not be intended? Sure, it's kind of pointless if a is an S, but if you have
>> a copy constructor, it makes perfect sense that S(a) would work and would be
>> pretty bizarre if it didn't, since it's explicitly calling the copy
>> constructor.
> 
> But there's a super explicit `@implicit` thing written right there...
> so should we expect that an *explicit* call to the copy constructor is
> not allowed? Or maybe it is allowed and `@implicit` is a lie?

The "@implicit" attribute does not preclude explicit calls. Razvan: you 
may want to mention that.

>> It even works right now if you give S a constructor that takes
>> an S. It just isn't actually treated as a proper copy constructor at the
>> moment, since that's currently the postblit constructor's job.
> 
> Current language doesn't have `@implicit` written anywhere...

Misunderstanding that I assume has been cleared by now.


Andrei