On Tuesday, 10 July 2018 at 20:58:09 UTC, Manu wrote:
On Tue, 10 Jul 2018 at 03:50, RazvanN via Digitalmars-d
I managed to put together a first draft of the DIP for adding
the copy constructor to the language . If anyone is
interested, please take a look. Suggestions and comments about
technical aspects and wording are all welcome.
I feel there's some things missing.
1. Explain the need and reasoning behind `@implicit`... that's
It is a simple way of defining a copy constructor without the
adding new keywords and with minimal additions to the parser.
and I don't like it at face value.
2. It looks like copy constructors are used to perform
(and not constructions)... but, there is also opAssign. What
S b = a; // <- copy construction? looks like an
S b = S(a); // <- actually looks like a construction, but
syntax seems to not be intended (and rightly so, it's pretty
3. In C++, copy constructors and copy assignment operators come
pairs (which is totally lame!), but we don't see that same
extend here, and it's not clear at all why.
4. Given the special rules where assignments are lifted to
constructions, I want to know when that occurs (maybe that is
spec-ed wrt postblit?)
Copy construction is used solely when the object was not
initialized and it
cannot be used otherwise. Consider this example:
immutable int a = 7;
@implicit this(ref A another)
this.a = A.a; // first assignment over .init state
void opAssign(A rhs)
this.a = rhs.a;
A a = A(2);
A b = a; // initialization -> calls copy
b = a; // cannot call copy constructor because
// modify immutable; call opAssign.
The first assignment of b calls the copy constructor and the
immutable field is
initialized; later assignments to b.a will result in "modify
The second assignment of b cannot call the copy constructor
because it would then modify an initialized immutable field.
However, with opAssign the compiler knows that A.a cannot be
modified because it is immutable.