Re: [boost] [WG21 mailing] N4453 Resumable expressions

Subject: Re: [boost] [WG21 mailing] N4453 Resumable expressions
From: Evgeny Panasyuk (evgeny.panasyuk_at_[hidden])
Date: 2015-10-14 22:24:13

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.