sorting hidden data.

[dsimcha]

== Quote from Steven Schveighoffer (schveiguy at yahoo.com)'s article
> On Wed, 29 Sep 2010 12:26:39 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
> > On 9/29/10 6:22 PDT, Steven Schveighoffer wrote:
> >> std.algorithm.sort seems to require lvalue access to elements of a
> >> range, presumably so it can call swap on two elements during sorting. So
> >> while a range can technically allow changing of data, it cannot be
> >> passed to swap.
> >>
> >> e.g.
> >>
> >> struct myrange
> >> {
> >> @property T front() {...}
> >> @property T front(T t) {...}
> >> void popFront() {...}
> >> @property bool empty() {...}
> >> myrange opSlice(size_t low, size_t hi) {...}
> >> @property size_t length() {...}
> >> }
> >
> > Good news - you should be able to use sort on sealed ranges if they
> > define moveFront, moveBack, and moveAt. Look e.g. at Zip, it's also
> > sealed yet you can sort Zips no problem.
> >
> > This is a relatively new addition.
> I'm not liking this...
> How many more boiler-plate functions will we be forced to add in order to
> support standard ranges?  save() was bad enough, this is three more, when
> the functionality *already exists*.
> Can't sort just use:
> x = r1.front;
> r1.front = r2.front;
> r2.front = x;
> ???
> -Steve

I somewhat agree, but apparently noone noticed my other post.  moveFront() and
friends **have default behavior** via the module level function
std.range.moveFront() in most cases, and when they don't it is for a good reason.
 If Phobos directly calls the object's moveFront() instead of using the module
level one with this default behavior, then IMHO it's **a bug**.  Please read my
post from ~an hour ago on this default behavior.