I'm adding a new class to dcollections -- Deque of STL fame.
A deque implements dcollections' List interface, and one of the
requirements of the List interface is to be able to sort elements.
One important property of most dcollections containers is that data is not
exposed. This means you cannot get an address to the internal storage of
elements. The one exception is ArrayList (which purposely exposes its
representation via an array). I initially wanted to make Deque also hide
its internals, but I ran into a significant snag.
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() {...}
}
You cannot use std.algorithm.sort on this range.
So my current workaround is to allow ref return on front().
My questions are:
1. Does it make sense to allow ref access to Deque?
2. Is there a way to use std.algorithm.sort on myrange above?
3. Might people have interest in a "property delegate" that allows one to
pass the ability to set/get a property? e.g.:
auto pdelegate = getPropertyDelegate!"front"(r);
-Steve
