this(this) must be cheap and O(1)

[dsimcha]

Vote++.  I have little experience in C++, but two things have convinced 
me that arbitrary cost copying is butt ugly and not worth the cost:

1.  The debacle of adding moveFront()/moveBack()/moveAt()/more bugs to 
std.range/std.algorithm last year.

2.  How well reference counting semantics have worked on Cristi's GSoC 
project, which I mentored.

On 9/24/2011 3:29 AM, Andrei Alexandrescu wrote:
> We've had a long-standing question on whether D should cater to
> arbitrarily costly copy constructor. C++ and its standard library do
> allow such, at a great cost in complexity of the standard library and
> user code.
>
> Taking a stand on this issue in D has long haunted Walter and myself. I
> think I have reached the point where I can argue convincingly that D
> should go for the following design:
>
> 1. You may not define this(this), and the object will be copied memberwise.
>
> 2. You may @disable this(this), and the object will not be copyable. The
> language must define under what circumstances such objects are usable.
> The library must define how it interacts with such objects.
>
> 3. You may define this(this), in which case the standard library is free
> to assume it is cheap, constant-complexity, and non-failing.
>
> This means that objects with large state would need to use things like
> COW and/or reference counting.
>
> The main argument for this design is that expensive constructors are a
> hidden, unescapable, and cross-cutting cost. Essentially every
> expensive-to-copy type C++ ever defines comes with the caveat that you
> should AVOID copying it. This leads to the simple notion that at best
> you should avoid defining expensive-to-copy types in the first place.
> (As I read in a book: only the man on the street and the great general
> can think of obviously good strategies.)
>
> (Anecdote - I was working on slides for a C++ course for people coming
> from other languages. One slide pointed out that reasonably-written C++
> code maps straightforwardly to fast code, with ONE exception - the
> hidden cost of copy constructors and destructors. It would be progress
> to eliminate that exception.)
>
> I'd go as far as requiring this(this) to be nothrow, but perhaps it
> would be best to see whether that is a necessity.
>
> Anyhow, this is what I think "sendero luminoso" is for D: a world in
> which objects are free to prevent copying altogether (an important
> category of designs) or define liability-free, unlimited copying
> (another important category of designs). Types that allow copying but do
> an arbitrary amount of work are a design D is willing to shun, in wake
> of C++'s poor experience with such. No type should have hidden copying
> costs that influence complexity and performance of complex operations.
>
>
> Destroy.
>
> Andrei
>