On Wed, 10 Feb 2021 at 10:49, Niall Douglas via Boost-users < boost-users@lists.boost.org> wrote:
> On 10/02/2021 09:19, Richard Hodges via Boost-users wrote: > > > As far as I am able to tell from attending some of the meetings, the > > motivation for changes amongst certain actors in WG21 seems to me to be > > driven by either malice or willful ignorance of the impact on the user > > community. > > I think this too strong. People are sent by their employers to represent > their employer's interests on WG21. I can't think of a major tech > multinational whose representatives have not voiced serious concerns > about how poorly Networking maps onto their platform's proprietary > networking technologies, which is true, but equally very few of them > have been willing to fund a reference implementation which does improve > that mapping AND is completely portable to all the other platforms. They > have accepted that critique of their critiques, and everybody has > (mostly) moved on. > > Most of what is delaying Networking in the past year or so has not been > directly related to Networking (that ship has sailed, the committee has > conclusively voted that Networking = ASIO). The present problems are the > concurrency model, specifically what and how and why Executors > ought/could/should/might be. That's the exact same problem which has > bedevilled the Networking proposal since its very beginning, but I want > to be absolutely clear that it isn't just Networking being roadblocked > by this. Several major proposals are blocked by Executors. > It seems to me that what is holding up executors is the insistence on the sender/receiver nonsense. The use case for which seems to be (from looking at the proposals) unmaintainable and unintelligible write-once multi-page compound statements describing what could easily be expressed in a simple coroutine. > > I don't think malice nor wilful ignorance is behind the churn in > Executors. Rather, if WG21 gets it wrong, it's a huge footgun, so they > rightly won't progress it until its done. Everything which depends on it > is therefore blocked. > > I would also remind everybody that there was an option to progress the > blocking only API of ASIO into the standard which could have been > achieved quickly, but Chris elected not to do so at that time. I think > he was right in that choice, had the blocking API been standardised, it > would be unlikely the async API would have been revisited quickly. > A blocking-only API after half a decade of pontificating would be a risible outcome, which would reflect even more poorly on the competence of an already distrusted standards committee. We already have a standardised blocking-only API in Berkeley Sockets. What on earth would be the point of choosing C++ as the language for your program only to have it spend all its time blocked on a socket, and dependent on IO-specific mechanisms for cancellation? Such a thing does not belong in the standard at all. > > Niall > _______________________________________________ > Boost-users mailing list > Boost-users@lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-users > -- Richard Hodges hodge...@gmail.com office: +442032898513 home: +376841522 mobile: +376380212
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
