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