Hello everyone,

I have finished writing the last details of the copy constructor DIP[1] and also I have published the first implementation [2]. As I wrongfully made a PR for the DIP queue in the early stages of the development of the DIP, I want to announce this way that the DIP is ready for the draft review now. Those who are familiar with the compiler, please take a look at the implementation and help me improve it!

Thanks,
RazvanN

[1] https://github.com/dlang/DIPs/pull/129
[2] https://github.com/dlang/dmd/pull/8688

On 12/09/2018 3:08 AM, RazvanN wrote:
> Hello everyone,
> 
> I have finished writing the last details of the copy constructor DIP[1] and also I have published the first implementation [2]. As I wrongfully made a PR for the DIP queue in the early stages of the development of the DIP, I want to announce this way that the DIP is ready for the draft review now. Those who are familiar with the compiler, please take a look at the implementation and help me improve it!
> 
> Thanks,
> RazvanN
> 
> [1] https://github.com/dlang/DIPs/pull/129
> [2] https://github.com/dlang/dmd/pull/8688

Here is a question (that I don't think has been asked) why not @copy?

@copy this(ref Foo other) { }

It can be read as copy constructor, which would be excellent for helping people learn what it is doing (spec lookup).

Also can we really not come up with an alternative bit of code than the tupleof to copying wholesale? E.g. super(other);

On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole wrote:
> Here is a question (that I don't think has been asked) why not @copy?

It's not wrong to call this an implicit constructor since it's called implicitly. It also means that, if we get implicit constructors in general, we can keep the same syntax and annotations, and it will be consistent.

> Also can we really not come up with an alternative bit of code than the tupleof to copying wholesale? E.g. super(other);

That would be possible, but it would be inconsistent with super constructors in general.

This should probably have been posted here. -- Andrei

-------- Forwarded Message --------
Subject: Copy Constructor DIP and implementation
Date: Tue, 11 Sep 2018 15:08:33 +0000
From: RazvanN <razvan.nitu1305@gmail.com>
Organization: Digital Mars
Newsgroups: digitalmars.D.announce

Hello everyone,

I have finished writing the last details of the copy constructor DIP[1] and also I have published the first implementation [2]. As I wrongfully made a PR for the DIP queue in the early stages of the development of the DIP, I want to announce this way that the DIP is ready for the draft review now. Those who are familiar with the compiler, please take a look at the implementation and help me improve it!

Thanks,
RazvanN

[1] https://github.com/dlang/DIPs/pull/129
[2] https://github.com/dlang/dmd/pull/8688

On 9/11/2018 8:08 AM, RazvanN wrote:
> [1] https://github.com/dlang/DIPs/pull/129
> [2] https://github.com/dlang/dmd/pull/8688

Thank you, RazvanN!

On Tuesday, 11 September 2018 at 15:08:33 UTC, RazvanN wrote:
> Hello everyone,
>
> I have finished writing the last details of the copy constructor DIP[1] and also I have published the first implementation [2]. As I wrongfully made a PR for the DIP queue in the early stages of the development of the DIP, I want to announce this way that the DIP is ready for the draft review now. Those who are familiar with the compiler, please take a look at the implementation and help me improve it!
>
> Thanks,
> RazvanN
>
> [1] https://github.com/dlang/DIPs/pull/129
> [2] https://github.com/dlang/dmd/pull/8688

I'm not sure about the naming of `@implicit` attribute. It seems confusing when used. `@copy` feels more natural or do we even need a new attribute at all?

On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole wrote:
>
> Here is a question (that I don't think has been asked) why not @copy?
>
> @copy this(ref Foo other) { }
>
> It can be read as copy constructor, which would be excellent for helping people learn what it is doing (spec lookup).
>
> Also can we really not come up with an alternative bit of code than the tupleof to copying wholesale? E.g. super(other);

I could not agree more. @implicit can mean many things, while @copy is much more specific... For what is worth I vote for @copy ! :)

On Tuesday, 11 September 2018 at 23:56:56 UTC, Walter Bright wrote:
> On 9/11/2018 8:08 AM, RazvanN wrote:
>> [1] https://github.com/dlang/DIPs/pull/129
>> [2] https://github.com/dlang/dmd/pull/8688
>
> Thank you, RazvanN!

I very much agree!

On Wednesday, 12 September 2018 at 11:39:21 UTC, Dejan Lekic wrote:
> On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole wrote:
>>
>> Here is a question (that I don't think has been asked) why not @copy?
>>
>> @copy this(ref Foo other) { }
>>
>> It can be read as copy constructor, which would be excellent for helping people learn what it is doing (spec lookup).
>>
>> Also can we really not come up with an alternative bit of code than the tupleof to copying wholesale? E.g. super(other);
>
> I could not agree more. @implicit can mean many things, while @copy is much more specific... For what is worth I vote for @copy ! :)

@implicit makes sense if extending explicitly implicit calls to all other constructors gets somday considered. Some people argued for it and I agree with them that it'd be nice to have, for ex. to make a custom string struct type usable without having to smear the code with constructor calls.

On Wednesday, September 12, 2018 10:04:57 AM MDT Elie Morisse via Digitalmars-d-announce wrote:
> On Wednesday, 12 September 2018 at 11:39:21 UTC, Dejan Lekic
>
> wrote:
> > On Tuesday, 11 September 2018 at 15:22:55 UTC, rikki cattermole
> >
> > wrote:
> >> Here is a question (that I don't think has been asked) why not
> >> @copy?
> >>
> >> @copy this(ref Foo other) { }
> >>
> >> It can be read as copy constructor, which would be excellent for helping people learn what it is doing (spec lookup).
> >>
> >> Also can we really not come up with an alternative bit of code than the tupleof to copying wholesale? E.g. super(other);
> >
> > I could not agree more. @implicit can mean many things, while @copy is much more specific... For what is worth I vote for @copy ! :)
>
> @implicit makes sense if extending explicitly implicit calls to all other constructors gets somday considered. Some people argued for it and I agree with them that it'd be nice to have, for ex. to make a custom string struct type usable without having to smear the code with constructor calls.

That's why some argued in a previous thread on the topic that we should decide what (if anything) we're going to do with adding implicit construction to the language before finalizing this DIP. If we added some sort of implicit constructor to the language, then @implicit would make some sense on copy constructors (it's still a bit weird IMHO, but it does make some sense when explained), and in that case, having used @copy could actually be a problem.

If we're looking at this as an attribute that's purely going to be used on copy constructors, then @copy does make more sense, but it's also less flexible. @implicit could potentially be used for more, whereas @copy really couldn't - not when it literally means copy constructor.

Personally, I'd rather that we just risk the code breakage caused by not having an attribute for copy constructors than use either @implicit or @copy, since it really only risks breaking code using constructors that were intended to be copy constructors but had to be called explicitly, and that code would almost certainly be fine if copy constructors then became implicit, but Andrei seems unwilling to do that. But at least, when start arguing about that, fact that the work "explicitly" very naturally fits into that as the description for what a copy constructor would be currently, it does make more sense that @implicit would be used.

Ultimately, I expect that if we add any attribute for this, people coming to D are going to think that it's downright weird, but if we're going to have one, if we go with @implicit, we're future-proofing things a bit, and personally, thinking about it over time, I've found that it feels less like a hack than something like @copy would. If we had @copy, this would clearly forever be something that we added just because we has postblit constructors first, whereas @implicit at least _might_ be used for something more. It would still feel weird and hacky if it never was used for anything more, but at least we'd be future-proofing the language a bit, and @implicit does make _some_ sense after it's explained, even if very few people (if any) will initially think that it makes sense.

- Jonathan M Davis