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

[Andrei Alexandrescu]

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