Accessors, byLine, input ranges

[Steven Schveighoffer]

On Fri, 29 Jan 2010 09:34:25 -0500, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2010-01-29 08:18:46 -0500, "Steven Schveighoffer"  
> <schveiguy at yahoo.com> said:
>
>> Hey, it's that dead horse again, let's beat it!
>>  Andrei and I and several others discussed this ad infinitum.  You  
>> will  never convince Andrei that his design is wrong :)
>
> Andrei is the one who complained that it's difficult to know whether  
> 'byLine' is a property in the first place. I'm just explaining why it  
> is, and what should be done.

I agree.

>
> I'm starting to think Anrei likes ambiguous semantics.  :-)
>
>
>> The truth is, the fact that byLine modifies stdin by its mere existence  
>>  proves to be inconsequential.  Nobody will fetch the byLine property   
>> without using it.  It's still an accessor.
>
> That's only true if you use byLine exclusively.
>
> Here is a case where the advance fetching of byLine could go wrong:
>
> 	// fetch 3 lines:
> 	string[] consume(3, stdin.byLine);
> 	// now fill a buffer
> 	ubyte[] buffer;
> 	buffer = stdin.rawRead(buffer);
>
> 	E[] consume(E, R)(int count, R range) {
> 		E[] elements;
> 		foreach (i; 0..count) {
> 			elements ~= range.front;
> 			range.popFront();
> 		}
> 		return elements;
> 	}
>
> The problem here is that the consume() function will in reality consume  
> 4 lines of stdin, even though it just take 3 from byLine.
>
> When we later call rawRead, a line has been lost.

Yeah, I am on your side.  byLine has some nuances that make it  
incompatible with other uses of the stream.  In fact, byLine might only be  
useful in processing the entire file.  Hm... opApply?

-Steve