Boost logo

Boost :

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: (

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

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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at