Accessors, byLine, input ranges

[Michel Fortin]

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'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.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/