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.


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

Reply via email to