Copy Constructor DIP

[Manu]

On Thu, 12 Jul 2018 at 06:45, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> 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.

Okay. Well, I guess that I just wanted some clarity on exactly what
'initialisation' looks like.

T b = a; // clearly initialisation, sure
T c = T(a); // c is initialised to a copy of an rvalue which was
initialised as a copy of a. Is there *two* calls to the copy
constructor here?

In this way, is an explicit call to the copy constructor is allowed?
You said it is, but the word "@implicit" makes it look like explicit
calls should be an arbitrary error; change the word at least.

C++ is a disaster zone these days with `T t = x;`  `T t = T(x);`  `T
t(x);`  `T t{x};`... I just wanna make sure we don't end up with
initialisation 'cases'.

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

Right, but as I've alluded to before, there's a loose relationship
here. C++ prescribes the 'rule of 3' (or 5). If we introduce copy
constructors, are we introducing those concepts?
I think introduction of those concepts may pull questions about
assignment into the definition space.

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

Okay. In that case, I really don't like the name.