Re: [boost] [coroutine] Experimenting with interfaces

Subject: Re: [boost] [coroutine] Experimenting with interfaces
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2012-09-21 19:26:06

On Fri, Sep 21, 2012 at 7:59 PM, Oliver Kowalke <oliver.kowalke_at_[hidden]>wrote:

> Am 21.09.2012 20:09, schrieb Giovanni Piero Deretta:
>
>> On Fri, Sep 21, 2012 at 6:34 PM, Oliver Kowalke <oliver.kowalke_at_[hidden]
>> >wrote:
>>
>>>
>>> template <typename C>
>>> void timer(C c, chrono::seconds interval) {
>>>    //  while( interval != chrono::seconds::zero() ) {
>>>    //      this_thread::sleep_for(****interval);
>>>    //      interval = c(interval);
>>>    //  }
>>> }
>>>
>>> coroutine<chrono::seconds(****chrono::seconds)> c(
>>>      [](coroutine<chrono::seconds(****chrono::seconds)> c,
>>> chrono::seconds
>>> i) {
>>>          timer(c, i);
>>>      }
>>> );
>>>
>>> chrono::seconds s = c(chrono::seconds(1)); // [1]
>>>
>>> Which value has variable 's' after return from 'c(chrono::seconds(1))' ?
>>>
>>>  for seconds(1), it would simply return seconds(1), right? If you mean on
>> chrono::seconds::zero(), then the coroutine would return without yielding
>> any result. In this case, an option that would allow mantaining the
>> function-like interface would be to throw an exception from [1], or, if
>> operator() was called with std::nothrow as an additional first parameter,
>> return an optional. This was what the original library did on exceptional
>> returns and would work well here as well I guess. Note that 'coroutine'
>> could detect the result type of the coroutine-fn and decide what to do on
>> return depending on it, this way the user can decide the most natural
>> behaviour depending on the nature of the problem.
>>
>>  if the the coroutine function is forced to return the return type of the
> signature no exception must be thrown and optional is also not necessary.
>
>
yes, and that's the solution used by the original coroutine library, but
having to yield the last value sometimes makes for an innatural
coroutine-fn, especially if a loop is involved. Of course an easy way out
is for the user to explicitly specify optional<T> as the return type of the
coroutine and just return none at the end of the coroutine-fn (a small
sintatic sugar you could consider is, at coroutine exit,  to automatically
return a value constructed T if the coroutine has a nonvoid return type and
the coroutine-fn is void).

Anyways, any such extension could probably be added later in the library as
more experience is acquired.

-- gpd