moveFront() and friends: Request for comment

[dsimcha]

Andrei and I were talking on the Phobos list and deep in a newsgroup thread
about whether Phobos should make a serious effort to efficiently support
structs with arbitrarily complex, expensive postblits.  Such support includes
the moveFront(), moveBack() and moveAt() range primitives, which are designed
to allow a struct with arbitrarily expensive copying to be efficiently moved
(rather than copied) from the range to another variable.

My general feeling is ranges are becoming too complex, that they already work
well enough for the vast majority of cases, and that any more complexity would
make them nearly impossible to write correctly, especially in the case of
higher order ranges.  I think the amount of time it took to get std.range and
the range parts of std.algorithm into a reasonably bug-free state supports
this assessment.  In general, for reasons I won't detail to avoid driving this
post off topic, I think D has been complicating common cases to fix corner
cases too much lately.

With regard to supporting postblits specifically, to me there are two points
to having value semantics instead of reference semantics:

1.  For small primitive types value semantics are more efficient to implement.

2.  Value semantics avoid uncontrolled aliasing and make programs easier to
reason about.

However, I think number 2 is a red herring when it comes to structs,
especially if you care about performance or handling out of memory exceptions.
 The net effect of hiding arbitrarily complex, possibly throwing logic behind
an innocent looking assignment statement, parameter passing, etc. is to make
programs harder to reason about than if everything just had reference
semantics and explicit cloning.  Therefore, I consider arbitrarily expensive,
non-O(1) postblits to be a terrible programming practice that Phobos should
not go out of the way to handle efficiently, and a throwback to non-GC'd
languages where everything must have a clear owner who is responsible for
freeing it.  I realize that there are a few odd cases like BigInt that would
be very strange with reference semantics.  However, in these cases copy on
write semantics work pretty well.

I'd like any comments anyone might have on to what extent arbitrarily
expensive postblits should be considered in the design of Phobos.