On 08/17/2010 01:18 PM, David Simcha wrote:
Two points:
1. I generally consider making copying arbitrarily expensive via
this(this) to be a *terrible* practice that we shouldn't bend over
backwards to support efficiently. Using this(this) to give eager value
semantics is a holdover from C++, where objects must have a clear owner
and aliasing must be controlled due to lack of GC. In a GC'd language
containers should have reference semantics with explicit duplication.
The proper use of this(this) is for simple O(1) things like reference
counting. My general feeling is that range definitions are getting too
complex to support a corner case.
I understand the sentiment, and I partially share it. Just like you I am
tempted to decree that this(this) must be O(1) and call it a day.
However, that often means that other operations all of a sudden become
weirder.
Consider an array of integers that uses reference counting. That means
that assigning an int to an existing slot of the array could throw. For
someone who (a) knows the array uses RC/COW, and (b) has a good
understanding of RC/COW, that is understandable. But at the end of the
day, that has leaky abstraction written all over it.
This has been a known issue in C++ with std::string. The design of
std::string has tried really hard to enable reference counting
implementations, but has essentially failed. As an example, in STL
everything that has capacity() and size() guarantees that size() <=
capacity(). The semantics of capacity() is "maximum number of elements
that can be stored without triggering reallocation". For a RC string
with count > 1, capacity() should be zero even though size() is nonzero.
The STL does not allow this, and current implementations essentially lie
in capacity().
2. What's the difference between moveFront(Widget rhs) and front(Widget
rhs)? I understand the difference for the case of moveFront() vs.
front(), but not for the assignment case.
Sorry, I meant Widget moveFront(). It destructively reads the front of
the range and returns it.
Ignoring the complexities of this(this)-related stuff, though, I
definitely like the work on sealed containers, etc.
Can't wait to find the time to write that article about it.
Andrei
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
