On Wed, Apr 3, 2013 at 4:17 PM,  <lcidfire@gmail.com> wrote:
> Since I am beginning to code using the N3558 extension I wonder whether
> std::future could use another retrieval operator.
> When using containers one can choose to use std::vector::operator[] or
> std::vector::at. Similarly, using std::future::get could get a
> non-checking/waiting variant with std::future::operator(), Personally I
> would prefer this because calling std::future::get in a then-lambda just
> looks wrong (semantically) because in my head this get function is
> associated with (possible) waiting/blocking.

A few other libraries handle this by unpacking the future when passing
the result to the .then() callback instead of passing the raw future.
Of course, then you need a way to pass the exception, but
std::exception_ptr looks sufficient, contrary to the statement in
N3558 that "this option is not viable in C++ as there is no single
base type for exceptions as there is in JavaScript."

Jeffrey

--

---
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 email 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-proposals/?hl=en.



.

I do agree Jeffrey.
The sheer amount of code necessary only to extract the actual values
out of a when_all callback is pretty annoying.
Perhaps it would make sense to add a when_all_values function, which
unpacks the values.

On Wed, Apr 3, 2013 at 4:26 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> On Wed, Apr 3, 2013 at 4:17 PM,  <lcidfire@gmail.com> wrote:
>> Since I am beginning to code using the N3558 extension I wonder whether
>> std::future could use another retrieval operator.
>> When using containers one can choose to use std::vector::operator[] or
>> std::vector::at. Similarly, using std::future::get could get a
>> non-checking/waiting variant with std::future::operator(), Personally I
>> would prefer this because calling std::future::get in a then-lambda just
>> looks wrong (semantically) because in my head this get function is
>> associated with (possible) waiting/blocking.
>
> A few other libraries handle this by unpacking the future when passing
> the result to the .then() callback instead of passing the raw future.
> Of course, then you need a way to pass the exception, but
> std::exception_ptr looks sufficient, contrary to the statement in
> N3558 that "this option is not viable in C++ as there is no single
> base type for exceptions as there is in JavaScript."
>
> Jeffrey
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/gvAQPszt8lI/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email 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-proposals/?hl=en.
>
>

--

---
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 email 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-proposals/?hl=en.



.

That's what when_all() was specified to do in our Portland proposal, and we received strong feedback to **not** unpack the futures.

Niklas

-----Original Message-----
From: lcidfire@googlemail.com [mailto:lcidfire@gmail.com]
Sent: Wednesday, April 3, 2013 07:36
To: std-proposals@isocpp.org
Cc: Niklas Gustafsson
Subject: Re: [std-proposals] N3558: Add (fast) non-checking invocation operator to std::future

I do agree Jeffrey.
The sheer amount of code necessary only to extract the actual values out of a when_all callback is pretty annoying.
Perhaps it would make sense to add a when_all_values function, which unpacks the values.

On Wed, Apr 3, 2013 at 4:26 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> On Wed, Apr 3, 2013 at 4:17 PM,  <lcidfire@gmail.com> wrote:
>> Since I am beginning to code using the N3558 extension I wonder
>> whether std::future could use another retrieval operator.
>> When using containers one can choose to use std::vector::operator[]
>> or std::vector::at. Similarly, using std::future::get could get a
>> non-checking/waiting variant with std::future::operator(), Personally
>> I would prefer this because calling std::future::get in a then-lambda
>> just looks wrong (semantically) because in my head this get function
>> is associated with (possible) waiting/blocking.
>
> A few other libraries handle this by unpacking the future when passing
> the result to the .then() callback instead of passing the raw future.
> Of course, then you need a way to pass the exception, but
> std::exception_ptr looks sufficient, contrary to the statement in
> N3558 that "this option is not viable in C++ as there is no single
> base type for exceptions as there is in JavaScript."
>
> Jeffrey
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/gvAQPszt8lI/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email 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-proposals/?hl=en.
>
>


--

---
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 email 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-proposals/?hl=en.



.

We have run into very little user issues with PPL and its ".get() doesn't b=
lock once the task is complete" rule (PPL task<T> =3D=3D std::shared_future=
<T>), the same as for N3558. That the task has been completed when .then() =
is called seems to not lead to too much confusion in the minds of our PPL u=
sers. A performance-based argument for a faster retrieval mechanism makes s=
ense, but it would still have to do a check and fail (through whatever mech=
anism) if the future has not been filled with a value or exception.

PPL does give you the option of using either a task<T> or a T as the argume=
nt to the callback object passed to .then(). As this leads to some complexi=
ty both in implementation, and, we have found, in user education, we opted =
to not include this in our proposal for extensions to std::future<T>. In Po=
rtland, we also received feedback from SG1 in the context of when_all(), th=
at unpacking a future was not something that the library should do automagi=
cally.

std::exception_ptr is, indeed, sufficient, but passing it in along with the=
 result is also inelegant in my opinion, since the future already holds it =
and you essentially have to rethrow to inspect it, exactly what .get() does=
 for you.

FWIW,

Niklas

-----Original Message-----
From: Jeffrey Yasskin [mailto:jyasskin@google.com]=20
Sent: Wednesday, April 3, 2013 07:27
To: std-proposals@isocpp.org
Cc: Niklas Gustafsson
Subject: Re: [std-proposals] N3558: Add (fast) non-checking invocation oper=
ator to std::future

On Wed, Apr 3, 2013 at 4:17 PM,  <lcidfire@gmail.com> wrote:
> Since I am beginning to code using the N3558 extension I wonder=20
> whether std::future could use another retrieval operator.
> When using containers one can choose to use std::vector::operator[] or=20
> std::vector::at. Similarly, using std::future::get could get a=20
> non-checking/waiting variant with std::future::operator(), Personally=20
> I would prefer this because calling std::future::get in a then-lambda=20
> just looks wrong (semantically) because in my head this get function=20
> is associated with (possible) waiting/blocking.

A few other libraries handle this by unpacking the future when passing the =
result to the .then() callback instead of passing the raw future.
Of course, then you need a way to pass the exception, but std::exception_pt=
r looks sufficient, contrary to the statement in
N3558 that "this option is not viable in C++ as there is no single base typ=
e for exceptions as there is in JavaScript."

Jeffrey



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



.

BTW, the reasoning I find most convincing for providing the futures from when_all() rather than the values has to do with exception propagation.

The previous proposal (what we presented in Portland) stated that one (non-deterministically chosen) of the input futures' exceptions would be propagated by the future result of when_all().

Here are the problems with that:

1. If there's an exception, and I passed in futures to when_all(), what happens to the values of all the futures that do not propagate exceptions?

2. If there's more than one future with an exception, the other exceptions (which may be more important) are lost.

By having when_all() provide the input futures rather than their values we avoid both issues.


Niklas

-----Original Message-----
From: Niklas Gustafsson
Sent: Wednesday, April 3, 2013 07:50
To: 'lcidfire@googlemail.com'; std-proposals@isocpp.org
Subject: RE: [std-proposals] N3558: Add (fast) non-checking invocation operator to std::future

That's what when_all() was specified to do in our Portland proposal, and we received strong feedback to **not** unpack the futures.

Niklas

-----Original Message-----
From: lcidfire@googlemail.com [mailto:lcidfire@gmail.com]
Sent: Wednesday, April 3, 2013 07:36
To: std-proposals@isocpp.org
Cc: Niklas Gustafsson
Subject: Re: [std-proposals] N3558: Add (fast) non-checking invocation operator to std::future

I do agree Jeffrey.
The sheer amount of code necessary only to extract the actual values out of a when_all callback is pretty annoying.
Perhaps it would make sense to add a when_all_values function, which unpacks the values.

On Wed, Apr 3, 2013 at 4:26 PM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> On Wed, Apr 3, 2013 at 4:17 PM,  <lcidfire@gmail.com> wrote:
>> Since I am beginning to code using the N3558 extension I wonder
>> whether std::future could use another retrieval operator.
>> When using containers one can choose to use std::vector::operator[]
>> or std::vector::at. Similarly, using std::future::get could get a
>> non-checking/waiting variant with std::future::operator(), Personally
>> I would prefer this because calling std::future::get in a then-lambda
>> just looks wrong (semantically) because in my head this get function
>> is associated with (possible) waiting/blocking.
>
> A few other libraries handle this by unpacking the future when passing
> the result to the .then() callback instead of passing the raw future.
> Of course, then you need a way to pass the exception, but
> std::exception_ptr looks sufficient, contrary to the statement in
> N3558 that "this option is not viable in C++ as there is no single
> base type for exceptions as there is in JavaScript."
>
> Jeffrey
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/gvAQPszt8lI/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email 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-proposals/?hl=en.
>
>


--

---
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 email 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-proposals/?hl=en.



.

--089e01227b945d276504d977cc35
Content-Type: text/plain; charset=ISO-8859-1

"[...] but it would still have to do a check and fail (through whatever
mechanism) if the future has not been filled with a value or exception."
Why is that?. Why does it *have* to check? std::vector::operator[] with an
invalid index results in undefined behavior, I would expect the same for a
std::future::operator().


On Wed, Apr 3, 2013 at 4:47 PM, Niklas Gustafsson <
Niklas.Gustafsson@microsoft.com> wrote:

> We have run into very little user issues with PPL and its ".get() doesn't
> block once the task is complete" rule (PPL task<T> ==
> std::shared_future<T>), the same as for N3558. That the task has been
> completed when .then() is called seems to not lead to too much confusion in
> the minds of our PPL users. A performance-based argument for a faster
> retrieval mechanism makes sense, but it would still have to do a check and
> fail (through whatever mechanism) if the future has not been filled with a
> value or exception.
>
> PPL does give you the option of using either a task<T> or a T as the
> argument to the callback object passed to .then(). As this leads to some
> complexity both in implementation, and, we have found, in user education,
> we opted to not include this in our proposal for extensions to
> std::future<T>. In Portland, we also received feedback from SG1 in the
> context of when_all(), that unpacking a future was not something that the
> library should do automagically.
>
> std::exception_ptr is, indeed, sufficient, but passing it in along with
> the result is also inelegant in my opinion, since the future already holds
> it and you essentially have to rethrow to inspect it, exactly what .get()
> does for you.
>
> FWIW,
>
> Niklas
>
> -----Original Message-----
> From: Jeffrey Yasskin [mailto:jyasskin@google.com]
> Sent: Wednesday, April 3, 2013 07:27
> To: std-proposals@isocpp.org
> Cc: Niklas Gustafsson
> Subject: Re: [std-proposals] N3558: Add (fast) non-checking invocation
> operator to std::future
>
> On Wed, Apr 3, 2013 at 4:17 PM,  <lcidfire@gmail.com> wrote:
> > Since I am beginning to code using the N3558 extension I wonder
> > whether std::future could use another retrieval operator.
> > When using containers one can choose to use std::vector::operator[] or
> > std::vector::at. Similarly, using std::future::get could get a
> > non-checking/waiting variant with std::future::operator(), Personally
> > I would prefer this because calling std::future::get in a then-lambda
> > just looks wrong (semantically) because in my head this get function
> > is associated with (possible) waiting/blocking.
>
> A few other libraries handle this by unpacking the future when passing the
> result to the .then() callback instead of passing the raw future.
> Of course, then you need a way to pass the exception, but
> std::exception_ptr looks sufficient, contrary to the statement in
> N3558 that "this option is not viable in C++ as there is no single base
> type for exceptions as there is in JavaScript."
>
> Jeffrey
>
>
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/gvAQPszt8lI/unsubscribe?hl=en
> .
> To unsubscribe from this group and all its topics, send an email 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-proposals/?hl=en.
>
>
>

--

---
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 email 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-proposals/?hl=en.



--089e01227b945d276504d977cc35
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&quot;[...] but it would still have to do a check and fail=
 (through whatever mechanism) if the future has not been filled with a valu=
e or exception.&quot;<div>Why is that?. Why does it <b>have</b> to check? <=
font face=3D"courier new, monospace">std::vector::operator[]</font> with an=
 invalid index results in undefined behavior, I would expect the same for a=
 <font face=3D"courier new, monospace">std::future::operator().</font></div=
>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed,=
 Apr 3, 2013 at 4:47 PM, Niklas Gustafsson <span dir=3D"ltr">&lt;<a href=3D=
"mailto:Niklas.Gustafsson@microsoft.com" target=3D"_blank">Niklas.Gustafsso=
n@microsoft.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">We have run into very little user issues wit=
h PPL and its &quot;.get() doesn&#39;t block once the task is complete&quot=
; rule (PPL task&lt;T&gt; =3D=3D std::shared_future&lt;T&gt;), the same as =
for N3558. That the task has been completed when .then() is called seems to=
 not lead to too much confusion in the minds of our PPL users. A performanc=
e-based argument for a faster retrieval mechanism makes sense, but it would=
 still have to do a check and fail (through whatever mechanism) if the futu=
re has not been filled with a value or exception.<br>

<br>
PPL does give you the option of using either a task&lt;T&gt; or a T as the =
argument to the callback object passed to .then(). As this leads to some co=
mplexity both in implementation, and, we have found, in user education, we =
opted to not include this in our proposal for extensions to std::future&lt;=
T&gt;. In Portland, we also received feedback from SG1 in the context of wh=
en_all(), that unpacking a future was not something that the library should=
 do automagically.<br>

<br>
std::exception_ptr is, indeed, sufficient, but passing it in along with the=
 result is also inelegant in my opinion, since the future already holds it =
and you essentially have to rethrow to inspect it, exactly what .get() does=
 for you.<br>

<br>
FWIW,<br>
<br>
Niklas<br>
<div class=3D"im HOEnZb"><br>
-----Original Message-----<br>
From: Jeffrey Yasskin [mailto:<a href=3D"mailto:jyasskin@google.com">jyassk=
in@google.com</a>]<br>
Sent: Wednesday, April 3, 2013 07:27<br>
To: <a href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a=
><br>
Cc: Niklas Gustafsson<br>
Subject: Re: [std-proposals] N3558: Add (fast) non-checking invocation oper=
ator to std::future<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">On Wed, Apr 3, 2013 at 4:17 P=
M, =A0&lt;<a href=3D"mailto:lcidfire@gmail.com">lcidfire@gmail.com</a>&gt; =
wrote:<br>
&gt; Since I am beginning to code using the N3558 extension I wonder<br>
&gt; whether std::future could use another retrieval operator.<br>
&gt; When using containers one can choose to use std::vector::operator[] or=
<br>
&gt; std::vector::at. Similarly, using std::future::get could get a<br>
&gt; non-checking/waiting variant with std::future::operator(), Personally<=
br>
&gt; I would prefer this because calling std::future::get in a then-lambda<=
br>
&gt; just looks wrong (semantically) because in my head this get function<b=
r>
&gt; is associated with (possible) waiting/blocking.<br>
<br>
A few other libraries handle this by unpacking the future when passing the =
result to the .then() callback instead of passing the raw future.<br>
Of course, then you need a way to pass the exception, but std::exception_pt=
r looks sufficient, contrary to the statement in<br>
N3558 that &quot;this option is not viable in C++ as there is no single bas=
e type for exceptions as there is in JavaScript.&quot;<br>
<br>
Jeffrey<br>
<br>
<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/gvAQPszt8lI/unsubscribe?hl=3Den" target=
=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/gv=
AQPszt8lI/unsubscribe?hl=3Den</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
<br>
<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--089e01227b945d276504d977cc35--

.