Re: [boost] [coroutine] new versions

Subject: Re: [boost] [coroutine] new versions
From: Eugene Yakubovich (eyakubovich_at_[hidden])
Date: 2012-10-10 21:33:13

I apologize for delayed response.

On Fri, Oct 5, 2012 at 10:22 AM, Oliver Kowalke <oliver.kowalke_at_[hidden]> wrote:
> Version 1) requires that coroutine-fn has only one argument ==
> coroutine<>::self_t. Other arguments are accessed via
> coroutine<>::self_t::get< int >() and results via coroutine<>::get().
> interface provides input/output iterators.
>
> typedef coroutine< int( int, int> > coro_t;
> int fn( coro_t::self_t & c) {
>     int x = c.get< 0 >();
>     int y = c.get< 1 >();
>     c.yield( x +y);
>     ...
> }
> coro_t coro( fn);
> int res = c( 3, 7).get();

I only like yield if there's a separate generator class. For general
coroutines, I would prefer the second version. But I'm torn if it
makes sense to have a separate generator class. It's just sugar but it
might lower the learning curve.

>
> Version 2) requires that coroutine-fn has only one argument too ==
> coroutine<> with inverted signature. Other arguments are access via
> coroutine<>::get().
> interface provides input/output iterators.
>
> typedef coroutine< int( int, int> > coro_t;
> int fn( coroutine< tuple< int, int >( int) & c) {
>     int x = c.get().get< 0 >();
>     int y = c.get().get< 1 >();
>     c( x +y);
>     ...
> }
> coro_t coro( fn);
> int res = c( 3, 7).get();

Overall, I do like this interface. Like I mentioned before, I would
like to see the coroutine-function with a void return type. Or have an
option for that. Maybe the coroutine can support both by looking at
the return type of the passed in function and adjusting accordingly.
The only problem with that is it would make it harder to have a type
deducing function, i.e. make_coroutine.

As for output iterators, I see that it's currently only supported for
coroutines with void return type and arity of 1. If a coroutine has a
non-void return type, output iterator can still be defined, just
ignore the return values. Maybe also support arbitrary arity by having
the iterator's value_type be a tuple for arities larger than 1.

Regards,
-Eugene