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
