2 ms·

Thanks your answer clarifies a lot. So my question was , as a mechanism to implement async operation how does C++ coroutine compares to this rust library. From

Thanks your answer clarifies a lot. So my question was , as a mechanism to implement async operation how does C++ coroutine compares to this rust library. From my understanding the C++ committee is pushing for the introduction of coroutine specifically because any library base approach would have the limitation you mentioned. Is that a correct ? You seems familiar with the C++ committee, do you know a good way to track a feature one is interested in ? I kinda lost track of the coroutine proposal after the 4 revision or Gor paper. By the beside Visual studio, any other compiler has a working implementation of the current draft ?

gpderetta 10y ago
Coroutines would still run on top of std::future, it would be Just syntactic sugar to avoid callback hell via then chaining. In same case this might save some allocation as the callback would be a plain pointer to the control block, but that's about it. I'm not part of the committee nor I attend meetings, but I follow the papers and the public online discussions.
- soulbadguy 10y ago
  From the last Gor paper, coroutine don't need to run on top of the std::future class. The type traits required allows for more computational patters (like generators, agent/actor, full coroutines) etc...
  - gpderetta 10y ago
    No, but they are still designed to work well with std::futures and that's going to be the standard blessed way to do async IO.