Re: [boost] {Review] Coroutine reviewstarts today, September 3rd

Subject: Re: [boost] {Review] Coroutine reviewstarts today, September 3rd
From: Eugene Yakubovich (eyakubovich_at_[hidden])
Date: 2012-09-11 11:43:14

>> Maybe we can change behavior so that generator's constructor does not
>> invoke the generator-function, only operator() does. And change
>> operator() to return optional<R> instead of R. The usage can then be:
>>
>> gen_t g(foo);
>> while( optional<X> val = g() ) {
>>     // use val.get()
>> }
>
> what would be the benefit?
>

This would eliminate the "early destruction" problem described before.
The generator would end up not storing a value (which it currently
does in detail::generator_resume::result_) and operator() would just
return whatever the generator-function yielded or optional<none> if
the generator-function exited.

> Shouldn't iterators be implemented on top of generators/coroutines?
>

Yes, that is definitely a good option. My thinking of putting the
iterator "inside" the generator was to potentially avoid constructing
optional<R> -- which would otherwise be needed if the generator's
interface was like the one proposed above. Iterator could then use
private methods of generator and not the public interface. I'm not
sure if there's really any overhead to constructing optional<R> so it
might not really matter.

Also, looks like Boost.Optional does not yet support moveable-only
types so having the iterators not use it can bring quicker support of
movable-only types (after tuples support them). Granted, only the
iterator interface would be usable with movable-only types.

Oliver, if you would like, I can code up my proposed changes and send
in the patch. It might make it easier to explore the design.

Regards,
Eugene