Support of C++20 coroutines and naming of entities in SO-5

[eao197]

There is some progress in adding C++20 coroutines support and I hope that the first alpha version could be released in a week or two. But I have some doubts about the naming that is currently used in the development branch.

For example, all stuff related to C++20 coroutines now live in a new namespace so_5::cpp_coro. It allows, for example, to distinguish different versions of some functions, like asynchronous select from old synchronous one:

// Synchronous select.
so_5::select(so_5::from_all().handle_n(1), ...);

// Asynchronous select.
so_5::cpp_coro::select(so_5::from_all().handle_n(1), ...);

The so_5::cpp_coro contains such an important thing like task_t<T> that is the heart of the new coroutine related stuff. For example, an asynchronous event handler in agent (or message handler in select) has to return task_t<void> -- this is the mark for SO-5 that the handler is a coroutine and SO-5 treats it in a special way.

Because of that event handlers look a bit uglier than I wanted 😣

class demo : public so_5::agent_t
{
  // Async handler as a method.
  so_5::cpp_coro::task_t<void> evt_async_handler(mhood_t<some_msg>) {...}
  ...
  void so_define_agent() override
  {
    so_subscribe_self().event(
      // Async handler as a lambda.
      [this](mhood_t<another_msg> cmd) -> so_5::cpp_coro::task_t<void> {...});
  }
};

I'm afraid that this naming is not good and could lead to complaints from users. Because this stuff is not released yet there is time to change it to something more appropriate.

So I want to ask a few questions and would be glad to receive some feedback:

• Do you think that the new namespace so_5::cpp_coro is good for you? Or do you prefer to have all coroutines-related stuff in so_5 directly?
• Is returning a task_t<void> or task_t<> from an event handler looks good for you? Or do you prefer a different name (maybe resumable_t)? Which one?

Here are light notes of why such naming is used now.

---

Coroutines-related stuff is placed in so_5::cpp_coro namespace for several reasons:

• there is the same logic as with dispatchers that live in so_5::disp namespace or so_5::msg_tracing for message-tracing facilities, or so_5::stats for monitoring and statistics;
• the so_5::cpp_coro allows to use name select for asynchronous version of select without introducing a new name async_select;
• theoretically there could be support not only for stackless coroutines from C++20, but also for stackful coroutines implemented on top of boost::fibers, for example. In such a case there could be so_5::boost_fibers_coro namespace with similar entities inside (like select or scheduler_t).

---

Initially I thought about a special name so_5::resumable_t for a type to be returned from an asynchronous event handler. But I started the implementation from a helper type so_5::cpp_coro::task_t<T>. This task_t<T> was seen as an internal helper type that wouldn't be exposed to a public API. However, at some moment I realized that task_t<T> is a very useful thing (maybe it's because the standard C++ library still does not provide something similar) and started to use it everywhere in coroutines support. As a consequence the task_t<void> is used as a special mark for an asynchronous event handler.

For now I think that declaration like that:

so_5::cpp_coro::task_t<void> evt_async_handler(mhood_t<msg>);

is a bit wordy, even in such a form:

so_5::cpp_coro::task_t<> evt_async_handler(mhood_t<msg>);

So I have the temptation to define so_5::resumable_t as an alias for so_5::cpp_coro::task_t<void>. This simple trick will allow to write:

so_5::resumable_t evt_async_handler(mhood_t<msg>);

But it could lead to questions like "what so_5::resumable_t is?" and "how so_5::resumable_t differs from so_5::cpp_coro::task_t?" So I haven't introduced such an alias yet.