sorting hidden data.

Jacob Carlborg doob at me.com
Wed Sep 29 13:10:19 PDT 2010


On 2010-09-29 19:42, Andrei Alexandrescu wrote:
> 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

Would that be the uniform function call syntax that I've been waiting 
for since I first heard of it?

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list