On 14/10/2015 08:32, VinÃcius dos Santos Oliveira wrote:
2015-04-15 10:27 GMT-03:00 Niall Douglas
: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4453.pdf
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). It goes on to admit this in section 12 and offers some library-based solutions, but makes a point of stating that these aren't part of the proposal itself. There are some things I like about this -- namely that it potentially allows for different library implementations for different requirements, and theoretically even the potential for application writers to completely customise it for certain needs (eg. enforcing certain mutex types or memory patterns). But this is also a potential complication -- look at all the entertainment we're already having with interop between different pointer/future/thread/mutex types. 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. But one advantage of await is that it does not have those limitations, and is intended to be used directly by application code with minimal library support.