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

Subject: Re: [boost] [coroutine][review] Very Late Review
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2012-09-19 12:21:01

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?

>
> 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.