Re: [Async] Naming land grab?

From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2023-10-03 07:01:48

Am 03.10.2023 um 07:52 schrieb Klemens Morgenstern via Boost:
> 1. ASYNC
>
> The name async is meant to homestead the async name for sure, so we
> can have other coroutine based modules like async.io, async.http
> (hopefully working with a future http-proto) and async.mysql etc.
> This is based on other languages using `async` as a keyword.
>
> The asio-based libraries in boost at this moment are beast, mysql &
> redis. None of those have asio in their name. Redis was aedis, to
> clarify it's async, but I thought this was bad for searches and
> proposed Marcelo to change it.
> That combined with the fact that no one has yet claimed async, made it
> seem like a good choice, especially if we can have simplified apis for
> the already existing asio-compatible libraries as async.redis and
> async.mysql, maybe a low-level io library, called async.io and
> async.process.
> That is, the name boost.async would mean C++20 coroutines based.
> I am unsure if the criticism of the name is that it implies too much
> (i.e. it should include the above-mentioned modules already) or if it
> implies to be something different (like a generic async completion
> solution, akin to asio's completion tokens).
> If it is the former, this library is probably boost.async.core. Which
> would be an alright name, but I would expect for all the types to
> still be in the boost::async namespace, so I don't see the point.
+1
> An alternative I am not too fond of would be to use the `co_` prefix,
> as it is the prefix of the coroutine keywords, e.g. making this
> library `co_async` or just `co`. Then other coroutine libraries could
> be `co_mysql` etc.
> I would also like to note that other good names are already taken,
> such as boost.coroutine. And naming this library boost.coro or
> something would be much worse than async, because it's ambiguous and
> would also promise too much.

+1

> 2. TASK/PROMISE
>
> The solution Niall opted for is eager & lazy. I don't like adjectives
> as class names (similarly I don't like asio::awaitable) because that's
> a property of a thing. So imo they should be concepts or traits (e.g.
> is_eager), which is the case with async::awaitable.
+1
> boost.context uses "fiber" for the lazy and "continuation" for the
> eager types. Which makes sense, but `contiunation<T>` would look off
> to me, because it doesn't continue a T.

boost.context uses 'fiber_context' as requested by the C++ standards 
committee (proposal P0876: fiber_context - fibers without scheduler). It 
provides an asymmetric, stackful coroutine-like operation - in contrast 
to this C++20-coroutines are symmetric and stackless.

boost.context provides an additonal API `callcc/continuation' 
(call-with-current-continuation) - it is based on the Scheme call/cc and 
is deprecated. The `continuation< T >`is a suspended stack with 
preserved registers.

Oliver