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

[Steven Schveighoffer]

On Sat, 24 Sep 2011 03:29:52 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> 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