> What's wrong with:
> struct S {
>   this(ref S copyFrom);
> }
>
> That looks like a perfectly good copy constructor declaration ;) I'm just saying, the DIP needs to explain this.

That is actually a valid constructor, according to today's compiler. There
might be code out there that uses this syntax for the constructor and overnight
it will be turned into a copy constructor.

I agree that the current syntax is lacking. This was Andrei's proposition
and I was initially against it, but he said to put it in the DIP so that
we can discuss it as a community. Maybe this syntax is better:

@this(ref S a another)

It looks like the c++ copy constructor but the `@` makes it different from
a constructor, so we're good. What do you think?

> Right. This is all obvious and intuitive.
> What I'm hearing is that under this proposal, copy constructors and
> assignment operators DO come in pairs (just like in C++), but that's
> not mentioned here in this DIP. Since this proposal will introduce
> that recommended pattern from C++, it may be worth mentioning.

If by "come in pairs" you mean that you can define them both, then yes,
that is the case. Will add a paragraph in the DIP to specify this.

You mentioned that it's terrible that the assignment operator
and the copy constructor come in pairs. Why is that? Would you rather
have a copy constructor that is used also as an assignment operator?

> That's my point; so this is a compile error then:
> S b = S(a); // <- explicit construction of copy? ie, explicit call to
> stated `@implicit` function

Consider this code:

import std.stdio : writeln;

struct S
{

    this(this)
    {
        writeln("postblit");
    }
    int a;
    this(int a)
    {
        this.a = a;
    }

    this(ref S another)
    {
        writeln("calling this");
    }

}


void main()
{
    S a;
    S b = S(a);
}

In this situation, the constructor is called; if `this(ref S another)` is commented the code will result in a compilation error "constructor S.this(int) is not callable using argument types (S)", so the postblit is NOT called. In my opinion this is the desired behavior and should be implemented by the copy constructor also. If you are doing `S b = S(a)` then you are explicitly trying
to call a constructor; if it doesn't exist, then it's an error; if you wanted to call the copy constructor then you would have done `S b = a;`. Using S(a) states the intention of explicitly calling a constructor while the copy constructor can
only be called implicitly.

On 07/11/2018 05:55 AM, Nick Treleaven wrote:
> On Tuesday, 10 July 2018 at 10:47:04 UTC, RazvanN wrote:
>> [1] https://github.com/dlang/DIPs/pull/129
> 
> Thanks for making the DIP. I can't get this code to compile (my struct has an `int i` field):
> 
> static foreach (i, ref field; src.tupleof)
>      this.tupleof[i] = field;
> 
> Error: constant value src.i cannot be ref
> 
> https://run.dlang.io/is/qeugC8
> 
> Removing `static` works. Otherwise I tried changing `ref` to `alias`:
> 
> Error: variable src cannot be read at compile time
> 
> But this shorter code seems to work fine:
> 
> this.tupleof = src.tupleof;

Odd. Timon, what would be the reason for that error? Razvan, can you please look into removing "static" for now. Thanks!

On 07/10/2018 04:58 PM, 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`.

Razvan: I think it would help to explain that the attribute is necessary to avoid changing semantics of existing code. Thanks.

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

The proposal does not affect or interfere with opAssign in any way.

> 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?)

What special rules are you referring to? Thanks.

On 07/10/2018 06:50 PM, Manu wrote:
> On Tue, 10 Jul 2018 at 15:23, Jonathan M Davis via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>>
>> On Tuesday, 10 July 2018 14:58:09 MDT Manu via Digitalmars-d wrote:
>>> 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)
>>
>> S b = a;
>>
>> has never been assignment in either C++ or D. It's initialization /
>> construction, which means that it calls a constructor - be that a postblit
>> constructor or a copy constructor. Assignment only occurs when you're giving
>> an existing object a new value.
> 
> I know this, but it's not syntactically obvious, it just depends on
> the fact that you already know that fact... I feel a DIP about copy
> construction needs to have some text explaining that, and where the
> edges are.

The DIP is not a tutorial on existing related parts of the language. Copy initialization has been distinct from assignment for a long time in both C++ and D languages.

> Is an initialisation assignment can use a copy constructor, why can't
> a normal assignment implicitly use a copy constructor? (implicit
> destruct then copy-construct)

Because assignment and construction were, and are, distinct operation. There is no need for the DIP to explain.

>> And why would
>>
>> S b = S(a);
>>
>> not be intended? Sure, it's kind of pointless if a is an S, but if you have
>> a copy constructor, it makes perfect sense that S(a) would work and would be
>> pretty bizarre if it didn't, since it's explicitly calling the copy
>> constructor.
> 
> But there's a super explicit `@implicit` thing written right there...
> so should we expect that an *explicit* call to the copy constructor is
> not allowed? Or maybe it is allowed and `@implicit` is a lie?

The "@implicit" attribute does not preclude explicit calls. Razvan: you may want to mention that.

>> It even works right now if you give S a constructor that takes
>> an S. It just isn't actually treated as a proper copy constructor at the
>> moment, since that's currently the postblit constructor's job.
> 
> Current language doesn't have `@implicit` written anywhere...

Misunderstanding that I assume has been cleared by now.


Andrei

On 07/11/2018 11:11 AM, Atila Neves wrote:
> On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote:
>>> But there's a super explicit `@implicit` thing written right there... so should we expect that an *explicit* call to the copy constructor is not allowed? Or maybe it is allowed and `@implicit` is a lie?
>>
>> The @implicit is there to point out that you cannot call that method
>> explicitly; it gets called for you implicitly when you construct an object
>> as a copy of another object.
> 
> How is this different from other types of constructors or destructors?

The main difference is that the compiler may insert calls to it implicitly.

> I also very much dislike the syntax - it makes no sense to me at all. I commented on the PR itself asking why it differs so much from C++ - specifically, what's bad about the C++ way of doing things there that we want to avoid?

C++ is at the other end of the spectrum - constructors are too implicit, so the "explicit" keyword has been introduced with the advice to use it in the vast majority of cases. If C++ could do it again, it would make everything explicit and add an "implicit" keyword.

On 07/11/2018 12:19 PM, vit wrote:
> On Wednesday, 11 July 2018 at 07:40:32 UTC, RazvanN wrote:
>>> But there's a super explicit `@implicit` thing written right there... so should we expect that an *explicit* call to the copy constructor is not allowed? Or maybe it is allowed and `@implicit` is a lie?
>>
>> The @implicit is there to point out that you cannot call that method
>> explicitly; it gets called for you implicitly when you construct an object
>> as a copy of another object.
> 
> Can be explicit constructor overloaded with implicit constructor when both have same signature?

Thanks for this. Yes we need to add a mention.

On 07/11/2018 05:28 PM, Manu wrote:
> What's wrong with:
> struct S {
>    this(ref S copyFrom);
> }
> 
> That looks like a perfectly good copy constructor declaration ;)
> I'm just saying, the DIP needs to explain this.

Thanks, worth a paragraph discussing silent semantics change.

> Right. This is all obvious and intuitive.
> What I'm hearing is that under this proposal, copy constructors and
> assignment operators DO come in pairs (just like in C++), but that's
> not mentioned here in this DIP. Since this proposal will introduce
> that recommended pattern from C++, it may be worth mentioning.

Shouldn't hurt to add 1-2 sentences to the effect. (Also an example.)

On 07/12/2018 02:54 AM, RazvanN wrote:
>> What's wrong with:
>> struct S {
>>   this(ref S copyFrom);
>> }
>>
>> That looks like a perfectly good copy constructor declaration ;) I'm just saying, the DIP needs to explain this.
> 
> That is actually a valid constructor, according to today's compiler. There
> might be code out there that uses this syntax for the constructor and overnight
> it will be turned into a copy constructor.
> 
> I agree that the current syntax is lacking. This was Andrei's proposition
> and I was initially against it, but he said to put it in the DIP so that
> we can discuss it as a community. Maybe this syntax is better:
> 
> @this(ref S a another)
> 
> It looks like the c++ copy constructor but the `@` makes it different from
> a constructor, so we're good. What do you think?

We will not add syntax if we can help it.

On Thursday, 12 July 2018 at 06:54:37 UTC, RazvanN wrote:

> [...]

> If by "come in pairs" you mean that you can define them both, then yes,
> that is the case. Will add a paragraph in the DIP to specify this.
>
> You mentioned that it's terrible that the assignment operator
> and the copy constructor come in pairs. Why is that? Would you rather
> have a copy constructor that is used also as an assignment operator?

Because, like in C++, now you have to implement both and make sure they do the same thing. Boilerplaty and a recipe for disaster.

Atila