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

Subject: Re: [boost] [WG21 mailing] N4453 Resumable expressions
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-10-14 18:28:51

On 14/10/2015 08:32, Vinícius dos Santos Oliveira wrote:
> 2015-04-15 10:27 GMT-03:00 Niall Douglas <s_sourceforge_at_[hidden]>:
>
>> 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.