On Wednesday, November 23, 2011 22:21:47 dsimcha wrote: > On 11/23/2011 9:26 PM, Walter Bright wrote: > > On 11/19/2011 7:02 PM, dsimcha wrote: > >> * Streams. (Another item where the bottleneck is mostly at the design > >> level and > >> people not really knowing what they want.) > > > > I'm not sure what the purpose of streams would be, now that we have > > ranges. > Right. As I mentioned in a previous post buried deep in this thread, I > think streams should just be a flavor of ranges that have most or all of > the following characteristics: > > 1. Live in std.stream. > > 2. Oriented toward I/O. > > 3. Heavy use of higher order ranges/stacking for things like > compression/decompression and encryption/decryption. > > 4. Mostly focused on input ranges as opposed to random > access/forward/bidirectional, since this is the best model for data from > a network or stdin.
Andrei's plan for streams was discussed a fair bit a while back. IIRC, it essentially involved a lower level range API which took chunks of elements rather than elements such that you were essentially dealing with a buffer that was reading in the data. A higher level range would then be put on top of that range which presented a more normal range API. So, a lower level stream of ubytes would be return ubyte[] for its front (the buffer which was ubyte[]), and then a higher level range which would return ubyte for its front would be on top of that. I'd have to go digging through the archives though to see exactly what Andrei was proposing, but that's more or less what I recall. AFAIK, he still intends for something along those lines to be implemented, but no one has done it yet. - Jonathan M Davis