RFC on range design for D2

[Andrei Alexandrescu]

Sergey Gromov wrote:
> Sean Kelly <sean at invisibleduck.org> wrote:
>> Sergey Gromov wrote:
>>> Now the same algorithm in ranges:
>>>
>>>> Merge_backward(R1, R2, R3)(R1 s1, R2 s2, R3 dst)
>>>> {
>>>>     for (;;)
>>>>     {
>>>>         if (s1.isEmpty())
>>>>             dst[] = s2[];
>>>>         else if (s2.isEmpty())
>>>>             dst[] = s1[];
>> I'm not sure the above is correct.  It should return after the copy is 
>> performed, and the code also assumes that the size of dst is equal to 
>> the size of s2 and s1, respectively.
> 
> Of course there should be return statements, thank you.  I've never 
> tested this code (obviously), just've thrown it together, so there ought 
> to be stupid mistakes like this.
> 
> As to the destination size.  This is merge sort.  The size of 
> destination buffer must be the sum of the sizes of source buffers.  As 
> soon as one of the source buffers is empty, i.e. completely moved to the 
> destination, there must be place exactly for what left in another source 
> buffer.  If this condition doesn't hold then the arguments weren't 
> correct in the first place.

Speaking of copying, C++'s std::copy and friends have been under 
increasing scrutiny lately because of their inability to modularly 
protect data against overruns. STL's three-argument functions that copy 
out are often a kiss of death for inexperienced STL users. I'm glad 
ranges cut that Gordian knot.

Andrei