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

On Tuesday, 10 July 2018 at 10:47:04 UTC, RazvanN 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

Does it allow to remove the "T.init must always be valid for structs" rule?

On Tuesday, 10 July 2018 04:52:18 MDT Guillaume Piolat via Digitalmars-d wrote:
> On Tuesday, 10 July 2018 at 10:47:04 UTC, RazvanN 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
>
> Does it allow to remove the "T.init must always be valid for structs" rule?

Why would it? init is the state of the object before any constructor runs, and quite a few things rely on it. The fact that we've allowed default initialization to be disabled already causes plenty of problems as it is. It's occasionally useful, but it definitely complicates things. D was designed with the idea that every type has an init value.

What problem are you trying to solve here?

- Jonathan M Davis

I'm not keen on the added attribute.

Something along the lines of:

this(this; ref Foo foo) {}

might look a little better no?

And now no super special attribute to worry about parsing.

On Tuesday, 10 July 2018 at 11:58:53 UTC, Jonathan M Davis wrote:
>>
>> Does it allow to remove the "T.init must always be valid for structs" rule?
>
> Why would it? init is the state of the object before any constructor runs, and quite a few things rely on it. The fact that we've allowed default initialization to be disabled already causes plenty of problems as it is. It's occasionally useful, but it definitely complicates things. D was designed with the idea that every type has an init value.
>
> What problem are you trying to solve here?
>
> - Jonathan M Davis

None, I was just reacting to https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c09332349f43

Proper D structs almost require having a T.init that is valid, and in turn many public members may get to check for internal validity before doing things. This is in stark contrast to C++ where "proper" constructor is guaranteed so you don't check such validity.

What is a "correct" T.init for a mutex RAII struct? It is a null handle value. It's obviously an invalid value for any purpose, but the D wrapper has to be a valid struct.

On Tuesday, 10 July 2018 06:34:34 MDT Guillaume Piolat via Digitalmars-d wrote:
> On Tuesday, 10 July 2018 at 11:58:53 UTC, Jonathan M Davis wrote:
> >> Does it allow to remove the "T.init must always be valid for structs" rule?
> >
> > Why would it? init is the state of the object before any constructor runs, and quite a few things rely on it. The fact that we've allowed default initialization to be disabled already causes plenty of problems as it is. It's occasionally useful, but it definitely complicates things. D was designed with the idea that every type has an init value.
> >
> > What problem are you trying to solve here?
> >
> > - Jonathan M Davis
>
> None, I was just reacting to https://medium.com/@feepingcreature/d-structs-dont-work-for-domain-data-c0 9332349f43
>
> Proper D structs almost require having a T.init that is valid, and in turn many public members may get to check for internal validity before doing things. This is in stark contrast to C++ where "proper" constructor is guaranteed so you don't check such validity.
>
> What is a "correct" T.init for a mutex RAII struct? It is a null handle value. It's obviously an invalid value for any purpose, but the D wrapper has to be a valid struct.

It's not necessarily expected that all of the functions on T.init are going to work. It's the stuff like copying it, assigning it, destroying it, etc. that have to work (and aside from destruction, you can even @disable them if you need to). Not even toString actually needs to work. It's just that it's so common for folks to print values that it gets annoying when it doesn't work. And yes, if T.init does not match the invariant, then you can start running into problems, though it isn't necessarily fatal. Basically, in that case, you're forced to disable default initialization and avoid actually doing much with the init value.

Honestly though, the reason that I think that invariants are terrible has nothing to do with T.init specifically but with opAssign. The invariant gets checked before opAssign, and in many cases, this makes sense, but in the case where you're doing something like void initialization or using emplace on uninitialized memory, it blows up in your face if the garbage that happened to be in the struct didn't match the invariant. The same would happen if T.init does not pass the invariant, but T.init isn't required to hit the problem. It's the fact that you can't bypass the invariant when giving the object a new value that's the main problem. If both assignment and copying worked without checking the invariant, then invariants would be a _lot_ more useful. Unfortunately, when I argued about this quite a bit with regards to opAssign several years ago, Walter didn't agree at all. He thought that it was critical that the invariant be valid when opAssign was called - and there are cases where that's arguably true - but since it doesn't work once you try to do fancier stuff like emplace, I'm of the opinion that invariants are unfortunately a waste of time - even without getting into the issue of init values.

- Jonathan M Davis

On 07/10/2018 06:52 AM, Guillaume Piolat wrote:
> On Tuesday, 10 July 2018 at 10:47:04 UTC, RazvanN 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
> 
> Does it allow to remove the "T.init must always be valid for structs" rule?

That's not part of this proposal's charter.

On Tuesday, 10 July 2018 at 13:38:33 UTC, Jonathan M Davis wrote:
> He thought that it was critical that the invariant be valid when opAssign was called - and there are cases where that's arguably true - but since it doesn't work once you try to do fancier stuff like emplace, I'm of the opinion that invariants are unfortunately a waste of time - even without getting into the issue of init values.
>
> - Jonathan M Davis

moveEmplace bypasses opAssign, since it memcopies directly. However, it resets its source value to T.init... so if T.init isn't valid, you simply crash whenever the source value goes out of scope.

Using types with an invalid T.init feels like playing musical chairs with a crash. You can shuffle things around, and make some parts work, but *something* is always left crashing at the end.

On Tuesday, 10 July 2018 at 14:28:09 UTC, FeepingCreature wrote:
> On Tuesday, 10 July 2018 at 13:38:33 UTC, Jonathan M Davis wrote:
>> [...]
> Using types with an invalid T.init feels like playing musical chairs with a crash. You can shuffle things around, and make some parts work, but *something* is always left crashing at the end.

This is where I feel being able to redefine T.init would be useful, but as Andrei said, that is beyond the scope of this DIP

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