On May 15, 2012, at 3:34 PM, "Nathan M. Swan" <nathanms...@gmail.com> wrote:
> On Monday, 14 May 2012 at 15:02:11 UTC, Steven Schveighoffer wrote: >> In other words, a stream of bytes, not a good range (who wants to get one >> byte at a time?). A stream of UTF text broken into lines, a very good range. > > There are several cases where one would want one byte at the time; e.g. as an > input to another range that produces the utf text as an output. > > I do agree for e.g. with binary data some data can't be read with ranges > (when you need to read small chunks of varying size), but that doesn't mean > most things shouldn't be ranged-based. You really want both, depending on the situation. I don't see what's weird about this. C++ iostreams have input and output iterators built on top as well, for much the same reason. The annoying part is that once you've moved to a range interface it's hard to go back. Like say I want a ZipRange on top of a FileRange. But now I wan to read structs as binary blobs from that uncompressed output. One thing I'd like in a buffered input API is a way to perform transactional reads such that if the full read can't be performed, the read state remains unchanged. The best you can do with most APIs is to check for a desired length, but what I'd I don't want to read until a full line is available, and I don't know the exact length? Typically, you end up having to double buffer, which stinks.
