On 2011-09-24 07:29:52 +0000, Andrei Alexandrescu
<seewebsiteforem...@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.for...@michelf.com
http://michelf.com/
