On Wed, Sep 19, 2012 at 2:20 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
Le 19/09/12 01:47, Giovanni Piero Deretta a écrit :
On Tue, Sep 18, 2012 at 10:45 PM, Eugene Yakubovich <eyakubovich@gmail.com>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
Le 19/09/12 18:21, Giovanni Piero Deretta a écrit : 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