On 10/10/10 7:34 PM, Tomek Sowiński wrote:
Currently the contents of Stride depend on from which end we look at it:
auto m = [1, 2, 3, 4, 1, 2, 3, 4, 1, 2, 3, 4]; // 3 rows, 4 columns
auto col = stride(m, 4);
assert(equal(col, [1, 1, 1]));
assert(equal(retro(col), [4, 4, 4]));
Is the quantum behavior intended?
Hmm, that does seem counter-intuitive, but I can't see any other way for
it to work.
Consider a doubly-linked list with the same data as above. How could
Stride implement back() without first computing the length of the list?
You could implement it correctly and efficiently for (non-infinite)
random access ranges, but then you'd have inconsistent behavior between
random access ranges and non-RA bidirectional ranges.
The solution I believe is to make Stride a forward range for directional
ranges, and give it the correct semantics for back() when used on a
random access range i.e. use ((length-1) - (length-1) % stride) to get
the back element index so that the retro traversal is actually the
reverse of the forward traversal.
For bidirectional ranges, people can always just use stride(retro(r), n)
to get a backwards traversing stride.
