sorting hidden data.

[dsimcha]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s article
> 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.
> Andrei

Actually, this gives me the opportunity to bring up a point I've been meaning to
bring up.  moveFront() and friends don't even need to be explicitly defined.  The
module level function moveFront() in std.range defines default behavior in the
following cases:

1.  If the range's elements don't have elaborate copy construction, moveFront just
forwards to front.

2.  If the range's elements are lvalues, std.algorithm.move(range.front) can give
the proper behavior.

Of course, these are just defaults and can be overridden by explicitly defining
moveFront() even where they apply.  If range.moveFront() is explicitly defined,
the module level function always forwards to it no matter what.

The situation has gradually evolved into this state due to discussions on Bugzilla
and the Phobos list and the impracticality of forcing explicit moveFront() on all
ranges.  Unless it's still subject to change, it should probably be documented
somewhere.