Unifying pipe IO

[ghost]

I'm working on byte IO proposal and hope to get R0 in Prague. I've actually thought about adding pipes before I found this proposal. I hope to share some experience and make us sync the API.

Right now there 2 functions for IO in the process proposal:

size_t read(span<byte> data);
size_t write(span<const byte> data);

while my API uses this:

streamsize read_some(span<byte> buffer);
streamsize write_some(span<const byte> buffer);

As you can see, the API is pretty similar but there are important differences. I return streamsize because it is defined to hold the size of IO operation. This type is also signed which is important in template code where unsigned types ruin arithmetic.

2nd - naming. The names were taken from Networking TS because they point out that that buffer may not be transferred fully. For that reason I provide high level std::io::read and std::io::write customization points that call read_some and write_some in a loop until the buffer is transferred.

Also note on vectored IO which is not in my proposal yet. From my understanding of MSDN, Windows requires perfectly aligned and sized pages so span<span<byte>> doesn't work in most cases. Also POSIX uses iovec and I've found I'd need to inherit my custom span class from iovec to pass it to POSIX functions without any memory allocations. What I'm saying is I think Networking TS design for vectored IO needs to be tweaked before it works in intuitive way.

[klemens-morgenstern]

I am starting to think that we might just remove the duplication of pipe and async_pipe and just make it one class that requires the networking TS. Then we would have the asnyc_read_some as well. See #34

[klemens-morgenstern]

Would your proposal use the async functionality or just the stream if it had to choose between those two?

[ghost]

I deliberately avoided async stuff for R0 as I wanted to get review of the basic design first and also I never used async stuff of the Networking TS/ASIO myself.

I find iostream stuff completely broken beyond any repair. In my own code I'm moving to ban use of char and wchar_t completely unless interfacing with OS API.

I've also read that C++23 executors are different enough from Networking TS that it requires a redesign. So, I'd rather keep sync and async stuff in different classes but will compromise and put them in the same class if required by LEWG[I].