2015-04-15 21:27 GMT+08:00 Niall Douglas
I'm finding Chris' paper on resumable expressions instead of compiler magic created resumable functions awfully compelling:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4453.pdf
I essentially proposed the same with my functionally composed constexpr basic_future design some months ago.
Would anyone else like to comment on this library based instead of compiler based resumable execution? I'm not against some compiler support for resumable execution, but I am finding the await based proposal highly problematic, and Chris does an excellent job in summarising my own thoughts on what's wrong with it.
IIUC, this proposal requires more compiler magic and is definitely compiler based. Await/yield from the "Resumable Functions" proposal is not that mysterious as one may think, at least I can emulate it in some degree using preprocessor: (https://github.com/jamboree/co2) The main point of this proposal is the implicit propagation of the resumability, that is, if a function calls a resumable function, then the function itself becomes a resumable function, which makes the existing template-based algorithms also usable to resumable functions. A major benefit of this approach is that it provides a unified syntax for both stackful and stackless coroutine, and IMHO is better than the approach proposed in N4398. In general, I like the idea of N4453 and would love to see a working language implementation. That said, I do have some questions, for example, it's not clear to me that whether a ctor/dtor could be a resumable function or not, and there may be some other issues that I can't foresee without playing with it.