A Universal I/O Abstraction for C++ (2020)

I think that it would be useful to consider the existing (very very very large) body of research on dataflow PL and APIs; e.g. check this paper from 1982 which talks about dataflow, coroutines, for handling file operations:

- https://scholarship.claremont.edu/cgi/viewcontent.cgi?articl...

More recent papers in the field:

- https://hal.archives-ouvertes.fr/hal-02865894/document

- https://library.oapen.org/bitstream/handle/20.500.12657/3772...

and older general overviews of the field:

- http://www.cs.ucf.edu/~dcm/Teaching/COT4810-Spring2011/Liter...

- http://210.47.10.86:8032/200009-3/65492.pdf#page=141

My main concern with this design, even if the code looks quite neat, is that the actual dataflow graph is not reified, but exists "invisibly" as part of the program source through the way co_await calls are sequenced.

This means that it is not possible to do as an user, a static analysis and scheduling of the tasks : it relies on the compiler to perform this. But, this problem is in my experience quite often very use-case-specific and ridden with informations compilers do not possess. Not having the way tasks are interdependent reified in an actual user-manipulable "graph" object means that users won't have the possibility, to, say, perform a topological sort or flow propagation on their async graph in order to extract information on it that could be necessary to perform a domain-specific optimization of said graph (for instance if we know that a set of tasks are dependent on each other in ways that aren't visible on the source code, but are known to the programmers, it would make sense to schedule them on a queue in their own thread).

Coroutines look interesting, I just need to get my head around them. All code examples I've seen, just as with ASIO, deal with the happy path only. For example, there's hardly a mention of timeouts and the faff ASIO makes you do to get them to work. If there's no 'read(..., timeout)' function then the API is broken as far as I'm concerned.

Then you'll (probably) need to write your own HTTP parsing code which, when you're half-way through, will make you realise that HTTP is actually not trivial at all to implement correctly. Best of luck writing your own HTTP2/3 engine. Boost.Beast seems like a great attempt at doing it right, but I've never used it. (HTTP needs to die, but that's a rant for another day)

IMO, it's too late for C++ and networking. If you need to read from something simple like a serial device then fine, it's probably ok. If you actually need to talk across the Internet then there are other languages that will do it better than you can.

Having said all this, personally, I know my limits and could never come up with anything better than ASIO.

If you really want you could even convert the graph (fully or partially) to a runtime representation.

The core of the proposals are not about specific classes or functions other than some default algorithm implementations.

Instead they are mostly about defining concepts and protocols so that independent async domains can coexist and iteroperate in the same application.

This is similar to the STL where the most important part are the various iterator concepts and the algorithm interfaces, not the actual algo implementations and the containers.

Too bad those shitty engineers in the 70s didn't think of Rust...