On Sat, 24 Sep 2011 03:29:52 -0400, Andrei Alexandrescu
<[email protected]> 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.
I'm fine with this, as long as it's not language-enforced, but just an
expectation. Because there are sometimes reasons to break the rules.
For example, you have said it's a faux pas to allocate memory inside a
postblit, but what if your "allocation" routine only allocates a pool on
the first call, and uses the pool for all the other allocations? Or
guarantees to allocate at most once every 1000 postblits? It's difficult
to make such guarantees generically, but within the context of a specific
application, it's quite easy to prove.
I don't know if we need to enforce nothrow, but probably the easiest way
to find a case where you *need* to throw is to enforce nothrow, and see
what fallout we have ;)
-Steve
