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