[RFC] I/O and Buffer Range

[Jason White]

On Sunday, 5 January 2014 at 13:30:59 UTC, Dmitry Olshansky wrote:
> I my view text implies something like:
>
> void write(const(char)[]);
> size_t read(char[]);
>
> And binary would be:
>
> void write(const(ubyte)[]);
> size_t read(ubyte[]);
>
> Should not clash.

Those would do the same thing for either text or binary data. 
When I say text writing, I guess I mean the serialization of any 
type to text (like what std.stdio.write does):

     void write(T)(T value);         // Text writing
     void write(const(ubyte)[] buf); // Binary writing

     write([1, 2, 3]); // want to write "[1, 2, 3]"
                       // but writes "\x01\x02\x03"

This clashes. We need to be able to specify if we want to 
write/read a text representation or just the raw binary data. In 
the above case, the most specialized overload will be called.

> In-memory array IMHO better not pretend to be a stream. This 
> kind of wrapping goes in the wrong direction (losing 
> capabilities). Instead wrapping a stream and/or array as a 
> buffer range proved to me to be more natural (extending 
> capabilities).

Shouldn't buffers/arrays provide a stream interface in addition 
to buffer-specific operations? I don't see why it would conflict 
with a range interface. As I understand it, ranges act on a 
single element at a time while streams act on multiple elements 
at a time. For ArrayBuffer in datapicked, a stream-style read is 
just lookahead(n) and cur += n. What capabilities are lost?

If buffers/arrays provide a stream interface, then they can be 
used by code that doesn't directly need the buffering 
capabilities but would still benefit from them.

>>Currently, std.stdio has all three of
>> those facets rolled into one.
>
> Locking though is a province of shared and may need a bit more 
> thought.

Locking of streams is something that I haven't explored too 
deeply yet. Streams that communicate with the OS certainly need 
locking as thread locality makes no difference there.