On Mon, Oct 2, 2023 at 10:40 PM Niall Douglas via Boost
Dear Boost,
I have received a non-public review which raises concerns about the naming land grab by proposed Boost.Async i.e. a Boost library called "Async" claims too much through its name.
I wrote a few things in responses and thought it might be good to summarize my thoughts here, as not everyone will read through lengthy discussions. 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. 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. Also note that there is nothing related to IO in this library itself. 2. TASK/PROMISE Since we're bikeshedding already, I might as well throw in the names task & promise which came up during review. It might be cultural, but the implied eager & laziness is obvious to me. Tasks get scheduled, promises should get fulfilled without scheduling. E.g. if you lend me your drill and I promise to return it, that should happen without you asking (i.e. co_awaiting) it. If you give a company the task to paint your fence, you'd expect that to be scheduled. There is of course an issue with promise, as the internal coroutine state is using the same name. The std::packaged_task is a way to create a lazy future. std::promise is the way to create a lazy future, it's just callback based. std::future thus can be both, lazy or eager, depending how it was created. Which is why I opted not to use it. 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. This could of course be because my native language, german, is big on nouns. 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.