sorting hidden data.

[Steven Schveighoffer]

On Wed, 29 Sep 2010 13:25:23 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> 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.

What I mean is, why is it automatically assumed that if front does not  
return a ref, the only way to swap is via moveX?  If T == int, why must we  
have a moveFront to deal with it?  IMO, all algorithms should default to  
copying unless alternatives exist.

 From what I understand, moveFront is going to be *more* expensive, since  
it has to zero out the original.  While this is fine for some types, it's  
not fine for simple types.

-Steve