On Sun, Apr 28, 2013 at 9:51 AM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Hi,
>
> during a discussion on Boost about a expected class, we have identified a
> then() function that behaves a little bit different from the one proposed=
 in
> N3558.
> I would like to see if the variation we have identified for the expected
> class would be as well good for futures.
>
> In order to simplify the user code the continuation function has a
> value_type as parameter instead of a future reference and is called only =
if
> the future is valid. Instead of
>
> future<int> f1 =3D async([]() {return 123;});
> future<string> f2 =3D f1.then([](future<int> f) {
> return f.get().to_string();
> // here .get() won=92t block
> });
>
> we can write
>
> future<string> f2 =3D f1.then([](int const & i) {
> return i.to_string();
> });
>
> BTW, I don't reach to identify in the proposal what is the state of futur=
e
> obtained with then() if the continuation throws. I would expect the
> exception to be stored on in this future. Is this correct?
>
> The result of the continuation function could be another value type or a
> future. Returning a future from the continuation could improve the
> performances in cases where the function is directly the originator of th=
e
> exception.
>
> future<int> f2 =3D f1.then([](string const & s) -> future<string> {
> int i;
> if (parse_int(s, i)) return make_ready_future(i);
> else make_exceptional_future<int>("Parse error");
> });
>
>
> When the future is not valid the result of the then() call is a future wi=
th
> the exception, so that the first exception is transported during the whol=
e
> chain.
>
> auto r =3D f().then(g).then(h);
>
> If f() returns a future set with an exception, g and h would not be calle=
d
> at all and r would contain the original exception. If the user access to
> r.get() the exception will be thrown.
>
> To complete the chain we could add a continuation with an on_exception
> function that calls its continuation only if the future has an exception.
>
> f().then(g).then(h).on_exception(eh);
>
> What do you think of this variation?

Look at the Future equivalents in Javascript and Twisted for some
inspiration here. They tend to have "future<T>::then(function<U(T)>,
function<U(exception)>)->future<U>", where the second function is
optional, and the exception is propagated if it's missing. They
sometimes automatically turn future<future<U>> into future<U>, and I
think that's what was decided in Bristol for C++ futures too.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

Le 28/04/13 19:09, Jeffrey Yasskin a =E9crit :
> On Sun, Apr 28, 2013 at 9:51 AM, Vicente J. Botet Escriba
> <vicente.botet@wanadoo.fr> wrote:
>> Hi,
>>
>> during a discussion on Boost about a expected class, we have identified =
a
>> then() function that behaves a little bit different from the one propose=
d in
>> N3558.
>> I would like to see if the variation we have identified for the expected
>> class would be as well good for futures.
>>
>> In order to simplify the user code the continuation function has a
>> value_type as parameter instead of a future reference and is called only=
 if
>> the future is valid. Instead of
>>
>> future<int> f1 =3D async([]() {return 123;});
>> future<string> f2 =3D f1.then([](future<int> f) {
>> return f.get().to_string();
>> // here .get() won=92t block
>> });
>>
>> we can write
>>
>> future<string> f2 =3D f1.then([](int const & i) {
>> return i.to_string();
>> });
>>
>> BTW, I don't reach to identify in the proposal what is the state of futu=
re
>> obtained with then() if the continuation throws. I would expect the
>> exception to be stored on in this future. Is this correct?
>>
>> The result of the continuation function could be another value type or a
>> future. Returning a future from the continuation could improve the
>> performances in cases where the function is directly the originator of t=
he
>> exception.
>>
>> future<int> f2 =3D f1.then([](string const & s) -> future<string> {
>> int i;
>> if (parse_int(s, i)) return make_ready_future(i);
>> else make_exceptional_future<int>("Parse error");
>> });
>>
>>
>> When the future is not valid the result of the then() call is a future w=
ith
>> the exception, so that the first exception is transported during the who=
le
>> chain.
>>
>> auto r =3D f().then(g).then(h);
>>
>> If f() returns a future set with an exception, g and h would not be call=
ed
>> at all and r would contain the original exception. If the user access to
>> r.get() the exception will be thrown.
>>
>> To complete the chain we could add a continuation with an on_exception
>> function that calls its continuation only if the future has an exception=
..
>>
>> f().then(g).then(h).on_exception(eh);
>>
>> What do you think of this variation?
> Look at the Future equivalents in Javascript and Twisted for some
> inspiration here. They tend to have "future<T>::then(function<U(T)>,
> function<U(exception)>)->future<U>", where the second function is
> optional, and the exception is propagated if it's missing. They
> sometimes automatically turn future<future<U>> into future<U>, and I
> think that's what was decided in Bristol for C++ futures too.
>
I was aware of the two functions alternative but not that it was decided=20
to change the then interface. I didn't found nothing on the TWiki, where=20
can I read the minutes containing this decision?

I don't know if you could answer this question

BTW, I don't reach to identify in the proposal what is the state of future
obtained with then() if the continuation throws. I would expect the
exception to be stored on in this future. Is this correct? Could you point =
me where it is written?

Best,
Vicente


--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.