15.10.2015 1:28, Gavin Lambert:
revision 1 (p0114r0) is available: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0114r0.pdf
Let me just say up front that I'm definitely not an expert in this and I've only just recently read these and the await paper (N4286; not sure if there's a newer one). So please let me know if I've missed something.
It bothers me a bit that it imposes limitations on use (given in 7.6, and presumably present so that the compiler can unambiguously know the required stack size of the call chain) that would render it nearly useless for practical purposes (since most code is not header-only templates, except in certain library contexts).
As I understand only asynchronous/resumable chain of calls should be inlined. I.e. if you want to call future<T> some_function(); which uses resumable stuff inside - you don't need to see it's body. If you want to compile each function of asynchronous/resumable chain separately - then you can do this by using "await" on each level, not only at the bottom of call stack. So this choice is up to user.
I must admit to not being entirely happy with await (although most of my experience has been with C# code), due to some of the points mentioned in this paper (viral keywords, magic use of special library types, and duplication of implementation if desired to provide both async and non-async methods). However this proposal shares the latter limitation *unless* implemented as header-only templates (see 7.10 -- non-templates cannot be both resumable and non-resumable, even if header-only).> And where async and non-async methods are required to be separate, then viral keywords are not a bad thing as it makes it more obvious where the potential suspension points are.
Viral keywords have another drawback - each function in asynchronous chain is stand-alone state machine. As I understand P0114R0 attempts to fuse several state machines into one, what results in less overhead.