On Tue, Oct 3, 2023, 10:14 PM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
I emphatically support the name ACE or just Ace for this library as: Asio Coroutine Extensions.
This perfectly describes the library and is a nice short name that's unique and pops.
One thing I don't understand, the authors insists that Asio is just here for its event loop and cancellation but if you look at the docs, like 80% of Ace's interface contains `boost::asio::` in it.
Those two statements are unrelated. 80% of things just need an event loop and cancellation support. I also wanted to mention that I think I saw a signature that accepted
`io_context::executor` when it should just be `asio::any_executor`.
Which function was that?
This seems to be based on the notion that Asio's executors will someday make it into the standard but that ship has already sailed and no matter what we think, Sender/Receiver are most likely going to be the future of execution in standard C++.
I dont think we will get either standardized. Until i am proven wrong, asio is the best pick for an event loop.
I think, in general, Ace should attempt to hide as much of Asio as it physically can. Right now, this library exists in an odd middleground.
Why? Why is hiding things an ideal?
It's too entrenched in Asio for non-Asio users to really use and if you are an Asio user, Chris is already implementing like 90% of the proposed functionality here in its experimental namespace.
In which way is this too entrenched? Please provide some specifics. The only thing that supports symmetric transfer in asio is the experimental::coro. Nothing else, so all synchronization utilities must go through an executor.
- Christian
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost