RFC on range design for D2

[Andrei Alexandrescu]

Lionello Lunesu wrote:
> 
> "superdan" <super at dan.org> wrote in message 
> news:ga5vjs$snn$1 at digitalmars.com...
>> Andrei Alexandrescu Wrote:
>>
>>> What we want is a design that tells the truth. And a design that tells
>>> the truth is this:
>>>
>>> r.isEmpty does whatever the hell it takes to make sure whether there's
>>> data available or not. It is not const and it could throw an exception.
>>>
>>> v = r.getNext returns BY VALUE by means of DESTRUCTIVE COPY data that
>>> came through the wire, data that the client now owns as soon as getNext
>>> returned. There is no extra copy, no extra allocation, and the real
>>> thing has happened: data has been read from the outside and user code
>>> was made the only owner of it.
>>
>> this is really kool n the gang. there's a sore point tho. if i wanna 
>> read strings from a file no prob.
>>
>> for (auto r = stringSucker(stdin); !r.isEmpty(); )
>> {
>>    string s = r.getNext();
>>    // play with s
>> }
>>
>> but a new string is allocated every line. that's safe but slow. so i 
>> want some more efficient stuff. i should use char[] because string 
>> don't deallocate.
>>
>> for (auto r = charArraySucker(stdin); !r.isEmpty(); )
>> {
>>    char[] s = r.getNext();
>>    // play with s
>> }
>>
>> no improvement. same thing a new char[] is alloc each time. maybe i 
>> could do
>>
>> for (auto r = charArraySucker(stdin); !r.isEmpty(); )
>> {
>>    char[] s = r.getNext();
>>    // play with s
>>    delete s;
>> }
>>
>> would this make stuff faster. maybe. maybe not. and it's not general. 
>> what i'd like is some way of telling the range, i'm done with this you 
>> can recycle and reuse it. it's a green green world.
>>
>> for (auto r = charArraySucker(stdin); !r.isEmpty(); )
>> {
>>    char[] s = r.getNext();
>>    // play with s
>>    r.recycle(s);
>> }
>>
>> sig is recycle(ref ElementType!(R)).
> 
> Can't this be done by creating different ranges? I mean, trying to find 
> a 'one size fits all' model is usually a lost cause. And now we have 
> different consumers and different types.
> 
> Perhaps one sucker is instantiated with its own internal buffer and 
> another sucker allocates every new item. And possibly yet another sucker 
> only returns invariant items.

I don't mind implementing different suckers. :o) The problem is that the
suckers won't have the same interface, so some of them will work badly
or not at all with std.algorithm.

So again: I think the design you suggested isEmpty/first/getNext is the
better one even for input iterators.

Andrei