www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DIP 1018--The Copy Constructor--Final Review

reply Mike Parker <aldacron gmail.com> writes:
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.
Feb 28 2019
parent reply Olivier FAURE <couteaubleu gmail.com> writes:
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.
Mar 01 2019
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
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
Mar 01 2019
parent reply RazvanN <razvan.nitu1305 gmail.com> writes:
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
Mar 02 2019
parent reply Olivier FAURE <couteaubleu gmail.com> writes:
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.
Mar 02 2019
parent reply Nick Treleaven <nick geany.org> writes:
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).
Mar 03 2019
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
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
Mar 03 2019
parent reply Nick Treleaven <nick geany.org> writes:
On Sunday, 3 March 2019 at 21:33:07 UTC, Paolo Invernizzi wrote:

 On Sunday, 3 March 2019 at 13:06:31 UTC, Nick Treleaven wrote:

 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


 __mutable


You mean annotate all reference type fields with __mutable? I 
really don't think that is what it is being designed for. 
Razvan's proposal [1] has many restrictions on __mutable:

* "__mutable can only be applied to private members"
* "Global/Local and static variables cannot be __mutable"
* "__mutable data can only be manipulated in  system code"
* "__mutable fields of const instances also need to be regarded 
as shared" [*]

These restrictions mean mass __mutable use on reference type 
fields would be unsafe and very prone to introducing races in MT 
code.

[1] 
https://github.com/RazvanN7/DIPs/blob/Mutable_Dip/DIPs/DIP1xxx-rn.md
[*] Note: I submitted a PR to fix some typos in this section
Mar 04 2019
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Monday, 4 March 2019 at 11:20:22 UTC, Nick Treleaven wrote:

 On Sunday, 3 March 2019 at 21:33:07 UTC, Paolo Invernizzi wrote:

 On Sunday, 3 March 2019 at 13:06:31 UTC, Nick Treleaven wrote:

 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


 __mutable


 You mean annotate all reference type fields with __mutable? I 
 really don't think that is what it is being designed for. 
 Razvan's proposal [1] has many restrictions on __mutable:

 * "__mutable can only be applied to private members"
 * "Global/Local and static variables cannot be __mutable"
 * "__mutable data can only be manipulated in  system code"
 * "__mutable fields of const instances also need to be regarded 
 as shared" [*]

 These restrictions mean mass __mutable use on reference type 
 fields would be unsafe and very prone to introducing races in 
 MT code.

 [1] 
 https://github.com/RazvanN7/DIPs/blob/Mutable_Dip/DIPs/DIP1xxx-rn.md
 [*] Note: I submitted a PR to fix some typos in this section


I mean that we have transitioned from struct memcpy + postblit to 
copyctor, but both solutions are sub-optimal.

Citing Andrei addition, "so forcing const on the copy 
constructor's right-hand side would make simple copying task 
UNDULY difficult", that I interpret as lack of plasticity in the 
language in expressing such use case.

There's the need to keep the original type of the value passed to 
the parameters as it is, and to express that the argument can't 
be muted in the method, BUT indirection can be taken.

I've the impression that the road of dealing with such problem 
first, and then dissecting postblit + mutable (not necessarily in 
the current Razvan DIP design) would have resulted in a better 
way to solve what we are currently trying to solve now.

Well, but that's bike shedding, so... just don't take my word too 
seriously...

:-P

- P
Mar 04 2019
parent Kagamin <spam here.lot> writes:
On Monday, 4 March 2019 at 12:59:36 UTC, Paolo Invernizzi wrote:

 Citing Andrei addition, "so forcing const on the copy 
 constructor's right-hand side would make simple copying task 
 UNDULY difficult", that I interpret as lack of plasticity in 
 the language in expressing such use case.

 There's the need to keep the original type of the value passed 
 to the parameters as it is, and to express that the argument 
 can't be muted in the method, BUT indirection can be taken.


That can be done with inout:

struct A
{
     int[] a;
     this(ref inout int[] b) inout
     {
         a=b;
     }
}

void f()
{
     int[] b;
     A a=A(b); //mutable ok
     const A a1=const A(b); //const ok
}
Mar 05 2019
prev sibling next sibling parent reply Atila Neves <atila.neves gmail.com> writes:
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.
Mar 02 2019
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/2/19 7:55 AM, Atila Neves wrote:

 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.


Correctamundo. (Also the case in C++.)
Mar 05 2019
prev sibling parent reply Kagamin <spam here.lot> writes:
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.
Mar 02 2019
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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??
Mar 02 2019