February 27, 2019 Re: DIP 1018--The Copy Constructor--Formal Review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paolo Invernizzi | On 02/25/2019 03:41 PM, Paolo Invernizzi wrote: > On Monday, 25 February 2019 at 20:23:58 UTC, Andrei Alexandrescu wrote: >> On 2/25/19 3:23 PM, Jacob Carlborg wrote: >>> On 2019-02-25 20:24, Mike Parker wrote: >>> >>>> From the process document: >>>> >>>> “the DIP Manager or the Language Maintainers may allow for >>>> exceptions which waive requirements or responsibilities at their >>>> discretion.” >>> >>> Having it documented doesn't make it less flawed. >> >> Jacob, are there amends you need to make to the DIP? > > Honestly, I've not understood the rationale or the covered use case in > letting the copy ctor mutate the ref source parameters... > Sincerely, without polemical intent. I made an editorial pass: https://github.com/dlang/DIPs/pull/145 The most material change was additional explanation of using mutable ref instead of e.g. const. Here's the relevant excerpt, please let me know if it clarifies the motivation. ============================================= 1. The parameter of the copy constructor is passed by a mutable reference to the source object. This means that a call to the copy constructor may legally modify the source object: ```d struct A { int[] a; this(ref A another) { another.a[2] = 3; } } void main() { A a, b; a = b; // b.a[2] is modified } ``` This is surprising and potentially error-prone behavior because changing the source of a copy is not customary and may surprise the user of a type. (For that reason, C++ coding standards adopt the convention of taking the source by means of reference to `const`; copy constructors that use non-`const` right-hand side are allowed but discouraged.) In D, `const` and `immutable` are more restrictive than in C++, so forcing `const` on the copy constructor's right-hand side would make simple copying task unduly difficult. Consider: ```d class Window { ... } struct Widget { private Window display; ... this(ref const Widget rhs) { display = rhs.display; // Error! Cannot initialize a Window from a const(Window) } } ``` Such sharing of resources across objects is a common occurrence, which would be impeded by forcing `const` on the right-hand side of a copy. (An inferior workaround would be to selectively cast `const` away inside the copy constructor, which is obviously undesirable.) For that reason this DIP proposes allowing mutable copy sources. ============================================= |
March 03, 2019 Re: DIP 1018--The Copy Constructor--Formal Review | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Thursday, 28 February 2019 at 01:42:13 UTC, Andrei Alexandrescu wrote:
> Such sharing of resources across objects is a common occurrence, which would be impeded by forcing `const` on the right-hand side of a copy. (An inferior workaround would be to selectively cast `const` away inside the copy constructor, which is obviously undesirable.) For that reason this DIP proposes allowing mutable copy sources.
There's an argument to be made that a copy constructor isn't the best way to share resources between two variables in a way that might affect code using the variable being copied.
|
Copyright © 1999-2021 by the D Language Foundation