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