2015-04-15 23:16 GMT+08:00 Niall Douglas
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?
The reference implementation is just an emulation, not what he's proposing, what he really proposed is to add a language feature.
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.
Both the types that you can await on and the types that you can return from a resumable function are extensible and not restricted to STL. 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.
What's your concern here? 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 resumable functions in Chris' proposal have to be visible to the compiler in the same TU, if you want them to be in another TU, you need to abstract the resumability away and thus need allocation.
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?
I was refering to Chris' resumable expressions.
The latter makes resumability like constexpr, and therefore resumability is caller determined instead of callee determined like the Microsoft proposal.
Well, it's just that you don't need the await keyword. I don't think describing resumable in analog of constexpr is a good idea, they seem to differ in many aspects.
Caller determined resumability has the enormous advantage that you only need to write implementations once, instead of with resumable and non-resumable variants.
As I said, the reusability and the unification are the major attractions of Chris' proposal.
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
A major benefit of this approach is that it provides a unified syntax for 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.
Now that I think of it, the resumable function in Chris' proposal is also not a first-class object, so I guess you can't take its type as it's completely a compile-time construct.