Re: [boost.async] new name

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2023-10-12 05:26:44

> Anything with an underscore in it is an instant no from me.

Why?

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

Any help is appreciated. Naming is the second hardest task in software
development after all.

> 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.
>

Well the idea there is that I enthusiastically hope for more libraries
using my coros, e.g. async.http. Hence core would be the core library
of a bunch of async.* libs.
But I guess that is based on high hopes on my end with the additional
big question of whether or not people writing those libraries would
even want to do that. beast isn't named asio.http either.

> 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.
>

Well I don't like awaitable, as it's something that can be awaited.
But my lib provides the things that await as well, so it would be
boost.awaiters. Which is also weird, hence the idea of `await`.

>
> "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".

And co_sync would have the same issues as co_async?

>
> "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.

Well plus I don't like version numbers in libraries. A few standards
down the line, they seem out of date and as if they only were for this
version. Now I know better in the case of boost.mp11 for example, but
new users might not.
But I guess that it's coro with r -> 2, so co2o, isn't as obvious as i hoped.