Re: [boost] [coroutine] interface suggestion

Subject: Re: [boost] [coroutine] interface suggestion
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-09-21 02:02:50

Le 20/09/12 15:41, Giovanni Piero Deretta a écrit :
> On Thu, Sep 20, 2012 at 12:17 PM, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> wrote:
>
>> Le 20/09/12 12:18, Giovanni Piero Deretta a écrit :
>>
>>   On Thu, Sep 20, 2012 at 3:51 AM, Vicente J. Botet Escriba <
>>> vicente.botet_at_[hidden]> wrote:
>>>
>>>> Note that as I commented in some of my first post related to bind, you
>>>> must take care of const and reference  parameters in some tricky ways, as
>>>> in order to be able to reassign them you should do some casts. I hope
>>>> this
>>>> will not cache some undefined behavior.
>>>>
>>>>   How would you exactly rebind references? I can't see any sane way to do
>>> it.
>>>
>> Yes, references could not be rebound. We could rebind types, pointers but
>> not references.
>> I guess the coroutine library could store a pointer on the caller object,
>> and allow to obtain them using get<>. But in this case the coroutine
>> function could not follow the coroutine signature.
>
> you mean that caller_t::yield does not really model "int&()"? Well, this is
> an issue. As far I understand, currently Oliver is leaning on passing the
> parameters to the coroutine-fn, having yield() return a tuple, and having
> the coroutine-fn return the final result. This means that yield() will
> closely follow the signature and everything is fine.
Well, this is the initial design that was the source of all the 
alternative proposals. I have voted YES for the inclusion of the library 
without conditions. So if at the end this the original interface is 
retained it will be Ok for me.

After a more deep analysis of the alternatives I have proposed it seems 
that none make easier to write used code:
* bind can not be used with references, limiting the coroutine interface 
to don't use references is not a solution.
* access to the coroutine parameter using get, while it ensures a 
uniform and safe way to obtain them, is not easier to read, and in this 
case the coroutine function shouldn't follow the coroutine signature, 
which for some of you make the interface type unsafe.

>
> If instead he decides to go with the get<> interface, then maybe it is time
> to abandon the coroutine as a function model.
>
Could you elaborate more on the alternative model you are suggesting?

Best,
Vicente