Re: [boost] [coroutine][review] Very Late Review

Subject: Re: [boost] [coroutine][review] Very Late Review
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-09-19 14:58:14

Le 19/09/12 18:21, Giovanni Piero Deretta a écrit :
> On Wed, Sep 19, 2012 at 2:20 AM, Vicente J. Botet Escriba <
> vicente.botet_at_[hidden]> wrote:
>
>> Le 19/09/12 01:47, Giovanni Piero Deretta a écrit :
>>
>>> On Tue, Sep 18, 2012 at 10:45 PM, Eugene Yakubovich
>>> <eyakubovich_at_[hidden]>wrote:
>>>
>>>   On Mon, Sep 17, 2012 at 11:24 AM, Giovanni Piero Deretta
>>>>> It has been suggested that coroutine::self be removed an have a thread
>>>>>
>>>>> specific object. I strongly disagree with this option. First of all it
>>>>>
>>>> will
>>>>
>>>>> make it too easy to break type safety:
>>>>>
>>>>> typedef this_coroutine<int(int)> this_coro;
>>>>>
>>>>> typedef this_coroutine<void()> that_coro;
>>>>>
>>>>> coroutine<int(int)>([]{
>>>>>          that_coro::yield(); // oops compiles fine, UB at runtime.
>>>>> });
>>>>>
>>>>>   This is a good point. I now think I'd prefer type safety here so I
>>>> agree that using a thread specific object is bad.
>>>>
>>>>
>>>>   Help me convince Oliver then ;).
>> Hi,
>>
>> I didn't know that Oliver was for the thread specific object design.
>>
>> I'm not sure the alternative I proposed is the best one. Compile type
>> safety is too important to be lost. Unfortunately I don't have a solution
>> that is type safe and that avoid to pass an additional parameter to the
>> coroutine function.
>>
> Why do you feel it is important not to pass the additional parameter?
I don't know which will be the good interface to provide coroutines by 
the language itself, but I think that there will not have such a 
parameter. I wanted to be as close as possible to this hypothetic 
interface. The same reason was the origin of the bind suggestion.
>
>
>> Oliver, I don't know if you can take care of both alternatives, so that we
>> can experiment with. If it is not the case, it seems that maintaing the
>> self/caller parameter is safer. The thread specific design could always be
>> built on top of actual design, isn't it?
>>
> A trivial adapter around the coroutine-fn would do it.
>
I believe so. This is way I think the library could provide both.

Best,
Vicente