Revised RFC on range design for D2

[Bruno Medeiros]

Andrei Alexandrescu wrote:
> 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

How about having the element type of the 
file-containing-lines-of-integers range be const(int[]) instead of int[]?
I think it would solve the ownership problem, but it might introduce 
other problems, such as, how to make InputRange!(int[]) be covariant 
with InputRange!(const(int[]).

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D