getNext

[Steven Schveighoffer]

On Mon, 16 Jul 2012 18:37:34 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 7/16/12 5:55 PM, Steven Schveighoffer wrote:
>> On Mon, 12 Jul 2010 23:48:05 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>
>>> Consider this:
>>>
>>> T* getNext(R, T)(ref R range, ref T item);
>>
>> I see you still defending this concept from 2010, does it mean we may
>> still get it? (it would make things easier for std.io for sure)
>>
>> If so, can we ditch the notion of forward+ ranges requiring save?
>>
>> -Steve
>
> I'm not defending it, I recall last time I discussed it I mentioned its  
> issues. The main one is it makes it awkward to iterate ranges that don't  
> actually have elements in memory. The approach would be forced to return  
> the same pointer to a buffer, until the end when it returns null. User  
> code would have no ability to make the distinction.

Yes, that is a true drawback.  I suppose a nullable type would help here.

> On the other hand this is what e.g. byLine does, but with an array, not  
> a pointer.

True, but I was thinking in terms of unbuffered i/o.  Buffered i/o fits in  
ok with the current range scheme, since, as you point out, a slice can be  
a valid range element.

Come to think of it, you still need a place to put the data, so it doesn't  
really matter.  You always have to have a buffer to point to.

So maybe this isn't such a good idea...

> Like it or not, .save is here to stay.

not. ;)

-Steve