Revised RFC on range design for D2

[Andrei Alexandrescu]

Benji Smith wrote:
> Andrei Alexandrescu wrote:
>> In wake of the many excellent comments and suggestions made here, I 
>> made one more pass through the draft proposal for ranges.
>>
>> http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
>>
>> There are some comments in red illustrating some uncertainties (not 
>> all), and the names of the primitives have been updated. Bicycle shed 
>> galore! But don't forget to comment on the reactor as well :o).
> 
> Well done. I think the design has come together very nicely. I'm 
> especially happy with all the new names, which make a big difference for 
> me in being able to visualize how the proposal works. The old names 
> (fromLeft, etc) were very opaque to me.
> 
> (btw: head & toe? i love it!)
> 
> In its current state, this actually gets me pretty excited about D2. 
> Maybe even enough to finally slog my way through all the const stuff.
> 
> One tiny typo, though: In the "Forward range" section, the code sample 
> still uses "left" instead of "head".

Fixed, thanks.

> And, there are two sections (which I think are related to one another) 
> that left me scratching my head:
> 
> Input Ranges:
> "In case ElementType!(R) has aliases (such as a reference, pointer, or 
> array type), the iterator is free to recycle it it upon the call to 
> r.next, so client code must do a deep copy if preserving the value is 
> needed. [NOTE: This is a weakness in the design. A better way of 
> figuring recycling should be found.] The call is defined only right 
> after r.done returned false."
> 
> Forward Ranges:
> "Also, forward ranges iterate over "real" elements, which makes in-place 
> mutation of r.head possible."
> 
> Those paragraphs are completely greek to me. Can you elaborate?

Consider iterating over an array of int[], specifically an int[][]. Then 
when you call r.head you see the current int[]. You can store it and use 
it a few steps later or even after the iteration is done for as long as 
the array is around.

Contrast that with iterating a file containing lines of integers. The 
file has a buffer of type int[]. Every time you call r.next, the file 
range reads a new line, parses the integers, and REFILLS the array with 
them. If if generated a new array every line, that would cause a great 
deal of allocations.

Same about the in-place thing. If you modify elements in the array, they 
stay modified. If you modify the buffer of a file, your changes get 
overwritten upon r.next.


Andrei