Re: [Async] Naming land grab?

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2023-10-03 14:36:33

On Tue, Oct 3, 2023, 10:14 PM Christian Mazakas via Boost <
boost_at_[hidden]> 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
>