On Wed, 29 Sep 2010 13:25:23 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 9/29/10 10:10 PDT, Steven Schveighoffer wrote:
On Wed, 29 Sep 2010 12:26:39 -0400, Andrei Alexandrescu
<[email protected]> 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
