[RFC] I/O and Buffer Range

[Vladimir Panteleev]

On Sunday, 29 December 2013 at 22:02:57 UTC, Dmitry Olshansky 
wrote:
> [snip]

Hmm, just yesterday I was rewriting a parser to use a buffer 
instead of loading the whole file in memory, so this is quite 
timely for me.

Questions:

1. What happens when the distance between the pinned and current 
position exceeds the size of the buffer (sliding window)? Is the 
buffer size increased, or is the stream rewound if possible and 
the range returned by the slice does seeking?

2. I don't understand the rationale behind the current semantics 
of lookahead/lookbehind. If you want to e.g. peek ahead/behind to 
find the first whitespace char, you don't know how many chars to 
request. Wouldn't it be better to make these functions return the 
ENTIRE available buffer in O(1)?

I guess I see the point when applied to regular expressions, 
where the user explicitly specifies how many characters to look 
ahead/behind. However, I think in most use cases the amount is 
not known beforehand (without imposing arbitrary limitations on 
users like "Thou shalt not have variable identifiers longer than 
32 characters"), so the pattern would be "try a cheap 
lookahead/behind, and if that fails, do an expensive one".

3. I think ideally the final design would use something like what 
std.allocator does with "unbounded" and "chooseAtRuntime" - some 
uses might not need lookahead or lookbehind or other features at 
all, so having a way to disable the relevant code would benefit 
those cases.