In response to feedback regarding the decision to approve DIP 1018, "The Copy Constructor", without a Final Review period, Walter and Andrei have agreed to revert their decision and initiate a Final Review Period.

As always, this is the last chance for community feedback. Please read the procedure document for details on what is expected in this review stage:

https://github.com/dlang/DIPs/blob/master/PROCEDURE.md#final-review

In summary--feedback at this stage should be focused on the technical and structural quality of the DIP. Personal opinions regarding the merits of the proposed feature are more appropriate in the Community Review stage.

The current revision of the DIP for this review is located here:

https://github.com/dlang/DIPs/blob/4dffe2455919a40fff37837d4b0307a31f2839b3/DIPs/DIP1018.md

In it, you'll find a link to and summary of the Community Review round. This round of review will continue until 11:59 pm ET on March 14 unless I call it off before then.

Thanks in advance for your participation.

On Thursday, 28 February 2019 at 10:44:36 UTC, Mike Parker wrote:
> Thanks in advance for your participation.

So, the big point of contention seems to be the possibility that structs have copy constructors taking non-const arguments.

I'll note that the language could allow only const arguments for copy constructor at first, and allow non-const arguments later (whereas the opposite order would be a breaking change).

Also, to the people on this forum who don't like non-const copy constructors, how do you propose to deal with this case?

    struct RefCounted(T) {
        int* refcount;
        T* payload;

        /* ... */
    }

    RefCounted p1(10);
    RefCounted p2 = p1;

One possibility would be to introduce a new "head_const" type qualifier, that would be used for cases like that. But honestly, I'm not sure

    this(ref head_const(RefCounted) other);

would bring much to the table compared to

    this(ref RefCounted other);

especially since then you have to consider introducing head_immutable and how they interact with scope and inout, etc.

On Friday, 1 March 2019 at 13:59:41 UTC, Olivier FAURE wrote:
> On Thursday, 28 February 2019 at 10:44:36 UTC, Mike Parker wrote:
>> Thanks in advance for your participation.
>
> So, the big point of contention seems to be the possibility that structs have copy constructors taking non-const arguments.
>
> I'll note that the language could allow only const arguments for copy constructor at first, and allow non-const arguments later (whereas the opposite order would be a breaking change).
>
> Also, to the people on this forum who don't like non-const copy constructors, how do you propose to deal with this case?
>
>     struct RefCounted(T) {
>         int* refcount;
>         T* payload;
>
>         /* ... */
>     }
>
>     RefCounted p1(10);
>     RefCounted p2 = p1;
>
> One possibility would be to introduce a new "head_const" type qualifier, that would be used for cases like that. But honestly, I'm not sure
>
>     this(ref head_const(RefCounted) other);
>
> would bring much to the table compared to
>
>     this(ref RefCounted other);
>
> especially since then you have to consider introducing head_immutable and how they interact with scope and inout, etc.

A way to express mutable data in an immutable / const graph is needed since a long time.

- P

On Friday, 1 March 2019 at 14:13:53 UTC, Paolo Invernizzi wrote:
> On Friday, 1 March 2019 at 13:59:41 UTC, Olivier FAURE wrote:
>> [...]
>
> A way to express mutable data in an immutable / const graph is needed since a long time.
>
> - P

The __mutable DIP is on the way. I am currently working on that [1]

[1] https://github.com/RazvanN7/DIPs/blob/Mutable_Dip/DIPs/DIP1xxx-rn.md

On Saturday, 2 March 2019 at 08:58:05 UTC, RazvanN wrote:
> On Friday, 1 March 2019 at 14:13:53 UTC, Paolo Invernizzi wrote:
>> On Friday, 1 March 2019 at 13:59:41 UTC, Olivier FAURE wrote:
>>> [...]
>>
>> A way to express mutable data in an immutable / const graph is needed since a long time.
>>
>> - P
>
> The __mutable DIP is on the way. I am currently working on that [1]
>
> [1] https://github.com/RazvanN7/DIPs/blob/Mutable_Dip/DIPs/DIP1xxx-rn.md

In the meantime, it's always possible to only allow const arguments for copy constructors at first, and consider non-const arguments once we've had a broader discussion on the semantics of const in D.

On Friday, 1 March 2019 at 13:59:41 UTC, Olivier FAURE wrote:
> On Thursday, 28 February 2019 at 10:44:36 UTC, Mike Parker wrote:
>> [...]
>
> So, the big point of contention seems to be the possibility that structs have copy constructors taking non-const arguments.
>
> [...]

The copy constructor doesn't *have* to take a ref to mutable. It can be ref const(T). It just doesn't force it.

On Friday, 1 March 2019 at 13:59:41 UTC, Olivier FAURE wrote:
> So, the big point of contention seems to be the possibility that structs have copy constructors taking non-const arguments.

I suppose it stems from the belief that mutable references are bad. Which is caused by a lack of explanation why bad. This is why design decisions should have explanations, otherwise people will guess the explanation, and they will guess incorrectly, and they will believe in what they guessed, and they will resist to change their beliefs, much pain ensues, it already happened, and keeps going. One guessed that it's non-intuitive, the other guessed that mutation is bad, the third guessed that const is bad. If RefCounted should mutate on copy by necessity, then it should mutate, no need to rationalize the opposite.

On Sat, Mar 02, 2019 at 04:41:42PM +0000, Kagamin via Digitalmars-d wrote: [...]
> This is why design decisions should have explanations, otherwise people will guess the explanation, and they will guess incorrectly, and they will believe in what they guessed, and they will resist to change their beliefs, much pain ensues, it already happened, and keeps going.
[...]

Exactly!!!

Every design decision should have its rationale well-documented, in an easily-accessible (and findable) place. That way people won't be forced to keep guessing.  Ideally, the spec on dlang.org should include such explanations, in addition to specifying the language itself.

Having such explanations attached to each design decision will also help us re-evaluate a decision later on when there's a need to change something.  Otherwise we forget how we got there, and are doomed to repeat the mistakes of the past.


T

-- 
Why do conspiracy theories always come from the same people??

On Saturday, 2 March 2019 at 10:17:01 UTC, Olivier FAURE wrote:
> In the meantime, it's always possible to only allow const arguments for copy constructors at first, and consider non-const arguments once we've had a broader discussion on the semantics of const in D.

Andrei has updated the DIP explaining why this wouldn't be a good @safe solution - see the `class Window` example:

https://github.com/dlang/DIPs/blob/5a10e274f7befcd2e615cdcbee549791cf11318e/DIPs/accepted/DIP1018.md#breaking-changes-and-deprecations

(He posted an update in the Announce thread - no one replied: https://forum.dlang.org/post/q57e9l$1582$1@digitalmars.com).

On Sunday, 3 March 2019 at 13:06:31 UTC, Nick Treleaven wrote:
> On Saturday, 2 March 2019 at 10:17:01 UTC, Olivier FAURE wrote:
>> In the meantime, it's always possible to only allow const arguments for copy constructors at first, and consider non-const arguments once we've had a broader discussion on the semantics of const in D.
>
> Andrei has updated the DIP explaining why this wouldn't be a good @safe solution - see the `class Window` example:
>
> https://github.com/dlang/DIPs/blob/5a10e274f7befcd2e615cdcbee549791cf11318e/DIPs/accepted/DIP1018.md#breaking-changes-and-deprecations
>
> (He posted an update in the Announce thread - no one replied: https://forum.dlang.org/post/q57e9l$1582$1@digitalmars.com).

__mutable

- Paolo