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

Subject: Re: [boost] [WG21 mailing] N4453 Resumable expressions
From: TONGARI J (tongari95_at_[hidden])
Date: 2015-04-15 12:25:42

2015-04-15 23:16 GMT+08:00 Niall Douglas <s_sourceforge_at_[hidden]>:

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

 The reference implementation is just an emulation, not what he's
proposing, what he really proposed is to add a language feature.

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

Both the types that you can await on and the types that you can return from
a resumable function are extensible and not restricted to STL.

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

What's your concern here?

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 resumable functions in Chris' proposal have to be visible to the
compiler in the same TU, if you want them to be in another TU, you need to
abstract the resumability away and thus need allocation.

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

I was refering to Chris' resumable expressions.

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

Well, it's just that you don't need the await keyword.
I don't think describing resumable in analog of constexpr is a good idea,
they seem to differ in many aspects.

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

As I said, the reusability and the unification are the major attractions of
Chris' proposal.

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

Now that I think of it, the resumable function in Chris' proposal is also
not a first-class object, so I guess you can't take its type as it's
completely a compile-time construct.