On 15 Apr 2015 at 22:55, TONGARI J wrote:
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.
This surprises me. He provides a reference implementation library which appears functionally complete except for the error checking which does require a compiler pass. The only compiler support needed is for reporting error messages, or at least that's what I read?
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)
By "compiler magic" I mean a new compiler keyword which returns a STL type, and assumes a great deal about how that STL type is implemented. I find that possibly okay for brand new STL types newly added. I find that deeply worrying for existing STL types. Even with their proposed generic all types of future traits support. I also feel that resumable functions need to not require allocating memory. I know they hacked MSVC to magically optimise out the memory allocation in the future<T>, but that doesn't appeal to me.
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.
Does this paragraph refer to the Microsoft resumable functions or to Chris' resumable expressions? The latter makes resumability like constexpr, and therefore resumability is caller determined instead of callee determined like the Microsoft proposal. Caller determined resumability has the enormous advantage that you only need to write implementations once, instead of with resumable and non-resumable variants.
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.
It seems to me that a constructor is an expression, and therefore capable of being resumed under Chris' proposal. The object being constructed would, I assume, remain partially constructed. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/