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