On Fri, May 10, 2024 at 4:32 PM Vinnie Falco via Boost
On Fri, May 10, 2024 at 12:22 AM Arno Schoedl via Boost < boost@lists.boost.org> wrote:
Is there a way to avoid std::for_each having to be a coroutine?
No. This blog post elegantly relates the problem with this design (I think).
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
The viral nature of co_await was understood in 2015 and described in P0158R0:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0158r0.html
Most of the problems predicted in P0158R0 before coroutines made it into the standard are now being reported independently by users. As I noted in my previous replies, there is no process in WG21 which revisits major language decisions to learn from mistakes. In fact... I remember when the author was lobbying hard for coroutines he was giving talks, going to lunches and dinners, posting on reddit, posting on the Official C++ Language Slack Workspace, hanging out in Discord, and so on. But after coroutines made it into the standard he disappeared faster than my ex-wife after I declared bankruptcy. He unlocked the achievement I suppose.
Heh, I reached out to Gor when I wrote my coroutine library, never heard a thing. You'd think he would be interested in how his C++ feature is used. I don't think they're really problems as much as they are design choices or rather implication of stackless coroutines (or resumable functions). The problem is more that stackful coroutines (or fibers) are most likely not being considered now because "we got coroutines already", so we'll need to make due with boost.context - which is a black box for the compiler. The particular design issues I have with coroutines are minor things like no support for noexcept. It seems like they didn't bother updating std::coroutine_traits after noexcept became part of the function signature.