[phobos] Improving std.range.Zip

[Andrei Alexandrescu]

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