Failed to sort range

[Sergei Nosov]

On Tuesday, 28 May 2013 at 18:38:01 UTC, Ali Çehreli wrote:
> 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

Yes, exactly.

I believe, the same fix should be applied here: front_ + i, 
front_ + j. It passes the sorting test.

Thank you so much, Ali. Feels like to be back in school again.