"Andrei Alexandrescu" <seewebsiteforem...@erdani.org> wrote in message news:iijpp7$197f$1...@digitalmars.com... > On 2/5/11 5:09 AM, Jonathan M Davis wrote: >> Hmm. I think that I'd have to have an actual implementation to mess >> around with >> to say much. My general take on buffered input is that I don't want to >> worry >> about it. I want it to be buffered so that it's more efficient, but I >> don't want to >> have to care about it in how I use it. I would have expected a buffered >> input >> range to be exactly the same as an input range except that it doesn't >> really >> just pull in one character behind the scenes. It pulls in 1024 or >> whatever when >> popFront() would result in the end of the buffer being reached, and you >> just get >> the first one with front. The API doesn't reflect the fact that it's >> buffered at >> all except perhaps in how you initialize it (by telling how big the >> buffer is, >> though generally I don't want to have to care about that either). > > Transparent buffering sounds sensible but in fact it robs you of important > capabilities. It essentially forces you to use grammars with lookahead 1 > for all input operations. Being able to peek forward into the stream > without committing to read from it allows you to e.g. do operations like > "does this stream start with a specific word" etc. As soon >
That shouldn't be a problem for the cases where a lookahead of 1 is all that's needed. So both types can exist (with the traditional/automatic type most likely built on top of Andrei's type). Thus, I think the only question is "Are the appropriate use-cases for the traditional/automatic type minor enough and infrequent enough to actively discourage it by not providing it?" That I can't answer.