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

Subject: Re: [boost] [WG21 mailing] N4453 Resumable expressions
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-04-15 11:16:34

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?

> 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.

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.

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 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?

The latter makes resumability like constexpr, and therefore 
resumability is caller determined instead of callee determined like 
the Microsoft proposal.

Caller determined resumability has the enormous advantage that you 
only need to write implementations once, instead of with resumable 
and non-resumable variants.

> A major benefit of this approach is that it provides a unified syntax for
> 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 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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/