On Tuesday, 10 July 2018 at 20:58:09 UTC, Manu wrote:
On Tue, 10 Jul 2018 at 03:50, RazvanN via Digitalmars-d
<digitalmars-d@puremagic.com> wrote:
Hi everyone!
I managed to put together a first draft of the DIP for adding
the copy constructor to the language [1]. If anyone is
interested, please take a look. Suggestions and comments about
technical aspects and wording are all welcome.
Thanks,
RazvanN
[1] https://github.com/dlang/DIPs/pull/129
I feel there's some things missing.
1. Explain the need and reasoning behind `@implicit`... that's
weird
It is a simple way of defining a copy constructor without the
need of
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
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)
3. In C++, copy constructors and copy assignment operators come
in
pairs (which is totally lame!), but we don't see that same
pattern
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
already
spec-ed wrt postblit?)
- Manu
Copy construction is used solely when the object was not
initialized and it
cannot be used otherwise. Consider this example:
struct A
{
immutable int a = 7;
@implicit this(ref A another)
{
this.a = A.a; // first assignment over .init state
- ok
}
void opAssign(A rhs)
{
this.a = rhs.a;
}
}
void main()
{
A a = A(2);
A b = a; // initialization -> calls copy
constructor
b = a; // cannot call copy constructor because
it will
// 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
immutable" error.
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.
