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