However, how is that an argument for also not providing user-friendly, "instant productivity" high-level wrappers? By not doing that, developers having simple needs with reasonable [1] defaults are doomed to chase the rabbit-hole of complex specifications and reinvent the wheel again and again. Countless hours of programmer productivity wasted.
So your complaint is not that Asio is bad, but that the author stopped when he should have kept going and writing more code? Nothing stops you or anyone else from supplying that missing code. As I have done with Beast.
That's not how I read the OP's point. He seemed to me to be pointing out that .NET APIs provide a stupid-simple API on top of lots of complexity which itself sits on top of the Win32 winsock API. And that I find a very fair criticism of the Networking TS, and one shared by a ton of people on WG21. Networking ought to be some stupid-simple coroutinised Ranges i/o API on the top. Then stuff like strands, i/o contexts, completion tokens et al in a distinct, held separate, API layer that you never see from the stupid simple API layer, unless you ask. And then very low level almost-raw-sockets in a third, distinct, held separate API at the bottom, that you ought to never see unless you really have to. That's the ideal in a lot of people's opinion, but nobody has the time to do it right. So we standardise what's common practice, not what people would prefer common practice ought to be. And that's entirely right and proper in my book. Standards ought to be about existing practice not about innovation, and this is one reason I find the current trajectory of one half of the Networking TS into pure innovation land (i.e. Executors, which don't exist anywhere yet in the proposed form) worrying. Me personally, I'd really like to see the bottom level part of Networking minus all the concurrency stuff standardised separately as soon as possible. We understand that part well. But, up to the TS editors and champions in the end, and they've not decided to do that. Niall