------=_Part_2438_4765619.1391433165610
Content-Type: text/plain; charset=UTF-8

While implementing parts of N3784 with libc++, I encountered the situation,
that I wanted to return a "future" from a function, that can NOT be
accessed synchronously.

I now thought about adding the following two functions:

template< class Type >
continuator async_cast(std::future<Type> fut) noexcept;
 template< class Type >
shared_continuator async_cast(std::shared_future<Type> fut) noexcept;

The difference for the continuator is, that it does not have a blocking get and only works asynchronously.
The question is whether this is a common scenario. And if such a continuator is added, whether it would make sense to composite the future classes out of a continuator.

--

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

------=_Part_2438_4765619.1391433165610
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">While implementing parts of N3784 with libc++, I encounter=
ed the situation, that I wanted to return a "future" from a function, that =
can NOT be accessed synchronously.<div><br></div><div>I now thought about a=
dding the following two functions:</div><div><br></div><div><pre class=3D"l=
ine-pre" style=3D"font-size: 12px; line-height: 16.799999237060547px; width=
: 744px; color: rgb(0, 0, 0);"><div class=3D"line" id=3D"file-future-LC9" s=
tyle=3D"font-family: Consolas, 'Liberation Mono', Courier, monospace;">temp=
late&lt; class Type &gt;</div><div class=3D"line" id=3D"file-future-LC10" s=
tyle=3D"font-family: Consolas, 'Liberation Mono', Courier, monospace;">cont=
inuator async_cast(std::future&lt;Type&gt; fut) noexcept;</div><div class=
=3D"line" id=3D"file-future-LC11" style=3D"font-family: Consolas, 'Liberati=
on Mono', Courier, monospace;"> </div><div class=3D"line" id=3D"file-future=
-LC12" style=3D"font-family: Consolas, 'Liberation Mono', Courier, monospac=
e;">template&lt; class Type &gt;</div><div class=3D"line" id=3D"file-future=
-LC13" style=3D"font-family: Consolas, 'Liberation Mono', Courier, monospac=
e;">shared_continuator async_cast(std::shared_future&lt;Type&gt; fut) noexc=
ept;</div><div class=3D"line" id=3D"file-future-LC13"><font face=3D"arial, =
sans-serif"><br></font></div><div class=3D"line" id=3D"file-future-LC13"><f=
ont face=3D"arial, sans-serif">The difference for the continuator is, that =
it does not have a blocking </font><font face=3D"verdana, sans-serif">get a=
nd only works asynchronously</font><font face=3D"arial, sans-serif">.</font=
></div><div class=3D"line" id=3D"file-future-LC13"><font face=3D"arial, san=
s-serif">The question is whether this is a common scenario. And if such a c=
ontinuator is added, whether it would make sense to composite the future cl=
asses out of a continuator.</font></div></pre></div></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2438_4765619.1391433165610--

.

------=_Part_539_22421895.1391616526638
Content-Type: text/plain; charset=UTF-8

On Monday, February 3, 2014 7:12:45 AM UTC-6, lcid...@gmail.com wrote:
>
> While implementing parts of N3784 with libc++, I encountered the
> situation, that I wanted to return a "future" from a function, that can NOT
> be accessed synchronously.
>
>
Could you elaborate on those situations? What does it mean that a "future"
cannot be accessed synchronously? What would happen if I did access that
"future" synchronously?


> I now thought about adding the following two functions:
>
> template< class Type >
> continuator async_cast(std::future<Type> fut) noexcept;
>  template< class Type >
> shared_continuator async_cast(std::shared_future<Type> fut) noexcept;
>
> The difference for the continuator is, that it does not have a blocking get and only works asynchronously.
>
>
Would you care to provide more detail about this "continuator"? I assume it
doesn't have `wait` either, but that's just me guessing...


> The question is whether this is a common scenario. And if such a continuator is added, whether it would make sense to composite the future classes out of a continuator.
>
>
You hardly explained which scenario is that. Why don't you start by
explaining your scenario, the problems a regular future would present, and
how your "continuation" fix them first?

--

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

------=_Part_539_22421895.1391616526638
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, February 3, 2014 7:12:45 AM UTC-6, lcid...@gmai=
l.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">W=
hile implementing parts of N3784 with libc++, I encountered the situation, =
that I wanted to return a "future" from a function, that can NOT be accesse=
d synchronously.<div><br></div></div></blockquote><div><br>Could you elabor=
ate on those situations? What does it mean that a "future" cannot be access=
ed synchronously? What would happen if I did access that "future" synchrono=
usly?<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div></div><div>I now thought about adding the following two funct=
ions:</div><div><br></div><div><pre style=3D"font-size:12px;line-height:16.=
799999237060547px;width:744px;color:rgb(0,0,0)"><div style=3D"font-family:C=
onsolas,'Liberation Mono',Courier,monospace">template&lt; class Type &gt;</=
div><div style=3D"font-family:Consolas,'Liberation Mono',Courier,monospace"=
>continuator async_cast(std::future&lt;Type&gt; fut) noexcept;</div><div st=
yle=3D"font-family:Consolas,'Liberation Mono',Courier,monospace"> </div><di=
v style=3D"font-family:Consolas,'Liberation Mono',Courier,monospace">templa=
te&lt; class Type &gt;</div><div style=3D"font-family:Consolas,'Liberation =
Mono',Courier,monospace">shared_continuator async_cast(std::shared_future&l=
t;<wbr>Type&gt; fut) noexcept;</div><div><font face=3D"arial, sans-serif"><=
br></font></div><div><font face=3D"arial, sans-serif">The difference for th=
e continuator is, that it does not have a blocking </font><font face=3D"ver=
dana, sans-serif">get and only works asynchronously</font><font face=3D"ari=
al, sans-serif">.</font></div></pre></div></div></blockquote><div><br>Would=
 you care to provide more detail about this "continuator"? I assume it does=
n't have `wait` either, but that's just me guessing...<br>&nbsp;</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><pre style=3D=
"font-size:12px;line-height:16.799999237060547px;width:744px;color:rgb(0,0,=
0)"><div><font face=3D"arial, sans-serif">The question is whether this is a=
 common scenario. And if such a continuator is added, whether it would make=
 sense to composite the future classes out of a continuator.</font></div></=
pre></div></div></blockquote><div><br>You hardly explained which scenario i=
s that. Why don't you start by explaining your scenario, the problems a reg=
ular future would present, and how your "continuation" fix them first? <br>=
</div></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_539_22421895.1391616526638--

.

------=_Part_507_29093188.1391620731787
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sorry, Agustin, I'll try to be more precise.
The situation is that I have a download task. Lets say I have a function st=
d::future=20
downloadFile(string url). Now I want to declare this for multiple=20
platforms. I there make a distinction between desktop platforms (e.g.=20
Linux) and server and embedded ones (e.g. Emscripten). The distinction is=
=20
that code on the latter ones is only run in certain threads, which can not=
=20
be (indirectly) controlled. As such, one thread is processing one program=
=20
and I thus do not want any blocking operation in this thread. Then of=20
course (to prevent novices from shooting themselves in the leg), I do not=
=20
want the blocking aspects of std::future. So this leads me to have the=20
following declaration:

#ifdef PLATFORM_USES_MULTIPLE_THREADS
std::future downloadFile(string url);
#else
std::continuator downloadFile(string url);
#endif

Now the interface of the continuator would look something like* (* hugely=
=20
simplified):

template< class T >
class continuator {
  std::shared_continuator<T> share();
  T get();
  bool valid() const;
  bool is_ready() const;
  template<typename F>
  auto then(F&& func) -> future<decltype(func(*this))>;=20
  template<typename F>=20
  auto then(executor &ex, F&& func) -> future<decltype(func(move(*this)))>;=
=20
  template<typename F>=20
  auto then(launch policy, F&& func) ->=20
future<decltype(func(move(*this)))>;=20
};

Which you guessed right, is a future without the synchronous access. The=20
question then:

   1. Is std::continuator is a wrapper around std::future? or
   2. Can std::future be rewritten to inherit or be composed from a=20
   std::continuator
  =20
And of course I then would like to get from the bigger to the smaller class=
=20
via:

template< class Type >
continuator async_cast(future<Type> fut) noexcept;
 template< class Type >
shared_continuator async_cast(shared_future<Type> fut) noexcept;

Does this make the scenario more clear?



On Wednesday, February 5, 2014 5:08:46 PM UTC+1, Agust=C3=ADn K-ballo Berg=
=C3=A9=20
wrote:
>
> On Monday, February 3, 2014 7:12:45 AM UTC-6, lcid...@gmail.com wrote:
>>
>> While implementing parts of N3784 with libc++, I encountered the=20
>> situation, that I wanted to return a "future" from a function, that can =
NOT=20
>> be accessed synchronously.
>>
>>
> Could you elaborate on those situations? What does it mean that a "future=
"=20
> cannot be accessed synchronously? What would happen if I did access that=
=20
> "future" synchronously?
> =20
>
>> I now thought about adding the following two functions:
>>
>> template< class Type >
>> continuator async_cast(std::future<Type> fut) noexcept;
>>  template< class Type >
>> shared_continuator async_cast(std::shared_future<Type> fut) noexcept;
>>
>> The difference for the continuator is, that it does not have a blocking =
get and only works asynchronously.
>>
>>
> Would you care to provide more detail about this "continuator"? I assume=
=20
> it doesn't have `wait` either, but that's just me guessing...
> =20
>
>> The question is whether this is a common scenario. And if such a continu=
ator is added, whether it would make sense to composite the future classes =
out of a continuator.
>>
>>
> You hardly explained which scenario is that. Why don't you start by=20
> explaining your scenario, the problems a regular future would present, an=
d=20
> how your "continuation" fix them first?=20
>

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

------=_Part_507_29093188.1391620731787
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sorry, Agustin, I'll try to be more precise.<div>The situa=
tion is that I have a download task. Lets say I have a function <font face=
=3D"verdana, sans-serif">std::future downloadFile(string url)</font>. Now I=
 want to declare this for multiple platforms. I there make a distinction be=
tween desktop platforms (e.g. Linux) and server and embedded ones (e.g. Ems=
cripten). The distinction is that code on the latter ones is only run in ce=
rtain threads, which can not be (indirectly) controlled. As such, one threa=
d is processing one program and I thus do not want any blocking operation i=
n this thread. Then of course (to prevent novices from shooting themselves =
in the leg), I do not want the blocking aspects of <font face=3D"verdana, s=
ans-serif">std::future</font>. So this leads me to have the following decla=
ration:</div><div><br></div><div><font face=3D"verdana, sans-serif">#ifdef =
PLATFORM_USES_MULTIPLE_THREADS</font></div><div><font face=3D"verdana, sans=
-serif">std::future downloadFile(string url);</font></div><div><font face=
=3D"verdana, sans-serif">#else</font></div><div><font face=3D"verdana, sans=
-serif">std::continuator downloadFile(string url);</font></div><div><font f=
ace=3D"verdana, sans-serif">#endif</font></div><div><br></div><div>Now the =
interface of the continuator would look something like* (* hugely simplifie=
d):</div><div><br></div><font face=3D"verdana, sans-serif">template&lt; cla=
ss T &gt;</font><div><font face=3D"verdana, sans-serif">class&nbsp;continua=
tor&nbsp;{</font></div><div><span style=3D"line-height: 14.300000190734863p=
x;">&nbsp;&nbsp;</span><font face=3D"verdana, sans-serif">std::shared_conti=
nuator&lt;T&gt; share();<br>&nbsp; T get();<br>&nbsp; bool valid() const;<b=
r>&nbsp; bool is_ready() const;<br>&nbsp; template&lt;typename F&gt;<br>&nb=
sp; auto then(F&amp;&amp; func) -&gt; future&lt;decltype(func(*this))&gt;; =
<br>&nbsp; template&lt;typename F&gt; <br>&nbsp; auto then(executor &amp;ex=
, F&amp;&amp; func) -&gt; future&lt;decltype(func(move(*this)))&gt;; <br>&n=
bsp; template&lt;typename F&gt; <br>&nbsp; auto then(launch policy, F&amp;&=
amp; func) -&gt; future&lt;decltype(func(move(*this)))&gt;; </font></div><d=
iv><font face=3D"verdana, sans-serif">};</font></div><div><font face=3D"ver=
dana, sans-serif"><br></font></div><div>Which you guessed right, is a futur=
e without the synchronous access. The question then:</div><div><ol><li><spa=
n style=3D"line-height: normal;">Is </span><font face=3D"verdana, sans-seri=
f" style=3D"line-height: normal;">std::continuator</font><span style=3D"lin=
e-height: normal;">&nbsp;</span>is a wrapper around <font face=3D"verdana, =
sans-serif">std::future? or</font></li><li>Can <font face=3D"verdana, sans-=
serif">std::future</font>&nbsp;be rewritten to inherit or be composed from =
a <font face=3D"verdana, sans-serif">std::continuator</font><br></li></ol><=
div>And of course I then would like to get from the bigger to the smaller c=
lass via:</div><div><br></div><div><pre style=3D"width: 744px;"><div style=
=3D"color: rgb(0, 0, 0); font-size: 12px; line-height: 16.799999237060547px=
;"><font face=3D"verdana, sans-serif">template&lt; class Type &gt;</font></=
div><div style=3D"color: rgb(0, 0, 0); font-size: 12px; line-height: 16.799=
999237060547px;"><font face=3D"verdana, sans-serif">continuator async_cast(=
future&lt;Type&gt; fut) noexcept;</font></div><div style=3D"color: rgb(0, 0=
, 0); font-size: 12px; line-height: 16.799999237060547px;"><font face=3D"ve=
rdana, sans-serif"> </font></div><div style=3D"color: rgb(0, 0, 0); font-si=
ze: 12px; line-height: 16.799999237060547px;"><font face=3D"verdana, sans-s=
erif">template&lt; class Type &gt;</font></div><div style=3D"color: rgb(0, =
0, 0); font-size: 12px; line-height: 16.799999237060547px;"><font face=3D"v=
erdana, sans-serif">shared_continuator async_cast(shared_future&lt;<wbr>Typ=
e&gt; fut) noexcept;</font></div><div style=3D"color: rgb(0, 0, 0); font-si=
ze: 12px; line-height: 16.799999237060547px;"><font face=3D"verdana, sans-s=
erif"><br></font></div><font face=3D"arial, sans-serif">Does this make the =
scenario more clear?</font></pre></div><div><br><br>On Wednesday, February =
5, 2014 5:08:46 PM UTC+1, Agust=C3=ADn K-ballo Berg=C3=A9 wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Monday, February 3, 2=
014 7:12:45 AM UTC-6, <a>lcid...@gmail.com</a> wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">While implementing parts of N3784 with l=
ibc++, I encountered the situation, that I wanted to return a "future" from=
 a function, that can NOT be accessed synchronously.<div><br></div></div></=
blockquote><div><br>Could you elaborate on those situations? What does it m=
ean that a "future" cannot be accessed synchronously? What would happen if =
I did access that "future" synchronously?<br>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>I now thought about=
 adding the following two functions:</div><div><br></div><div><pre style=3D=
"font-size:12px;line-height:16.799999237060547px;width:744px;color:rgb(0,0,=
0)"><div style=3D"font-family:Consolas,'Liberation Mono',Courier,monospace"=
>template&lt; class Type &gt;</div><div style=3D"font-family:Consolas,'Libe=
ration Mono',Courier,monospace">continuator async_cast(std::future&lt;Type&=
gt; fut) noexcept;</div><div style=3D"font-family:Consolas,'Liberation Mono=
',Courier,monospace"> </div><div style=3D"font-family:Consolas,'Liberation =
Mono',Courier,monospace">template&lt; class Type &gt;</div><div style=3D"fo=
nt-family:Consolas,'Liberation Mono',Courier,monospace">shared_continuator =
async_cast(std::shared_future&lt;<wbr>Type&gt; fut) noexcept;</div><div><fo=
nt face=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sa=
ns-serif">The difference for the continuator is, that it does not have a bl=
ocking </font><font face=3D"verdana, sans-serif">get and only works asynchr=
onously</font><font face=3D"arial, sans-serif">.</font></div></pre></div></=
div></blockquote><div><br>Would you care to provide more detail about this =
"continuator"? I assume it doesn't have `wait` either, but that's just me g=
uessing...<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div><pre style=3D"font-size:12px;line-height:16.799999237060547px=
;width:744px;color:rgb(0,0,0)"><div><font face=3D"arial, sans-serif">The qu=
estion is whether this is a common scenario. And if such a continuator is a=
dded, whether it would make sense to composite the future classes out of a =
continuator.</font></div></pre></div></div></blockquote><div><br>You hardly=
 explained which scenario is that. Why don't you start by explaining your s=
cenario, the problems a regular future would present, and how your "continu=
ation" fix them first? <br></div></div></blockquote></div></div></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_507_29093188.1391620731787--

.

------=_Part_2595_11856430.1391629801908
Content-Type: text/plain; charset=UTF-8

I also see a need for something like this. Even on desktop platforms, there
are still plenty of asynchronous API functions which do not need spawning
new threads (at least not explicitly by the user). For example, there is
plenty of this in Win32 (requiring the use of the WaitForSingleObject() and
friends).

So I agree that there is a problem to solve but I'm not sure I understand
the 'continuator' class that you propose. Personnally, I was more thinking
about "configurable futures", that is new future/promise methods to specify
custom 'wait' functions.

promise<int> p;
p.set_wait_functions(customWait, customWaitUntil);
.....


On Wednesday, February 5, 2014 12:18:51 PM UTC-5, lcid...@gmail.com wrote:

> Which you guessed right, is a future without the synchronous access.
>

What do you mean by "without the synchronous access"? Do you mean that
calling get() will not wait? How is it possible?



> template< class Type >
> continuator async_cast(future<Type> fut) noexcept;
>  template< class Type >
> shared_continuator async_cast(shared_future<Type> fut) noexcept;
>
> Does this make the scenario more clear?
>
>
>

Hum not for me at least. When you have a future, you usually are waiting
for soemthing in another thread (unless the future has a ready or deferred
state). I have a hard time understanding async_cast; how can it transform a
future (something from another thread) into a continuator (something from
current thread)? Please provide examples and/or a reference implementation.

--

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

------=_Part_2595_11856430.1391629801908
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I also see a need for something like this. Even on de=
sktop platforms, there are still plenty of asynchronous API functions which=
 do not need spawning new threads (at least not explicitly by the user). Fo=
r example, there is plenty of this in Win32 (requiring the use of the WaitF=
orSingleObject() and friends).</div><div>&nbsp;</div><div>So I agree that t=
here is a problem to solve but I'm not sure I understand the 'continuator' =
class that you propose. Personnally, I was more thinking about "configurabl=
e futures", that is new future/promise methods to specify custom 'wait' fun=
ctions.</div><div>&nbsp;</div><div><font face=3D"courier new,monospace">pro=
mise&lt;int&gt; p;</font></div><div><font face=3D"courier new,monospace">p.=
set_wait_functions(customWait, customWaitUntil);</font></div><div><font fac=
e=3D"courier new,monospace">....</font></div><div>&nbsp;</div><div><br>On W=
ednesday, February 5, 2014 12:18:51 PM UTC-5, lcid...@gmail.com wrote:</div=
><blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-=
left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: =
solid;" class=3D"gmail_quote"><div dir=3D"ltr"><div>Which you guessed right=
, is a future without the synchronous access.</div></div></blockquote><div>=
&nbsp;</div><div>What do you mean by "without the synchronous access"? Do y=
ou mean that calling get() will not wait? How is it possible?</div><div>&nb=
sp;</div><div>&nbsp;</div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; p=
adding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width:=
 1px; border-left-style: solid;" class=3D"gmail_quote"><div dir=3D"ltr"><di=
v><div><pre style=3D"width: 744px;"><div style=3D"color: rgb(0, 0, 0); line=
-height: 16.79px; font-size: 12px;"><font face=3D"verdana, sans-serif">temp=
late&lt; class Type &gt;</font></div><div style=3D"color: rgb(0, 0, 0); lin=
e-height: 16.79px; font-size: 12px;"><font face=3D"verdana, sans-serif">con=
tinuator async_cast(future&lt;Type&gt; fut) noexcept;</font></div><div styl=
e=3D"color: rgb(0, 0, 0); line-height: 16.79px; font-size: 12px;"><font fac=
e=3D"verdana, sans-serif"> </font></div><div style=3D"color: rgb(0, 0, 0); =
line-height: 16.79px; font-size: 12px;"><font face=3D"verdana, sans-serif">=
template&lt; class Type &gt;</font></div><div style=3D"color: rgb(0, 0, 0);=
 line-height: 16.79px; font-size: 12px;"><font face=3D"verdana, sans-serif"=
>shared_continuator async_cast(shared_future&lt;Type&gt; fut) noexcept;</fo=
nt></div><div style=3D"color: rgb(0, 0, 0); line-height: 16.79px; font-size=
: 12px;"><font face=3D"verdana, sans-serif"><br></font></div><font face=3D"=
arial, sans-serif">Does this make the scenario more clear?</font></pre></di=
v><div>&nbsp;</div></div></div></blockquote><div>&nbsp;</div><div>Hum not f=
or me at least.&nbsp;When you have a future, you usually&nbsp;are waiting f=
or soemthing in another thread (unless&nbsp;the future&nbsp;has a ready or =
deferred state).&nbsp;I have a&nbsp;hard time understanding&nbsp;async_cast=
; how can it transform&nbsp;a future (something from another thread) into a=
 continuator (something from current thread)? Please provide examples and/o=
r a reference implementation.</div></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2595_11856430.1391629801908--

.

------=_Part_909_15092519.1391631501052
Content-Type: text/plain; charset=UTF-8



On Wednesday, February 5, 2014 8:50:01 PM UTC+1, Alex B wrote:
>
> I also see a need for something like this. Even on desktop platforms,
> there are still plenty of asynchronous API functions which do not need
> spawning new threads (at least not explicitly by the user). For example,
> there is plenty of this in Win32 (requiring the use of the
> WaitForSingleObject() and friends).
>
Do not mistake threading with synchronization. You can have threading
without ever synchronizing. My proposal is to have a class that handles
similar to the extensions proposed in N3784, but without any
synchronization. A future/promise is from its interface not necessarily
bound to threads. Even the current implementations only have an implicit
dependency on synchronization primitives.


> So I agree that there is a problem to solve but I'm not sure I understand
> the 'continuator' class that you propose. Personnally, I was more thinking
> about "configurable futures", that is new future/promise methods to specify
> custom 'wait' functions.
>
> promise<int> p;
> p.set_wait_functions(customWait, customWaitUntil);
> ....
>
What you are proposing is a change in the synchronization. That is totally
different from what I am proposing.


> Do you mean that calling get() will not wait?
>
 Exactly.


> How is it possible?
>
Well, if you think about it, future::get only does a synchronization,
should the value not be ready yet. So instead of that the continuator::get
would throw an exception if the value is not ready yet. Perhaps it would be
better to rename continuation::get to continuation::pop.


>
>> Does this make the scenario more clear?
>>
>>
>>
>
> Hum not for me at least. When you have a future, you usually are waiting
> for soemthing in another thread (unless the future has a ready or deferred
> state).
>
That is correct. The unusual (but still possible) state with C++11 is, that
you already have fulfilled the promise and thus the future is ready.
With N3784 as soon as the promise is fulfilled (no matter from what
thread), the continuation may be called.


>  I have a hard time understanding async_cast; how can it transform a
> future (something from another thread) into a continuator (something from
> current thread)? Please provide examples and/or a reference implementation.
>
Yes, sorry starting with async_cast was a bad call. Since continuator is a
(feature) subset of future (+ N3784), one may want to limit the retrieval
of the value, of a future at some point, to only be accessible via
asynchronous functions (AKA continuations).

And example would be:

std::continuator
someAbstractAlwaysAsyncInterfaceFunction() {
  auto download = downloadFileViaFuture( "http://myurl.com" ); //returns a
std::future
  // do some other processing here
  return async_cast( download ); //returns a std::continuator - no sync
access to future is possible anymore
}



--

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

------=_Part_909_15092519.1391631501052
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, February 5, 2014 8:50:01 PM UTC+1, A=
lex B wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>I also see a need for something like this. Even on desktop platforms, t=
here are still plenty of asynchronous API functions which do not need spawn=
ing new threads (at least not explicitly by the user). For example, there i=
s plenty of this in Win32 (requiring the use of the WaitForSingleObject() a=
nd friends).</div></div></blockquote><div>Do not mistake threading with syn=
chronization. You can have threading without ever synchronizing. My proposa=
l is to have a class that handles similar to the extensions proposed in N37=
84, but without any synchronization. A future/promise is from its interface=
 not necessarily bound to threads. Even the current implementations only ha=
ve an implicit dependency on synchronization primitives.</div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></=
div><div>So I agree that there is a problem to solve but I'm not sure I und=
erstand the 'continuator' class that you propose. Personnally, I was more t=
hinking about "configurable futures", that is new future/promise methods to=
 specify custom 'wait' functions.</div><div>&nbsp;</div><div><font face=3D"=
courier new,monospace">promise&lt;int&gt; p;</font></div><div><font face=3D=
"courier new,monospace">p.set_wait_functions(<wbr>customWait, customWaitUnt=
il);</font></div><div><font face=3D"courier new,monospace">....</font></div=
></div></blockquote><div>What you are proposing is a change in the synchron=
ization. That is totally different from what I am proposing.</div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>&n=
bsp;</div><div>Do you mean that calling get() will not wait?</div></div></b=
lockquote><div>&nbsp;Exactly.</div><div>&nbsp;</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div>How is it possible?<br></div></=
div></blockquote><div>Well, if you think about it, future::get only does a =
synchronization, should the value not be ready yet. So instead of that the =
continuator::get would throw an exception if the value is not ready yet. Pe=
rhaps it would be better to rename continuation::get to continuation::pop.<=
/div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;padding-l=
eft:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-lef=
t-style:solid" class=3D"gmail_quote"><div dir=3D"ltr"><div><div><pre style=
=3D"width:744px"><div style=3D"color:rgb(0,0,0);line-height:16.79px;font-si=
ze:12px"><font face=3D"verdana, sans-serif"><br></font></div><font face=3D"=
arial, sans-serif">Does this make the scenario more clear?</font></pre></di=
v><div>&nbsp;</div></div></div></blockquote><div>&nbsp;</div><div>Hum not f=
or me at least.&nbsp;When you have a future, you usually&nbsp;are waiting f=
or soemthing in another thread (unless&nbsp;the future&nbsp;has a ready or =
deferred state).</div></div></blockquote><div>That is correct. The unusual =
(but still possible) state with C++11 is, that you already have fulfilled t=
he promise and thus the future is ready.</div><div>With N3784 as soon as th=
e promise is fulfilled (no matter from what thread), the continuation may b=
e called.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr"><div>&nbsp;I have a&nbsp;hard time understanding&nbsp;as=
ync_cast; how can it transform&nbsp;a future (something from another thread=
) into a continuator (something from current thread)? Please provide exampl=
es and/or a reference implementation.</div></div></blockquote><div>Yes, sor=
ry starting with async_cast was a bad call. Since continuator is a (feature=
) subset of future (+ N3784), one may want to limit the retrieval of the va=
lue, of a future at some point, to only be accessible via asynchronous func=
tions (AKA continuations).</div><div><br></div><div>And example would be:</=
div><div><br></div><div><font face=3D"verdana, sans-serif">std::continuator=
</font></div><div><font face=3D"verdana, sans-serif">someAbstractAlwaysAsyn=
cInterfaceFunction() {</font></div><div><font face=3D"verdana, sans-serif">=
&nbsp; auto download =3D downloadFileViaFuture( "http://myurl.com" ); //ret=
urns a std::future</font></div><div><font face=3D"verdana, sans-serif">&nbs=
p; // do some other processing here</font></div><div><font face=3D"verdana,=
 sans-serif">&nbsp; return async_cast( download ); //returns a std::continu=
ator - no sync access to future is possible anymore</font></div><div><font =
face=3D"verdana, sans-serif">}</font></div><div><br></div><div>&nbsp;</div>=
</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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_909_15092519.1391631501052--

.

--001a11c3c7f0460fec04f1aef21d
Content-Type: text/plain; charset=ISO-8859-1

Ah, I see that I completely misunderstood what you wanted to achieve. Sorry
I went a bit off-topic.

As I (now) understand it, you can 'almost' replace your continuator class
by a deferred future.

template <class F>
auto async_cast(F f)
{
    return async(launch::deferred, [f = move(f)]
    {
        if (f.wait_for(chrono::seconds(0)) == future_status::timeout)
            throw something;
        return f.get();
    });
}

What will not work is that you can only call get() once on the resulting
future... and I guess that your purpose is to call get() several times
(until it does not throw).



On Wed, Feb 5, 2014 at 3:18 PM, <lcidfire@gmail.com> wrote:

>
>
> On Wednesday, February 5, 2014 8:50:01 PM UTC+1, Alex B wrote:
>>
>> I also see a need for something like this. Even on desktop platforms,
>> there are still plenty of asynchronous API functions which do not need
>> spawning new threads (at least not explicitly by the user). For example,
>> there is plenty of this in Win32 (requiring the use of the
>> WaitForSingleObject() and friends).
>>
> Do not mistake threading with synchronization. You can have threading
> without ever synchronizing. My proposal is to have a class that handles
> similar to the extensions proposed in N3784, but without any
> synchronization. A future/promise is from its interface not necessarily
> bound to threads. Even the current implementations only have an implicit
> dependency on synchronization primitives.
>
>
>> So I agree that there is a problem to solve but I'm not sure I understand
>> the 'continuator' class that you propose. Personnally, I was more thinking
>> about "configurable futures", that is new future/promise methods to specify
>> custom 'wait' functions.
>>
>> promise<int> p;
>> p.set_wait_functions(customWait, customWaitUntil);
>> ....
>>
> What you are proposing is a change in the synchronization. That is totally
> different from what I am proposing.
>
>
>> Do you mean that calling get() will not wait?
>>
>  Exactly.
>
>
>> How is it possible?
>>
> Well, if you think about it, future::get only does a synchronization,
> should the value not be ready yet. So instead of that the continuator::get
> would throw an exception if the value is not ready yet. Perhaps it would be
> better to rename continuation::get to continuation::pop.
>
>
>>
>>> Does this make the scenario more clear?
>>>
>>>
>>>
>>
>> Hum not for me at least. When you have a future, you usually are waiting
>> for soemthing in another thread (unless the future has a ready or deferred
>> state).
>>
> That is correct. The unusual (but still possible) state with C++11 is,
> that you already have fulfilled the promise and thus the future is ready.
> With N3784 as soon as the promise is fulfilled (no matter from what
> thread), the continuation may be called.
>
>
>>  I have a hard time understanding async_cast; how can it transform a
>> future (something from another thread) into a continuator (something from
>> current thread)? Please provide examples and/or a reference implementation.
>>
> Yes, sorry starting with async_cast was a bad call. Since continuator is a
> (feature) subset of future (+ N3784), one may want to limit the retrieval
> of the value, of a future at some point, to only be accessible via
> asynchronous functions (AKA continuations).
>
> And example would be:
>
> std::continuator
> someAbstractAlwaysAsyncInterfaceFunction() {
>   auto download = downloadFileViaFuture( "http://myurl.com" ); //returns
> a std::future
>   // do some other processing here
>   return async_cast( download ); //returns a std::continuator - no sync
> access to future is possible anymore
> }
>
>
>
> --
>
> ---
> 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/4jU4f2bJE6I/unsubscribe
> .
> 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/.
>

--

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

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

<div dir=3D"ltr">Ah, I see that I completely misunderstood what you wanted =
to achieve. Sorry I went a bit off-topic.<div><br></div><div>As I (now) und=
erstand it, you can &#39;almost&#39; replace your continuator class by a de=
ferred future.</div>
<div><br></div><div><font face=3D"courier new, monospace">template &lt;clas=
s F&gt;</font></div><div><font face=3D"courier new, monospace">auto async_c=
ast(F f)<br></font></div><div><font face=3D"courier new, monospace">{</font=
></div>
<div><font face=3D"courier new, monospace">=A0 =A0 return async(launch::def=
erred, [f =3D move(f)]</font></div><div><font face=3D"courier new, monospac=
e">=A0 =A0 {</font></div><div><font face=3D"courier new, monospace">=A0 =A0=
 =A0 =A0 if (f.wait_for(chrono::seconds(0)) =3D=3D future_status::timeout)<=
/font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 =A0 =A0 throw so=
mething;</font></div><div><font face=3D"courier new, monospace">=A0 =A0 =A0=
 =A0 return f.get();</font></div><div><font face=3D"courier new, monospace"=
>=A0 =A0 });</font></div><div>
<font face=3D"courier new, monospace">}</font></div><div><br></div><div>Wha=
t will not work is that you can only call get() once on the resulting futur=
e... and I guess that your purpose is to call get() several times (until it=
 does not throw).</div>
<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Feb 5, 2014 at 3:18 PM,  <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:lcidfire@gmail.com" target=3D"_blank">lcidfire@gmail.com</a>&gt;</spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><br><br>O=
n Wednesday, February 5, 2014 8:50:01 PM UTC+1, Alex B wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">
<div dir=3D"ltr"><div>I also see a need for something like this. Even on de=
sktop platforms, there are still plenty of asynchronous API functions which=
 do not need spawning new threads (at least not explicitly by the user). Fo=
r example, there is plenty of this in Win32 (requiring the use of the WaitF=
orSingleObject() and friends).</div>
</div></blockquote></div><div>Do not mistake threading with synchronization=
.. You can have threading without ever synchronizing. My proposal is to have=
 a class that handles similar to the extensions proposed in N3784, but with=
out any synchronization. A future/promise is from its interface not necessa=
rily bound to threads. Even the current implementations only have an implic=
it dependency on synchronization primitives.</div>
<div class=3D"im"><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div><br></div><div>So I agree that there is a problem to so=
lve but I&#39;m not sure I understand the &#39;continuator&#39; class that =
you propose. Personnally, I was more thinking about &quot;configurable futu=
res&quot;, that is new future/promise methods to specify custom &#39;wait&#=
39; functions.</div>
<div>=A0</div><div><font face=3D"courier new,monospace">promise&lt;int&gt; =
p;</font></div><div><font face=3D"courier new,monospace">p.set_wait_functio=
ns(<u></u>customWait, customWaitUntil);</font></div><div><font face=3D"cour=
ier new,monospace">....</font></div>
</div></blockquote></div><div>What you are proposing is a change in the syn=
chronization. That is totally different from what I am proposing.</div><div=
 class=3D"im"><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>=A0</div><div>Do you mean that calling get() will not=
 wait?</div></div></blockquote></div><div>=A0Exactly.</div><div>=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>How is it possible?<br></div></div></blockquote><div>=
Well, if you think about it, future::get only does a synchronization, shoul=
d the value not be ready yet. So instead of that the continuator::get would=
 throw an exception if the value is not ready yet. Perhaps it would be bett=
er to rename continuation::get to continuation::pop.</div>
<div class=3D"im"><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;padd=
ing-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;borde=
r-left-style:solid" class=3D"gmail_quote">
<div dir=3D"ltr"><div><div><pre style=3D"width:744px"><div style=3D"line-he=
ight:16.79px;font-size:12px"><font face=3D"verdana, sans-serif"><br></font>=
</div><font face=3D"arial, sans-serif">Does this make the scenario more cle=
ar?</font></pre>
</div><div>=A0</div></div></div></blockquote><div>=A0</div><div>Hum not for=
 me at least.=A0When you have a future, you usually=A0are waiting for soemt=
hing in another thread (unless=A0the future=A0has a ready or deferred state=
).</div>
</div></blockquote></div><div>That is correct. The unusual (but still possi=
ble) state with C++11 is, that you already have fulfilled the promise and t=
hus the future is ready.</div><div>With N3784 as soon as the promise is ful=
filled (no matter from what thread), the continuation may be called.</div>
<div class=3D"im"><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div>=A0I have a=A0hard time understanding=A0async_cast; how =
can it transform=A0a future (something from another thread) into a continua=
tor (something from current thread)? Please provide examples and/or a refer=
ence implementation.</div>
</div></blockquote></div><div>Yes, sorry starting with async_cast was a bad=
 call. Since continuator is a (feature) subset of future (+ N3784), one may=
 want to limit the retrieval of the value, of a future at some point, to on=
ly be accessible via asynchronous functions (AKA continuations).</div>
<div><br></div><div>And example would be:</div><div><br></div><div><font fa=
ce=3D"verdana, sans-serif">std::continuator</font></div><div><font face=3D"=
verdana, sans-serif">someAbstractAlwaysAsyncInterfaceFunction() {</font></d=
iv>
<div><font face=3D"verdana, sans-serif">=A0 auto download =3D downloadFileV=
iaFuture( &quot;<a href=3D"http://myurl.com" target=3D"_blank">http://myurl=
..com</a>&quot; ); //returns a std::future</font></div><div><font face=3D"ve=
rdana, sans-serif">=A0 // do some other processing here</font></div>
<div><font face=3D"verdana, sans-serif">=A0 return async_cast( download ); =
//returns a std::continuator - no sync access to future is possible anymore=
</font></div><div><font face=3D"verdana, sans-serif">}</font></div><div><br=
></div>
<div>=A0</div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<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/4jU4f2bJE6I/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/4jU4f2bJE6I=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3c7f0460fec04f1aef21d--

.

This is a multi-part message in MIME format.
--------------060405020109040604000703
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 05/02/14 18:18, lcidfire@gmail.com a =E9crit :
> Sorry, Agustin, I'll try to be more precise.
> The situation is that I have a download task. Lets say I have a=20
> function std::future downloadFile(string url). Now I want to declare=20
> this for multiple platforms. I there make a distinction between=20
> desktop platforms (e.g. Linux) and server and embedded ones (e.g.=20
> Emscripten). The distinction is that code on the latter ones is only=20
> run in certain threads, which can not be (indirectly) controlled. As=20
> such, one thread is processing one program and I thus do not want any=20
> blocking operation in this thread. Then of course (to prevent novices=20
> from shooting themselves in the leg), I do not want the blocking=20
> aspects of std::future. So this leads me to have the following=20
> declaration:
>
> #ifdef PLATFORM_USES_MULTIPLE_THREADS
> std::future downloadFile(string url);
> #else
> std::continuator downloadFile(string url);
> #endif
>
> Now the interface of the continuator would look something like* (*=20
> hugely simplified):
>
> template< class T >
> class continuator {
> std::shared_continuator<T> share();
>   T get();
>   bool valid() const;
>   bool is_ready() const;
>   template<typename F>
>   auto then(F&& func) -> future<decltype(func(*this))>;
>   template<typename F>
>   auto then(executor &ex, F&& func) ->=20
> future<decltype(func(move(*this)))>;
>   template<typename F>
>   auto then(launch policy, F&& func) ->=20
> future<decltype(func(move(*this)))>;
> };
>
Why do you need that then() returns a future and not a continuator? IMO,=20
continuator should be independent from future. The continuation of a=20
continuator should be a continuator.
> Which you guessed right, is a future without the synchronous access.=20
> The question then:
>
>  1. Is std::continuatoris a wrapper around std::future? or
>
This is an implementation detail.
>
>  1. Can std::future be rewritten to inherit or be composed from a
>     std::continuator
>
Inheritance would add too much constraints in the continuator class.=20
Composition again is an implementation detail.
> And of course I then would like to get from the bigger to the smaller=20
> class via:
>
> template< class Type >
> continuator async_cast(future<Type> fut) noexcept;
> template< class Type >
> shared_continuator async_cast(shared_future<Type> fut) noexcept;
> Does this make the scenario more clear?
>
What about using instead of continuator the ongoing proposal for=20
std::expected? future could provide functions that convert from/to=20
continuator(expected)?

explicit future(expected<T>);
or future<T> make_ready_future(expected<T>);
expected<T> expected();

std::expected is something like you continuator class but .then()=20
returns an expected not a future.

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

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

<html>
  <head>
    <meta content=3D"text/html; charset=3DISO-8859-1"
      http-equiv=3D"Content-Type">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 05/02/14 18:18, <a class=3D"moz-txt-l=
ink-abbreviated" href=3D"mailto:lcidfire@gmail.com">lcidfire@gmail.com</a> =
a
      &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
      cite=3D"mid:c005ccec-6044-4c08-93ae-7e774c9421ca@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">Sorry, Agustin, I'll try to be more precise.
        <div>The situation is that I have a download task. Lets say I
          have a function <font face=3D"verdana, sans-serif">std::future
            downloadFile(string url)</font>. Now I want to declare this
          for multiple platforms. I there make a distinction between
          desktop platforms (e.g. Linux) and server and embedded ones
          (e.g. Emscripten). The distinction is that code on the latter
          ones is only run in certain threads, which can not be
          (indirectly) controlled. As such, one thread is processing one
          program and I thus do not want any blocking operation in this
          thread. Then of course (to prevent novices from shooting
          themselves in the leg), I do not want the blocking aspects of
          <font face=3D"verdana, sans-serif">std::future</font>. So this
          leads me to have the following declaration:</div>
        <div><br>
        </div>
        <div><font face=3D"verdana, sans-serif">#ifdef
            PLATFORM_USES_MULTIPLE_THREADS</font></div>
        <div><font face=3D"verdana, sans-serif">std::future
            downloadFile(string url);</font></div>
        <div><font face=3D"verdana, sans-serif">#else</font></div>
        <div><font face=3D"verdana, sans-serif">std::continuator
            downloadFile(string url);</font></div>
        <div><font face=3D"verdana, sans-serif">#endif</font></div>
        <div><br>
        </div>
        <div>Now the interface of the continuator would look something
          like* (* hugely simplified):</div>
        <div><br>
        </div>
        <font face=3D"verdana, sans-serif">template&lt; class T &gt;</font>
        <div><font face=3D"verdana, sans-serif">class&nbsp;continuator&nbsp=
;{</font></div>
        <div><span style=3D"line-height: 14.300000190734863px;">&nbsp;&nbsp=
;</span><font
            face=3D"verdana, sans-serif">std::shared_continuator&lt;T&gt;
            share();<br>
            &nbsp; T get();<br>
            &nbsp; bool valid() const;<br>
            &nbsp; bool is_ready() const;<br>
            &nbsp; template&lt;typename F&gt;<br>
            &nbsp; auto then(F&amp;&amp; func) -&gt;
            future&lt;decltype(func(*this))&gt;; <br>
            &nbsp; template&lt;typename F&gt; <br>
            &nbsp; auto then(executor &amp;ex, F&amp;&amp; func) -&gt;
            future&lt;decltype(func(move(*this)))&gt;; <br>
            &nbsp; template&lt;typename F&gt; <br>
            &nbsp; auto then(launch policy, F&amp;&amp; func) -&gt;
            future&lt;decltype(func(move(*this)))&gt;; </font></div>
        <div><font face=3D"verdana, sans-serif">};</font></div>
        <div><font face=3D"verdana, sans-serif"><br>
          </font></div>
      </div>
    </blockquote>
    <font face=3D"verdana, sans-serif">Why do you need that then() returns
      a future and not a continuator? IMO, continuator should be
      independent from future. The continuation</font> of a continuator
    should be a continuator.<br>
    <blockquote
      cite=3D"mid:c005ccec-6044-4c08-93ae-7e774c9421ca@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>Which you guessed right, is a future without the
          synchronous access. The question then:</div>
        <div>
          <ol>
            <li><span style=3D"line-height: normal;">Is </span><font
                style=3D"line-height: normal;" face=3D"verdana, sans-serif"=
>std::continuator</font><span
                style=3D"line-height: normal;">&nbsp;</span>is a wrapper ar=
ound
              <font face=3D"verdana, sans-serif">std::future? or</font></li=
>
          </ol>
        </div>
      </div>
    </blockquote>
    <font face=3D"verdana, sans-serif">This is an implementation detail.</f=
ont><br>
    <blockquote
      cite=3D"mid:c005ccec-6044-4c08-93ae-7e774c9421ca@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <ol>
            <li>Can <font face=3D"verdana, sans-serif">std::future</font>&n=
bsp;be
              rewritten to inherit or be composed from a <font
                face=3D"verdana, sans-serif">std::continuator</font><br>
            </li>
          </ol>
        </div>
      </div>
    </blockquote>
    Inheritance would add too much constraints in the continuator class.
    Composition again is an implementation detail.<br>
    <blockquote
      cite=3D"mid:c005ccec-6044-4c08-93ae-7e774c9421ca@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>And of course I then would like to get from the bigger to
            the smaller class via:</div>
          <div><br>
          </div>
          <div>
            <pre style=3D"width: 744px;"><div style=3D"color: rgb(0, 0, 0);=
 font-size: 12px; line-height: 16.799999237060547px;"><font face=3D"verdana=
, sans-serif">template&lt; class Type &gt;</font></div><div style=3D"color:=
 rgb(0, 0, 0); font-size: 12px; line-height: 16.799999237060547px;"><font f=
ace=3D"verdana, sans-serif">continuator async_cast(future&lt;Type&gt; fut) =
noexcept;</font></div><div style=3D"color: rgb(0, 0, 0); font-size: 12px; l=
ine-height: 16.799999237060547px;"><font face=3D"verdana, sans-serif"> </fo=
nt></div><div style=3D"color: rgb(0, 0, 0); font-size: 12px; line-height: 1=
6.799999237060547px;"><font face=3D"verdana, sans-serif">template&lt; class=
 Type &gt;</font></div><div style=3D"color: rgb(0, 0, 0); font-size: 12px; =
line-height: 16.799999237060547px;"><font face=3D"verdana, sans-serif">shar=
ed_continuator async_cast(shared_future&lt;<wbr>Type&gt; fut) noexcept;</fo=
nt></div><div style=3D"color: rgb(0, 0, 0); font-size: 12px; line-height: 1=
6.799999237060547px;"><font face=3D"verdana, sans-
serif">
</font></div><font face=3D"arial, sans-serif">Does this make the scenario m=
ore clear?</font></pre>
          </div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    What about using instead of continuator the ongoing proposal for
    std::expected? future could provide functions that convert from/to
    continuator(expected)?<br>
    <br>
    explicit future(expected&lt;T&gt;);<br>
    or future&lt;T&gt; make_ready_future(expected&lt;T&gt;);<br>
    expected&lt;T&gt; expected();<br>
    <br>
    std::expected is something like you continuator class but .then()
    returns an expected not a future.<br>
    <br>
    Vicente<br>
  </body>
</html>

<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------060405020109040604000703--

.

On 02/03/2014 02:12 PM, lcidfire@gmail.com wrote:
> While implementing parts of N3784 with libc++, I encountered the
> situation, that I wanted to return a "future" from a function, that can
> NOT be accessed synchronously.

Have you looked at N3747 "A Universal Model for Asynchronous
Operations"?

   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3747.pdf

--

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

.

------=_Part_890_31567240.1391797375852
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thursday, February 6, 2014 6:40:05 AM UTC+1, Vicente J. Botet Escriba=20
wrote:
>
>  Le 05/02/14 18:18, lcid...@gmail.com <javascript:> a =C3=A9crit :
> =20
> template< class T >
> class continuator {
>   std::shared_continuator<T> share();
>   T get();
>   bool valid() const;
>   bool is_ready() const;
>   template<typename F>
>   auto then(F&& func) -> future<decltype(func(*this))>;=20
>   template<typename F>=20
>   auto then(executor &ex, F&& func) ->=20
> future<decltype(func(move(*this)))>;=20
>   template<typename F>=20
>   auto then(launch policy, F&& func) ->=20
> future<decltype(func(move(*this)))>;=20
> };
>
>   Why do you need that then() returns a future and not a continuator?=20
> IMO, continuator should be independent from future. The continuation of a=
=20
> continuator should be a continuator.
>
You are right. My fault. Another try:

template< class T >
class continuator {
  std::shared_continuator<T> share();
  T get();
  bool valid() const;
  bool is_ready() const;
  template<typename F>
  auto then(F&& func) -> continuator<decltype(func(*this))>;=20
  template<typename F>=20
  auto then(executor &ex, F&& func) -> continuator<decltype(func(move(*
this)))>;=20
  template<typename F>=20
  auto then(launch policy, F&& func) -> continuator<decltype(func(move(*
this)))>;
};

Keep in mind that NONE of these functions block!
=20

> =20
>   And of course I then would like to get from the bigger to the smaller=
=20
> class via:
>
>  template< class Type >
> continuator async_cast(future<Type> fut) noexcept;
>  template< class Type >
> shared_continuator async_cast(shared_future<Type> fut) noexcept;
> Does this make the scenario more clear?
>
> =20
>   What about using instead of continuator the ongoing proposal for=20
> std::expected? future could provide functions that convert from/to=20
> continuator(expected)?
>
> explicit future(expected<T>);
> or future<T> make_ready_future(expected<T>);
> expected<T> expected();
>
> std::expected is something like you continuator class but .then() returns=
=20
> an expected not a future.
>
Please explain why you think std::expected "is something like [...]=20
continuator". As far as I read the expected spec they are nothing alike,=20
since expected always (already) has a result.

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

------=_Part_890_31567240.1391797375852
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 6, 2014 6:40:05 AM UTC+1, Vicente J.=
 Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 05/02/14 18:18, <a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"tiDbJO_UZGYJ" onmousedown=3D"this.href=3D'javascript:';=
return true;" onclick=3D"this.href=3D'javascript:';return true;">lcid...@gm=
ail.com</a> a
      =C3=A9crit&nbsp;:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr"><div><span style=3D"font-family: verdana, sans-serif=
;">template&lt; class T &gt;</span><br></div><div><font face=3D"verdana, sa=
ns-serif">class&nbsp;continuator&nbsp;{</font></div>
        <div><span style=3D"line-height:14.300000190734863px">&nbsp;&nbsp;<=
/span><font face=3D"verdana, sans-serif">std::shared_continuator&lt;T&gt;
            share();<br>
            &nbsp; T get();<br>
            &nbsp; bool valid() const;<br>
            &nbsp; bool is_ready() const;<br>
            &nbsp; template&lt;typename F&gt;<br>
            &nbsp; auto then(F&amp;&amp; func) -&gt;
            future&lt;decltype(func(*this))&gt;; <br>
            &nbsp; template&lt;typename F&gt; <br>
            &nbsp; auto then(executor &amp;ex, F&amp;&amp; func) -&gt;
            future&lt;decltype(func(move(*<wbr>this)))&gt;; <br>
            &nbsp; template&lt;typename F&gt; <br>
            &nbsp; auto then(launch policy, F&amp;&amp; func) -&gt;
            future&lt;decltype(func(move(*<wbr>this)))&gt;; </font></div>
        <div><font face=3D"verdana, sans-serif">};</font></div>
        <div><font face=3D"verdana, sans-serif"><br>
          </font></div>
      </div>
    </blockquote>
    <font face=3D"verdana, sans-serif">Why do you need that then() returns
      a future and not a continuator? IMO, continuator should be
      independent from future. The continuation</font> of a continuator
    should be a continuator.<br></div></blockquote><font face=3D"arial, san=
s-serif">You are right. My fault. Another try:</font><div><br></div><div><s=
pan style=3D"font-family: verdana, sans-serif;">template&lt; class T &gt;</=
span><br><span style=3D"font-family: verdana, sans-serif;">class&nbsp;conti=
nuator&nbsp;{</span><br><span style=3D"line-height: 14.300000190734863px;">=
&nbsp;&nbsp;</span><font face=3D"verdana, sans-serif">std::shared_continuat=
or&lt;T&gt; share();</font><br><span style=3D"font-family: verdana, sans-se=
rif;">&nbsp; T get();</span><br><span style=3D"font-family: verdana, sans-s=
erif;">&nbsp; bool valid() const;</span><br><span style=3D"font-family: ver=
dana, sans-serif;">&nbsp; bool is_ready() const;</span><br><span style=3D"f=
ont-family: verdana, sans-serif;">&nbsp; template&lt;typename F&gt;</span><=
br><span style=3D"font-family: verdana, sans-serif;">&nbsp; auto then(F&amp=
;&amp; func) -&gt;&nbsp;</span><span style=3D"font-family: verdana, sans-se=
rif;">continuator</span><span style=3D"font-family: verdana, sans-serif;">&=
lt;decltype(func(*this))&gt;;</span><span style=3D"font-family: verdana, sa=
ns-serif;">&nbsp;</span><br><span style=3D"font-family: verdana, sans-serif=
;">&nbsp; template&lt;typename F&gt;</span><span style=3D"font-family: verd=
ana, sans-serif;">&nbsp;</span><br><span style=3D"font-family: verdana, san=
s-serif;">&nbsp; auto then(executor &amp;ex, F&amp;&amp; func) -&gt;&nbsp;<=
/span><span style=3D"font-family: verdana, sans-serif;">continuator</span><=
span style=3D"font-family: verdana, sans-serif;">&lt;decltype(func(move(*</=
span><wbr style=3D"font-family: verdana, sans-serif;"><span style=3D"font-f=
amily: verdana, sans-serif;">this)))&gt;;</span><span style=3D"font-family:=
 verdana, sans-serif;">&nbsp;</span><br><span style=3D"font-family: verdana=
, sans-serif;">&nbsp; template&lt;typename F&gt;</span><span style=3D"font-=
family: verdana, sans-serif;">&nbsp;</span><br><span style=3D"font-family: =
verdana, sans-serif;">&nbsp; auto then(launch policy, F&amp;&amp; func) -&g=
t;&nbsp;</span><span style=3D"font-family: verdana, sans-serif;">continuato=
r</span><span style=3D"font-family: verdana, sans-serif;">&lt;decltype(func=
(move(*</span><wbr style=3D"font-family: verdana, sans-serif;"><span style=
=3D"font-family: verdana, sans-serif;">this)))&gt;;</span><br><div dir=3D"l=
tr"><div><font face=3D"verdana, sans-serif">};</font></div><div><font face=
=3D"verdana, sans-serif"><br></font></div><div><font face=3D"verdana, sans-=
serif">Keep in mind that NONE of these functions block!</font></div></div><=
/div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div bgc=
olor=3D"#FFFFFF" text=3D"#000000">
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div><br></div></div></blockquote>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>
          <div>And of course I then would like to get from the bigger to
            the smaller class via:</div>
          <div><br>
          </div>
          <div>
            <pre style=3D"width:744px"><div style=3D"color:rgb(0,0,0);font-=
size:12px;line-height:16.799999237060547px"><font face=3D"verdana, sans-ser=
if">template&lt; class Type &gt;</font></div><div style=3D"color:rgb(0,0,0)=
;font-size:12px;line-height:16.799999237060547px"><font face=3D"verdana, sa=
ns-serif">continuator async_cast(future&lt;Type&gt; fut) noexcept;</font></=
div><div style=3D"color:rgb(0,0,0);font-size:12px;line-height:16.7999992370=
60547px"><font face=3D"verdana, sans-serif"> </font></div><div style=3D"col=
or:rgb(0,0,0);font-size:12px;line-height:16.799999237060547px"><font face=
=3D"verdana, sans-serif">template&lt; class Type &gt;</font></div><div styl=
e=3D"color:rgb(0,0,0);font-size:12px;line-height:16.799999237060547px"><fon=
t face=3D"verdana, sans-serif">shared_continuator async_cast(shared_future&=
lt;Type&gt; fut) noexcept;</font></div><div style=3D"color:rgb(0,0,0);font-=
size:12px;line-height:16.799999237060547px"><font face=3D"verdana, sans-
serif">
</font></div><font face=3D"arial, sans-serif">Does this make the scenario m=
ore clear?</font></pre>
          </div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    What about using instead of continuator the ongoing proposal for
    std::expected? future could provide functions that convert from/to
    continuator(expected)?<br>
    <br>
    explicit future(expected&lt;T&gt;);<br>
    or future&lt;T&gt; make_ready_future(expected&lt;T&gt;)<wbr>;<br>
    expected&lt;T&gt; expected();<br>
    <br>
    std::expected is something like you continuator class but .then()
    returns an expected not a future.<br></div></blockquote><div>Please exp=
lain why you think std::expected "is something like [...] continuator". As =
far as I read the expected spec they are nothing alike, since expected alwa=
ys (already) has a result.</div></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_890_31567240.1391797375852--

.

------=_Part_947_8733437.1391797952095
Content-Type: text/plain; charset=UTF-8


On Wednesday, February 5, 2014 9:53:18 PM UTC+1, Alex B wrote:
>
> Ah, I see that I completely misunderstood what you wanted to achieve.
> Sorry I went a bit off-topic.
>
> As I (now) understand it, you can 'almost' replace your continuator class
> by a deferred future.
>
> template <class F>
> auto async_cast(F f)
> {
>     return async(launch::deferred, [f = move(f)]
>     {
>         if (f.wait_for(chrono::seconds(0)) == future_status::timeout)
>             throw something;
>         return f.get();
>     });
> }
>
> What will not work is that you can only call get() once on the resulting
> future... and I guess that your purpose is to call get() several times
> (until it does not throw).
>
continuation::get is only necessary for the following:

auto download = downloadFile( "http://whatever.org" ); //returns a
std::continuation<std::vector<char>>
download.then( []( continuation cont ) {
  auto result = cont.get(); // that is the way N3784 does it for futures.
} );

The second use case of get() is, that you might want to poll via is_ready.
And only call get, when is_ready is true of course (thus omitting the
exception).

OT:
We could however divide N3784 into 2 classes:

   - continuation
   has then functions but no is_ready
   - poll
   has only is_ready and get



--

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

------=_Part_947_8733437.1391797952095
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Wednesday, February 5, 2014 9:53:18 PM UTC+1, Alex =
B wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Ah, I=
 see that I completely misunderstood what you wanted to achieve. Sorry I we=
nt a bit off-topic.<div><br></div><div>As I (now) understand it, you can 'a=
lmost' replace your continuator class by a deferred future.</div>
<div><br></div><div><font face=3D"courier new, monospace">template &lt;clas=
s F&gt;</font></div><div><font face=3D"courier new, monospace">auto async_c=
ast(F f)<br></font></div><div><font face=3D"courier new, monospace">{</font=
></div>
<div><font face=3D"courier new, monospace">&nbsp; &nbsp; return async(launc=
h::deferred, [f =3D move(f)]</font></div><div><font face=3D"courier new, mo=
nospace">&nbsp; &nbsp; {</font></div><div><font face=3D"courier new, monosp=
ace">&nbsp; &nbsp; &nbsp; &nbsp; if (f.wait_for(chrono::seconds(0)<wbr>) =
=3D=3D future_status::timeout)</font></div>
<div><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; throw something;</font></div><div><font face=3D"courier new, mono=
space">&nbsp; &nbsp; &nbsp; &nbsp; return f.get();</font></div><div><font f=
ace=3D"courier new, monospace">&nbsp; &nbsp; });</font></div><div>
<font face=3D"courier new, monospace">}</font></div><div><br></div><div>Wha=
t will not work is that you can only call get() once on the resulting futur=
e... and I guess that your purpose is to call get() several times (until it=
 does not throw).</div></div></blockquote><div><font face=3D"verdana, sans-=
serif">continuation::get</font> is only necessary for the following:</div><=
div><br></div><div><font face=3D"verdana, sans-serif">auto download =3D dow=
nloadFile( "http://whatever.org" ); //returns a std::continuation&lt;std::v=
ector&lt;char&gt;&gt;</font></div><div><font face=3D"verdana, sans-serif">d=
ownload.then( []( continuation cont ) {</font></div><div><font face=3D"verd=
ana, sans-serif">&nbsp; auto result =3D cont.<font color=3D"#ff0000">get</f=
ont>(); // that is the way N3784 does it for futures.</font></div><div><fon=
t face=3D"verdana, sans-serif">} );</font></div><div><br></div><div><font f=
ace=3D"arial, sans-serif">The second use case of </font><font face=3D"verda=
na, sans-serif">get()</font><font face=3D"arial, sans-serif"> is, that you =
might want to poll via </font><font face=3D"verdana, sans-serif">is_ready</=
font><font face=3D"arial, sans-serif">. And only call get, when is_ready is=
 true of course (thus omitting the exception).</font></div><div><font face=
=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, sans-seri=
f">OT:</font></div><div><font face=3D"arial, sans-serif">We could however d=
ivide N3784 into 2 classes:</font></div><div><ul><li><span style=3D"font-fa=
mily: arial, sans-serif;">continuation<br>has </span><font face=3D"verdana,=
 sans-serif">then</font><span style=3D"font-family: arial, sans-serif;"> fu=
nctions but no </span><font face=3D"verdana, sans-serif">is_ready</font></l=
i><li><span style=3D"font-family: arial, sans-serif;">poll<br></span>has on=
ly <font face=3D"verdana, sans-serif">is_ready</font> and <font face=3D"ver=
dana, sans-serif">get</font></li></ul></div><div>&nbsp;</div></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_947_8733437.1391797952095--

.

------=_Part_897_7106680.1391798054486
Content-Type: text/plain; charset=UTF-8

On Thursday, February 6, 2014 10:33:02 AM UTC+1, Bjorn Reese wrote:
>
> Have you looked at N3747 "A Universal Model for Asynchronous
> Operations"?
>
>    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3747.pdf
>
Yes and I still largely agree with the Herb crowd, that continuation is
better.

--

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

------=_Part_897_7106680.1391798054486
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 6, 2014 10:33:02 AM UTC+1, Bjorn Ree=
se wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Have you looked at N3=
747 "A Universal Model for Asynchronous
<br>Operations"?
<br>
<br>&nbsp; &nbsp;<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2013/n3747.pdf" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fd=
ocs%2Fpapers%2F2013%2Fn3747.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNGwLIfBVv=
AdoLB6EaF8owGjp6gF_Q';return true;" onclick=3D"this.href=3D'http://www.goog=
le.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2F=
papers%2F2013%2Fn3747.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNGwLIfBVvAdoLB6=
EaF8owGjp6gF_Q';return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/d=
ocs/papers/2013/<wbr>n3747.pdf</a>
<br></blockquote><div>Yes and I still largely agree with the Herb crowd, th=
at continuation is better.&nbsp;</div></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_897_7106680.1391798054486--

.

This is a multi-part message in MIME format.
--------------050801040700070905010408
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 07/02/14 19:22, lcidfire@gmail.com a =C3=A9crit :
> On Thursday, February 6, 2014 6:40:05 AM UTC+1, Vicente J. Botet=20
> Escriba wrote:
>
>     Le 05/02/14 18:18, lcid...@gmail.com <javascript:> a =C3=A9crit :
>
>
>
>>
>     What about using instead of continuator the ongoing proposal for
>     std::expected? future could provide functions that convert from/to
>     continuator(expected)?
>
>     explicit future(expected<T>);
>     or future<T> make_ready_future(expected<T>);
>     expected<T> expected();
>
>     std::expected is something like you continuator class but .then()
>     returns an expected not a future.
>
> Please explain why you think std::expected "is something like [...]=20
> continuator". As far as I read the expected spec they are nothing=20
> alike, since expected always (already) has a result.
>
You wrote
 >Keep in mind that NONE of these functions block!

So what is the diferences and how continuator will take its value?


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

--------------050801040700070905010408
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 07/02/14 19:22, <a class=3D"moz-txt-l=
ink-abbreviated" href=3D"mailto:lcidfire@gmail.com">lcidfire@gmail.com</a> =
a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:09bfa653-02d8-4829-9916-22a310ef4d9e@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr">On Thursday, February 6, 2014 6:40:05 AM UTC+1,
        Vicente J. Botet Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div>Le 05/02/14 18:18, <a moz-do-not-send=3D"true"
                href=3D"javascript:" target=3D"_blank"
                gdf-obfuscated-mailto=3D"tiDbJO_UZGYJ"
                onmousedown=3D"this.href=3D'javascript:';return true;"
                onclick=3D"this.href=3D'javascript:';return true;">lcid...@=
gmail.com</a>
              a =C3=A9crit=C2=A0:<br>
            </div>
          </div>
        </blockquote>
        <br>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div><br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr"><br>
              </div>
            </blockquote>
            What about using instead of continuator the ongoing proposal
            for std::expected? future could provide functions that
            convert from/to continuator(expected)?<br>
            <br>
            explicit future(expected&lt;T&gt;);<br>
            or future&lt;T&gt; make_ready_future(expected&lt;T&gt;)<wbr>;<b=
r>
            expected&lt;T&gt; expected();<br>
            <br>
            std::expected is something like you continuator class but
            .then() returns an expected not a future.<br>
          </div>
        </blockquote>
        <div>Please explain why you think std::expected "is something
          like [...] continuator". As far as I read the expected spec
          they are nothing alike, since expected always (already) has a
          result.</div>
      </div>
      <br>
    </blockquote>
    You wrote <br>
    &gt;<font face=3D"verdana, sans-serif">Keep in mind that NONE of these
      functions block!</font><br>
    <br>
    So what is the diferences and how continuator will take its value? <br>
    <br>
    <br>
    Vicente<br>
    <br>
  </body>
</html>

<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------050801040700070905010408--

.

------=_Part_113_20489956.1391959607723
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Saturday, February 8, 2014 12:17:36 AM UTC+1, Vicente J. Botet Escriba=
=20
wrote:
>
>  Le 07/02/14 19:22, lcid...@gmail.com <javascript:> a =C3=A9crit :
> =20
> On Thursday, February 6, 2014 6:40:05 AM UTC+1, Vicente J. Botet Escriba=
=20
> wrote:=20
>>
>>  Le 05/02/14 18:18, lcid...@gmail.com a =C3=A9crit :=20
>>
> What about using instead of continuator the ongoing proposal for=20
>> std::expected? future could provide functions that convert from/to=20
>> continuator(expected)?
>>
>> explicit future(expected<T>);
>> or future<T> make_ready_future(expected<T>);
>> expected<T> expected();
>>
>> std::expected is something like you continuator class but .then() return=
s=20
>> an expected not a future.
>> =20
> Please explain why you think std::expected "is something like [...]=20
> continuator". As far as I read the expected spec they are nothing alike,=
=20
> since expected always (already) has a result.
> =20
>  You wrote=20
> >Keep in mind that NONE of these functions block!
>
> So what is the diferences and how continuator will take its value?=20
>
You are claiming, that std::expected is similar to my continuator proposal=
=20
and as such it is on you to give a compelling reasoning, why this should be=
=20
the case.
I highly doubt, that is the case since std::expected is always ready, while=
=20
continuation will only sometimes be ready immediately after instantiation.

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

------=_Part_113_20489956.1391959607723
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Saturday, February 8, 2014 12:17:36 AM UTC+1, Vicen=
te J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div>Le 07/02/14 19:22, <a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"_sq_jwT3WWsJ" onmousedown=3D"this.href=3D'javascript:';=
return true;" onclick=3D"this.href=3D'javascript:';return true;">lcid...@gm=
ail.com</a> a
      =C3=A9crit&nbsp;:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">On Thursday, February 6, 2014 6:40:05 AM UTC+1,
        Vicente J. Botet Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div>Le 05/02/14 18:18, <a>lcid...@gmail.com</a>
              a =C3=A9crit&nbsp;:&nbsp;</div></div></blockquote></div></blo=
ckquote></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v bgcolor=3D"#FFFFFF" text=3D"#000000"><blockquote type=3D"cite"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor=3D"#FFFFFF" t=
ext=3D"#000000">
            What about using instead of continuator the ongoing proposal
            for std::expected? future could provide functions that
            convert from/to continuator(expected)?<br>
            <br>
            explicit future(expected&lt;T&gt;);<br>
            or future&lt;T&gt; make_ready_future(expected&lt;T&gt;)<wbr>;<b=
r>
            expected&lt;T&gt; expected();<br>
            <br>
            std::expected is something like you continuator class but
            .then() returns an expected not a future.<br>
          </div>
        </blockquote>
        <div>Please explain why you think std::expected "is something
          like [...] continuator". As far as I read the expected spec
          they are nothing alike, since expected always (already) has a
          result.</div>
      </div>
      <br>
    </blockquote>
    You wrote <br>
    &gt;<font face=3D"verdana, sans-serif">Keep in mind that NONE of these
      functions block!</font><br>
    <br>
    So what is the diferences and how continuator will take its value? <br>=
</div></blockquote><div>You are claiming, that std::expected is similar to =
my continuator proposal and as such it is on you to give a compelling reaso=
ning, why this should be the case.</div><div>I highly doubt, that is the ca=
se since std::expected is always ready, while continuation will only someti=
mes be ready immediately after instantiation.</div></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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_113_20489956.1391959607723--

.

This is a multi-part message in MIME format.
--------------090806060301060900090002
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 09/02/14 16:26, lcidfire@gmail.com a =C3=A9crit :
>
> On Saturday, February 8, 2014 12:17:36 AM UTC+1, Vicente J. Botet=20
> Escriba wrote:
>
>     Le 07/02/14 19:22, lcid...@gmail.com <javascript:> a =C3=A9crit :
>>     On Thursday, February 6, 2014 6:40:05 AM UTC+1, Vicente J. Botet
>>     Escriba wrote:
>>
>>         Le 05/02/14 18:18, lcid...@gmail.com a =C3=A9crit :
>>
>>         What about using instead of continuator the ongoing proposal
>>         for std::expected? future could provide functions that
>>         convert from/to continuator(expected)?
>>
>>         explicit future(expected<T>);
>>         or future<T> make_ready_future(expected<T>);
>>         expected<T> expected();
>>
>>         std::expected is something like you continuator class but
>>         .then() returns an expected not a future.
>>
>>     Please explain why you think std::expected "is something like
>>     [...] continuator". As far as I read the expected spec they are
>>     nothing alike, since expected always (already) has a result.
>>
>     You wrote
>     >Keep in mind that NONE of these functions block!
>
>     So what is the diferences and how continuator will take its value?
>
> You are claiming, that std::expected is similar to my continuator=20
> proposal and as such it is on you to give a compelling reasoning, why=20
> this should be the case.
> I highly doubt, that is the case since std::expected is always ready,=20
> while continuation will only sometimes be ready immediately after=20
> instantiation.
>
Humm, sorry I shouldn't claim anything as I don't know what a=20
continuator is for you. I should instead just request you to describe=20
what a continuator is.
So please, could you explain what a continuator is?

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

--------------090806060301060900090002
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <div class=3D"moz-cite-prefix">Le 09/02/14 16:26, <a class=3D"moz-txt-l=
ink-abbreviated" href=3D"mailto:lcidfire@gmail.com">lcidfire@gmail.com</a> =
a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:98feec23-b78a-4e0f-9f23-ff39061f712b@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        On Saturday, February 8, 2014 12:17:36 AM UTC+1, Vicente J.
        Botet Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <div>Le 07/02/14 19:22, <a moz-do-not-send=3D"true"
                href=3D"javascript:" target=3D"_blank"
                gdf-obfuscated-mailto=3D"_sq_jwT3WWsJ"
                onmousedown=3D"this.href=3D'javascript:';return true;"
                onclick=3D"this.href=3D'javascript:';return true;">lcid...@=
gmail.com</a>
              a =C3=A9crit=C2=A0:<br>
            </div>
            <blockquote type=3D"cite">
              <div dir=3D"ltr">On Thursday, February 6, 2014 6:40:05 AM
                UTC+1, Vicente J. Botet Escriba wrote:
                <blockquote class=3D"gmail_quote"
                  style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                  solid;padding-left:1ex">
                  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
                    <div>Le 05/02/14 18:18, <a moz-do-not-send=3D"true">lci=
d...@gmail.com</a>
                      a =C3=A9crit=C2=A0:=C2=A0</div>
                  </div>
                </blockquote>
              </div>
            </blockquote>
          </div>
        </blockquote>
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
          <div bgcolor=3D"#FFFFFF" text=3D"#000000">
            <blockquote type=3D"cite">
              <div dir=3D"ltr">
                <blockquote class=3D"gmail_quote"
                  style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc
                  solid;padding-left:1ex">
                  <div bgcolor=3D"#FFFFFF" text=3D"#000000"> What about
                    using instead of continuator the ongoing proposal
                    for std::expected? future could provide functions
                    that convert from/to continuator(expected)?<br>
                    <br>
                    explicit future(expected&lt;T&gt;);<br>
                    or future&lt;T&gt;
                    make_ready_future(expected&lt;T&gt;)<wbr>;<br>
                    expected&lt;T&gt; expected();<br>
                    <br>
                    std::expected is something like you continuator
                    class but .then() returns an expected not a future.<br>
                  </div>
                </blockquote>
                <div>Please explain why you think std::expected "is
                  something like [...] continuator". As far as I read
                  the expected spec they are nothing alike, since
                  expected always (already) has a result.</div>
              </div>
              <br>
            </blockquote>
            You wrote <br>
            &gt;<font face=3D"verdana, sans-serif">Keep in mind that NONE
              of these functions block!</font><br>
            <br>
            So what is the diferences and how continuator will take its
            value? <br>
          </div>
        </blockquote>
        <div>You are claiming, that std::expected is similar to my
          continuator proposal and as such it is on you to give a
          compelling reasoning, why this should be the case.</div>
        <div>I highly doubt, that is the case since std::expected is
          always ready, while continuation will only sometimes be ready
          immediately after instantiation.</div>
      </div>
      <br>
    </blockquote>
    Humm, sorry I shouldn't claim anything as I don't know what a
    continuator is for you. I should instead just request you to
    describe what a continuator is.<br>
    So please, could you explain what a continuator is?<br>
    <br>
    Best,<br>
    Vicente<br>
    <br>
  </body>
</html>

<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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--------------090806060301060900090002--

.

On 02/05/2014 09:18 PM, lcidfire@gmail.com wrote:

> Well, if you think about it, future::get only does a synchronization,
> should the value not be ready yet. So instead of that the
> continuator::get would throw an exception if the value is not ready yet.

Another way to do this is to add a future::try_get().

--

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

.