Re: [Async] Naming land grab?

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2023-10-03 05:52:37

On Mon, Oct 2, 2023 at 10:40 PM Niall Douglas via Boost
<boost_at_[hidden]> wrote:
>
> 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.