On 2010-09-29 19:42, Andrei Alexandrescu wrote:
On 9/29/10 9:52 PDT, dsimcha wrote:
== Quote from Andrei Alexandrescu ([email protected])'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
