Re: [boost.async] new name

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2023-10-12 05:04:54

czw., 12 paź 2023 o 02:51 Klemens Morgenstern via Boost <
boost_at_[hidden]> napisał(a):

> Given the renaming requirement, I'd like to query the list if there
> are any objections to any of the following names:
>
> async.core
> await
> co_async / cosync
> co20 / cor20
>

While you didn't ask for it, let me offer some thoughts about the naming
rather than a yes/no.

I understand that your library is a *frontend* for asynchronous
computations, rather than a backend. A thing like Boost.ASIO or another
executor would be a backend. Is that a correct characterization? If yes,
"async.core" sends an opposite message: as if it was a backend.

The introductory sentence in GitHub say:

This library provides a set of easy to use coroutine primitives & utilities
running on top of boost.asio. These will be of interest for applications
that perform a lot of IO that want to not block unnecessarily, yet still
want to have linear & readable code (i..e. avoid callbacks).

One could summarize it even shorter as "a set of awaitables and basic
algorithms on them". In this spirit the name "Boost.Awaitables" would
reflect this, "await" (as a verb) a bit less so.

"co_async" does reflect that it will have something to do with C++
coroutines, but doesn't say what. If you wanted to say "the subset of
usages of coroutines that deal with asynchrony", you are losing it. It
looks more like "a better version of boost::asio::co_spawn". "cosync" no
longer associates with C++ coroutines because of the missing underscore. I
read this as "cosine".

"co20" is so strange that it could actually do the trick. It would fit into
the same category as Boost.Spirit, Boost.Phoenix, Boost.Beast: it's just a
cool name, if you want to learn what the library is for go to the
documentation. But you might as well go with Boost.Zen.

Regards,
&rzej;