sorting hidden data.

[Andrei Alexandrescu]

On 9/29/10 9:52 PDT, dsimcha wrote:
> == 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.

Yah. I've been with a foot in the air regarding this until Walter 
figures out what to do about the rule a.f(b) -> f(a, b).

Andrei