Boost logo

Boost :

Subject: Re: [boost] [next gen future-promise] What to callthemonadicreturntype?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-06-01 12:51:09


Le 01/06/15 17:32, Gottlob Frege a écrit :
> On Sun, May 31, 2015 at 6:25 PM, Vicente J. Botet Escriba
> <vicente.botet_at_[hidden]> wrote:
>> Le 30/05/15 22:49, Peter Dimov a écrit :
>>> Vicente J. Botet Escriba wrote:
>>>>>> Surely for catch_error() one must always return the same type of
>>>>>> future >> as the input? Otherwise it couldn't work when f1 has a value.
>>>>> Vicente in N4048 says that it's not required to return the same type.
>>>>>
>>>> If I said that it was an error. Could you point me where?
>>>
>>> Input Parameters:
>>> • Lambda function: The lambda function on map()/bind() takes a
>>> future<t>::value_type. The lambda
>>> function on catch_error() takes an exception_ptr. Both could return
>>> whatever type. This makes propagating
>>> exceptions straightforward. This approach also simplifies the chaining of
>>> continuations.
>>>
>>>
>> Thanks. I suspect I was referring to map and bind. future<T>::cath_error
>> must return T or future<T>. I recognize that it is not clear in the N4048.
>>
>> Initially catch_error() was called recover(). It can be used to recover from
>> errors and then the function returns a value or a future ready with a value
>> and also to change the reported error, in this case the function should
>> return future<T> ready with an exception.
>>
>
> I can imagine catch_error() returning something _convertible_
>
>> future<X> f1 = async( ... );
>> future<Y> f2 = f1.catch_error( []( exception_ptr e ) { return Y(); } );
> Y needs to be convertible from X.
The opposite is also possible. The continuation can return a type Y
convertible to X

     future<X> f1 = async( ... );
     future<X> f2 = f1.catch_error( []( exception_ptr e ) { return Y(); } );

> Not sure there is much value in that, however.
I have not needed it.
>
> P.S. can I specialize std::future<MyType> ? And does that just cause
> headaches for the STL?
>
No and I don't know. Do you have a use case that would need specialization?

Vicente


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk