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