Accessors, byLine, input ranges

[Steven Schveighoffer]

On Fri, 29 Jan 2010 11:08:37 -0500, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2010-01-29 11:00:31 -0500, "Steven Schveighoffer"  
> <schveiguy at yahoo.com> said:
>
>> On Fri, 29 Jan 2010 10:53:50 -0500, Michel Fortin   
>> <michel.fortin at michelf.com> wrote:
>>
>>> On 2010-01-29 10:49:34 -0500, "Steven Schveighoffer"   
>>> <schveiguy at yahoo.com> said:
>>>
>>>> ugh... much simpler with a true stream-like range that supports what  
>>>> is   natural for streams:
>>>>  for(int i = 0; i < count && !range.empty; i++) {
>>>>     elements ~= range.get();
>>>> }
>>>>  But of course, then this function doesn't work for other range  
>>>> types.   I  decided in that discussion long ago that stream ranges  
>>>> were going to  suck.
>>>  You can always define a generic take() like this:
>>>  	E take(R, E)(ref R range) {
>>> 		E element = range.front;
>>> 		range.popFront();
>>> 		return element;
>>> 	}
>>>  This will work for any forward range.
>>  Except stream ranges.  I don't get it...
>
> Hum, well I used 'take' while you defined 'get' as the basic function  
> for stream ranges. They're the same thing. Rename 'take' for 'get', or  
> the reverse, and all input ranges can work with the same 'get' or 'take'  
> function.
>
> (Note: I use 'take' instead of 'get' because it seems clearer to me that  
> it also removes the element from the range.)

Oh, I get it now.  Yes, you can define this (BTW, I agree take is better  
than get).  Whether we will ever get x.fn() => fn(x) for ranges remains to  
be seen.  Without that, you have boilerplate code in every forward range  
and beyond.  The other possibility is to define an abstraction function  
like:

E take(R, E)(ref R range) {
    static if(isForwardRange!(R))
    {
        // repeat your code above
    }
    else
        return range.take();
}

and then use take(r) whenever you need that capability.

-Steve