cppcoro development seems pretty dead

[etorth]

If @lewissbaker decide to stop actively maintain this repo, anyone would like to keep it going? This is the most promising coro library till now I have seen, thanks for the great work! I saw new PR's for cmake/gcc/network support, it'll never get merged if no experts are actively taking in charge of this repo.

What I searched from reddit: [fake_ben] cppcoro development seems pretty dead, wouldn't recommend that one. The only thing I'm able to use it for is generators.

[lewissbaker] My apologies, I haven't been spending a lot of time on cppcoro lately. I'm glad at least the generators is useful for you :)

I still try to merge contributions where possible.

Most of my more recent coroutine developments have been in folly::coro (the coroutine support parts of folly) and more recently in libunifex, which I believe has some better foundations for an async framework than cppcoro.

[andreasbuhr]

Yes, I agree. Lewis seems to not have the time at the moment. At the moment every second pull request is solving the same problems again.

Just yesterday I started an effort to channel all the good contributions from the pull requests in https://github.com/andreasbuhr/cppcoro, creating one branch for every problem. See the README.md, first section, for a detailed explanation.

[dutow]

+1 here, I'm currently using (my fork of) cppcoro in some of my projects, and I'd like to see it maintained in the future.

Compared to the other mentioned projects, cppcoro is a small project solely focusing on coroutines.

@lewissbaker if you do not have the time to maintain the project, maybe it would be better to move the cppcoro repository into an organization, where we could have multiple maintainers? The fork created by @andreasbuhr is already a step into this direction, and by making it into an organization, the development wouldn't stall because one of us doesn't have free time to spend on the project. I'm also willing to be a part of this, as I'd like to see this project improved.

As the owner of the current "official" repository, you could even transfer the current repo into this organization. That way anybody who has a current checkout would automatically receive updates from the new location.

[andreasbuhr]

Hi, While it was not my intention to become a maintainer, I would volunteer to help maintaining cppcoro till the end of the year (or so). I support dutow's suggestion of an organization.

[feverzsj]

I think the main issue is no compilers is mature enough for coroutines and other c++20 features. You can easily run into lots of weird compiler bugs using them.

[andreasbuhr]

I think the main issue is no compilers is mature enough for coroutines and other c++20 features. You can easily run into lots of weird compiler bugs using them.

You are right, C++-20 support is not mature yet. But coroutines support is pretty good in the latest releases. And even if there are compiler bugs, we can still fix the problems for which fixes exit.

[rimmartin]

Hi, has anyone removed the ::experimental namespace and tested with more recent compilers?

[andreasbuhr]

Hi @rimmartin , in the pull request https://github.com/lewissbaker/cppcoro/pull/171 is a proposal for that.

[rimmartin]

ah thanks

[Garcia6l20]

Hi ! I think I'm not the only one felling frustrated of attempting to contribute do cppcoro... @andreasbuhr did a great work by managing CMake support and its pull request did not even got a comment !

Many of us are maintaining our own version of cppcoro for our needs and not sharing this is a mess.

I would suggest to create a new project (eg.: opencoro or somthing like this) starting from cppcoro, and, as proposed before to create an organization with anyone wants to maintain the project.

Other things I'd like by diverging from cppcoro is that we could use newer standard stuff (eg.: concepts, and later modules) since coroutine are not supposed to be available before c++20.

What do you think about this ?

[tavi-cacina]

The king is dead, long live the king! This repo may be dead, but the foundations laid out by Lewiss Baker in this repo, are finding their way in to the standard. He is the champion or contributor to some standardization papers that will shape the coroutines and executors future (P1745R0, P2168R0, P1056R1, P0443R13). The cppcoro::task, generator, sync_wait, etc will be refined in the next C++ std::task/lazy/generator... I personally see the cppcoro with its core types as a transition library, till all these goodies land in the standard. I do not use the I/O features from cppcoro, can not say about that bits, but the new executors, the asio's own coroutines, are all bringing some uncertainty about the future of that part. My wish would be to split the cppcoro library in 2 repos, the cppcoro-core and the cppcoro-io, the first would just fill the transition role I described. I do not expect Lewiss to have the time and desire to make/supervise such changes, so I support the idea to just create an github organization cppcoro/cxxcoro then fork and split the repo. This may also solve some backwards compatibility uncertainties, like the current TS/C++20 decision. It would be awesome if the current champion @andreasbuhr would chime in and support the initiative :-)

[bitbugprime]

Most of my more recent coroutine developments have been in folly::coro (the coroutine support parts of folly) and more recently in libunifex, which I believe has some better foundations for an async framework than cppcoro.

Isn't Lewis working on libunifex now? Does libunifex have its own coroutine implementation? You still need a working stackless coroutine implementation to replace cppcoro. Does GCC 11 alpha and Clang 11 (not yet released) have one, with symmetric transfer?

Also, since you seem to be familiar with libunifex: if I may ask, how do you actually use it? The examples have no comments saying what they're doing and why the APIs are being composed as they are in those examples, and the API descriptions are, to say the least, sorely lacking in explaining what you do with them. The explanation of what they do doesn't explain what problem "doing that" solves. They say libunifex can be used to build executor and I/O systems (basically, if you wanted, write something like ASIO in libunifex) but offer no examples or their own high level equivalent. The deep call-sequence composed function call style looks cool, but I don't see how real-world logic can be done like that. Things like "do rpc. no response? ok call the backup. still nothing? ok, mark as dead, report problem to monitoring system for human followup, then return an error".

[Tachi107]

You may be interested in https://github.com/lewissbaker/generator/commit/a44c0a80c327945ec3e67e77089e780a710f13dc

[pfirsich]

I want to get started using coroutines and since unfortunately a bit of boilerplate is required to use them at all, I wanted to use a library. Is there a maintained de-facto alternative to this library now? If so, could someone link it please?

[vipcxj]

I've used a lot of languages, java, kotlin, csharp, golang, python, js, cpp, and now all of them have a coroutine mode (java is my own implementation). But c++'s coroutine is really bad (both complex and rudimentary, with the name of flexibility). I've found that this library meets the vast majority of my needs for coroutine, but asio is much more widely used. The worst part is that this library is not compatible with asio. I can't co_await cppcoro's task in asio's coroutine. Does anyone know how to make them work well together?

[Ender-events]

Maybe you could test this library https://github.com/boostorg/cobalt