sorting hidden data.

[Andrei Alexandrescu]

On 9/29/10 10:10 PDT, Steven Schveighoffer wrote:
> 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

It could, if we decided to punt on types with expensive constructors.

Andrei