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

Michel Fortin michel.fortin at michelf.com
Sat Sep 24 19:31:30 PDT 2011


On 2011-09-24 07:29:52 +0000, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> 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.

Seems like a perfectly reasonable policy. Go ahead.


> 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.

Perhaps I am missing the point. What would be gained by forcing 
this(this) to be nothrow?


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d mailing list