== Quote from Steven Schveighoffer ([email protected])'s article > 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
I somewhat agree, but apparently noone noticed my other post. moveFront() and friends **have default behavior** via the module level function std.range.moveFront() in most cases, and when they don't it is for a good reason. If Phobos directly calls the object's moveFront() instead of using the module level one with this default behavior, then IMHO it's **a bug**. Please read my post from ~an hour ago on this default behavior.
