DIP 1018--The Copy Constructor--Community Review Round 1

H. S. Teoh hsteoh at quickfur.ath.cx
Fri Dec 21 21:40:23 UTC 2018

On Fri, Dec 21, 2018 at 02:43:50PM +0000, Boris-Barboris via Digitalmars-d wrote:
> On Tuesday, 18 December 2018 at 14:51:39 UTC, Mike Parker wrote:
> > This is the feedback thread for the first round of Community Review for
> > DIP 1018, "The Copy Constructor"
> 1). I do not like the ability to specify a mutable copy source. Under
> no circumstance should the code like
> A a;
> A fun()
> {
>     return a;      // lowered to return tmp.copyCtor(a)
> }
> void main()
> {
>     A b = fun();    // the return value of fun() is moved to the location of b
> }
> be allowed to modify the value of a. This is an absolute pain to
> read\debug, and I would instead like to see a mandatory
> const\immutable on the source reference.
> Copy operation should not modify the source, or it should not be
> called a copy. If we are talking about a typical smart pointer struct
> (Refcounted), copy still should not modify the source. It is D's
> transitive const\immutable that is a problem here and it must be
> explicitly casted away by the developer.
> Only const also mitigates the combinatorial mess caused by 4
> combinations of mutable\immutable copy constructors, since immutable
> is implicitly converted to const.

Shouldn't const be inout in this case?

> 2). "A declaration is a copy constructor declaration if it is a
> constructor declaration that takes only one non-default parameter by
> reference that is of the same type as typeof(this), followed by any
> number of default parameters..."
> If you need other parameters, you are not performing a copy. Copy
> constructor needs no additional parameters. If the semantics of your
> domain problem involve parametrized post-copy operations, the code
> should state that explicitly - by using specialized properly-named
> methods, that notify the reader about this particularity.

+1.  Doing otherwise adds needless complexity for something I can't
think of any use cases for.

Programming is not just an act of telling a computer what to do: it is also an act of telling other programmers what you wished the computer to do. Both are important, and the latter deserves care. -- Andrew Morton

More information about the Digitalmars-d mailing list