moveFront() and friends: Request for comment

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> On 8/27/10 7:44 PDT, Pillsy wrote:
> > dsimcha Wrote:
> > [...]
> >> I'd like any comments anyone might have on to what extent
> >> arbitrarily expensive postblits should be considered in the
> >> design of Phobos.
> >
> > I agree with you: expensive post-blits just don't seem sufficiently
> > necessary in D to warp the design of the standard library around
> > them, and have a distinctly anti-patternish feel to them. You have
> > too many other options, like straight reference semantics, copy-on-
> > write, and (with immutability and GC) safely shared structure.
> >
> > The last can be an incredibly useful technique for reducing the
> > cost of copying, because it allows you to treat an immutable
> > reference type exactly like a value type.
> >
> > Cheers,
> > Pillsy
> Clearly immutable sharing helps, and clearly reference counting and COW
> are valid techniques. However, the situation is not as cut and dried.
> The problem with RC/COW is that they reduce exception safety essentially
> _everywhere_ else but the copy constructor. Once you have a type using
> RC/COW, any mutation of that object, even one that ostensibly doesn't
> cause resource allocation, might have arbitrary cost or fail. This was
> the experience with std::string in C++ - its creators did everything
> they could to enable reference counting, and the outcome was quite
> unpleasant.
> Add to this the implementation annoyance of checking for aliasing in
> _every_ single method of the type. RefCounted in phobos can help with
> that, but not without a cost.
> So I'm not sure it's as simple a decision as it might sound.
> Andrei

But with RC/COW at least you know that if something becomes arbitrarily expensive
it's for a good reason, i.e. because doing anything else would break the
abstraction you're trying to create **right now**.  With eager copying copies get
made very often when a human reader reasoning only locally about the code could
easily prove they're not needed.  Furthermore, I think my point still generally
holds about reference vs. value semantics:  When you have to bend over backwards
to get value semantics, they're no longer easier to reason about.