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

[Jonathan M Davis]

On Saturday, September 24, 2011 02:29:52 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.

I'd say that I have to agree, though I think that we'll definitely need to look 
into whether this(this) should be able to legimately throw or not. It seems 
like it could easily be the case that we could reasonably require that it be 
nothrow, and it seems that it could easily be the case that that's too 
restrictive. pure is in the same boat, I think. And if we can require those, 
it makes me wonder if we could require @safe as well. But I fear that there's 
going to be some reason why some or all of those are unreasonable to require.

By the way, does this mean that we'll be able to get rid of moveFront and its 
compatriots? - since if I understand correctly, the only reason that the 
moveXXX functions exist for ranges is to deal with the case where copying 
isn't cheap.

- Jonathan M Davis