On Mon, 12 Jul 2010 23:48:05 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@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

On 7/16/12 5:55 PM, Steven Schveighoffer wrote:
> On Mon, 12 Jul 2010 23:48:05 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail@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.

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

If you feel strongly there are merits in the approach that overcome its issues, why not design around it? Anyhow, it looks like this would be too big a redesign of input ranges. Like it or not, .save is here to stay.


Andrei

On Mon, 16 Jul 2012 18:37:34 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@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@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