The first reason for being unpopular is that they are overly complex. The C++ standard library doesn’t provide the required components for coroutines, so developers need to create their own.
Just to use coroutines, you have to write a promise_type , which must include something like:
std::suspend_always initial_suspend() { return {}; }
std::suspend_always final_suspend() noexcept { return {}; }
This is far more complex than anything else added to the standard in C++ 20.
Does it have to be this complex? Well, when you look into the granularity coroutines must achieve, there doesn’t seem to be a much better way.
If you were to compare the complexity of the code required to achieve asynchronous programming without coroutines, you’d see that code as being even more complex – so in that way coroutines simplify things.
This brings me to the second reason: their primary use cases aren’t very common, as not many applications require this level of control and efficiency for the asynchronous and concurrent programming. Most of these things can be achieved with old tools of futures, promises and callbacks, and most people stick to what they know as it keeps incrementally working so nobody bothers to learn the new thing.
There are some libraries that attempt to simplify their usage, but in my opinion, that defeats the purpose.
Leave a Reply