On 05/28/2013 11:31 AM, Ali Çehreli wrote:
> @property Array!T opSlice(size_t i, size_t j) {
> // ...
> ret.front_ = i;
>
> I feel like the initialization of front_ above is not right either.
> Imagine quick sort where we are slicing the right-hand side of a range
> as [0..10], which has already been sliced before. Setting front_ to 0
> would be wrong because then opIndex would still be counting from the
> beginning of the original elements.
My explanation is wrong but I think there is still a bug. Imagine we are
in the right-hand range that has been sliced as [10..$]. Now front_ is
10 and all is good: s[0] provides the arr[10] of the original array.
Now imagine our slice again by [5..$]. s_further[0] should provide
arr[15] of the original array but your setting front_ to 5 would
unfortunately provide arr[5].
Ali
