On Tuesday, 18 December 2018 at 14:51:39 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1018, "The Copy Constructor":
>
> [...]

At the risk of sounding noobish, the copy constructor is only being introduce for structs and not classes correct?

Alex

On Sunday, 6 January 2019 at 22:53:41 UTC, 12345swordy wrote:
> On Tuesday, 18 December 2018 at 14:51:39 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review for DIP 1018, "The Copy Constructor":
>>
>> [...]
>
> At the risk of sounding noobish, the copy constructor is only being introduce for structs and not classes correct?
>
> Alex

Yes.

On 2019-01-07 10:53, RazvanN wrote:
> On Sunday, 6 January 2019 at 22:53:41 UTC, 12345swordy wrote:
>> At the risk of sounding noobish, the copy constructor is only being
>> introduce for structs and not classes correct?
>
> Yes.

Why?

-- 
/Jacob Carlborg

On Mon, Jan 07, 2019 at 10:54:53PM +0100, Jacob Carlborg via Digitalmars-d wrote:
> On 2019-01-07 10:53, RazvanN wrote:
> > On Sunday, 6 January 2019 at 22:53:41 UTC, 12345swordy wrote:
> > > At the risk of sounding noobish, the copy constructor is only being introduce for structs and not classes correct?
> > 
> > Yes.
> 
> Why?

https://forum.dlang.org/post/56378A55.20505@erdani.com


T

-- 
My program has no bugs! Only undocumented features...

> Why would you need a default copy constructor? If there aren't any copy constructors defined, the compiler will just blit the fields. Generating


For the sake of consistency.
Imagine if the user explicitly calls or uses the address of the (generated) copy ctor,
then a struct change is made and the copy ctor is "no longer needed" because you can blit.
The user code that explicitly used the constructor is now broken.

> a single default copy constructor is not enough.

how about:

this(ref const T other);
immutable this(ref const T other);

On Wednesday, 9 January 2019 at 08:18:58 UTC, Dru wrote:
>> Why would you need a default copy constructor? If there aren't any copy constructors defined, the compiler will just blit the fields. Generating
>
>
> For the sake of consistency.
> Imagine if the user explicitly calls or uses the address of the (generated) copy ctor,
> then a struct change is made and the copy ctor is "no longer needed" because you can blit.
> The user code that explicitly used the constructor is now broken.

Consistency with what? How would you take the address of the copy constructor?
&a.__ctor? As you can see, you have to use the infamous `__` to do that so you should probably avoid it. Other than that what other use cases can be made for the generation of a default copy constructor and implicitly breaking most of the code that uses structs to pass by value to functions?

If you want to implicitly declare default copy constructors, you have to define all variants: mutable->mutable, const->const, immutable->immutable, shared->shared, all inout permutations etc. just to have backwards compatibility with the code that already uses structs. A horde of copy constructors to support a niche case. On the other hand, the current design is elegant as it does not touch already existent code and it generates copy constructors as they are indeed needed.

>> a single default copy constructor is not enough.
>
> how about:
>
> this(ref const T other);
> immutable this(ref const T other);

On 2019-01-07 23:53, H. S. Teoh wrote:

> https://forum.dlang.org/post/56378A55.20505@erdani.com

Would DIP1000 help with this?

-- 
/Jacob Carlborg

On Saturday, 5 January 2019 at 13:47:44 UTC, RazvanN wrote:
> On Saturday, 22 December 2018 at 16:40:47 UTC, Atila Neves wrote:
>> On Tuesday, 18 December 2018 at 14:51:39 UTC, Mike Parker wrote:
>>> This is the feedback thread for the first round of Community Review for DIP 1018, "The Copy Constructor":
>>>
>>> https://github.com/dlang/DIPs/blob/07da1f2cabc8b1bc3ad66034598a133e5ad13356/DIPs/DIP1018.md
>>>
>>> All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on January 4, or when I make a post declaring it complete. (This time I'm extending the review period by a few days because of the holidays.)
>>>
>>> At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of community review. Otherwise, it will be queued for the Final Review and Formal Assessment by the language maintainers.
>>>
>>> Please familiarize yourself with the documentation for the Community Review before participating.
>>>
>>> https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#community-review
>>>
>>> Thanks in advance to all who participate.
>>
>> I only realised that there would be a change to move semantics for structs that define a copy constructor at the end. Can one still manually move such structs? I'd like the DIP to go into that.
>
> I think that move and copy constructors are orthogonal concepts.

Perhaps, but moving and copying are not.

> I don't see how copy constructors may affect this.

I didn't either until the example in the DIP:

-----------
struct C { this(ref C) {} }
void fun(C c) {}
void main() {
    C c;
    fun(c);
}
-----------

c is moved before the DIP, and copied afterwards due to the existing constructor being considered a copy constructor.

> At this point, there is no move operator in D and the copy constructor is used only when a copy is made. If you are referring to Shackar Shamesh's DIP,

I wasn't referring to opMove, no, but I think adding a `this(C c)` constructor to the example would do it for rvalues?

On Wednesday, 9 January 2019 at 14:25:44 UTC, Atila Neves wrote:

> I didn't either until the example in the DIP:
>
> -----------
> struct C { this(ref C) {} }
> void fun(C c) {}
> void main() {
>     C c;
>     fun(c);
> }
> -----------
>
> c is moved before the DIP, and copied afterwards due to the existing constructor being considered a copy constructor.

C is not moved in this situation. The following code:

struct C { this(this) { import std.stdio; writeln("postblit"); } }
void fun(C c) {}
void main()
{
    C c;
    fun(c);
}

prints "postblit". Am I missing something?

> I wasn't referring to opMove, no, but I think adding a `this(C c)` constructor to the example would do it for rvalues?

The copy constructor is called solely on lvalues. `this(C c)` is a simple constructor that needs to be called explicitly.

An argument for your side:
It can be useful to check if a type is "blit able"
to do that we can check if a copy ctor does not exist.