Topic: [RFC] A Joint Thought on Resumable Functions &
Author: TONGARI J <tongari95@gmail.com>
Date: Mon, 21 Sep 2015 23:41:28 +0800
Raw View
--089e0111b5e2f6bc76052043b652
Content-Type: text/plain; charset=UTF-8
Hi,
Please find the draft here:
https://gist.github.com/jamboree/a2b3fe32eeb8c21e820c
It's my thoughts on the possible joint of Resumable Functions(N4402) and
Resumable Expressions(N4453).
To be clear, I'm not gonna write a complete proposal, I just hope the
authors and people behind the aforementioned proposals could take the idea
into account.
Any feedback is welcome.
--
---
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/.
--089e0111b5e2f6bc76052043b652
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<div><br></div><div>Please find the draft here:</div><d=
iv><a href=3D"https://gist.github.com/jamboree/a2b3fe32eeb8c21e820c">https:=
//gist.github.com/jamboree/a2b3fe32eeb8c21e820c</a><br></div><div><br></div=
>It's my thoughts on the possible joint of Resumable Functions(N4402) a=
nd Resumable Expressions(N4453).<div><br></div><div>To be clear, I'm no=
t gonna write a complete proposal, I just hope the authors and people behin=
d the aforementioned proposals could take the idea into account.</div><br>A=
ny feedback is welcome.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0111b5e2f6bc76052043b652--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Mon, 21 Sep 2015 21:13:44 +0200
Raw View
--089e013c646e1b5475052046ae7e
Content-Type: text/plain; charset=UTF-8
On 21 September 2015 at 17:41, TONGARI J <tongari95@gmail.com> wrote:
> Hi,
>
> Please find the draft here:
> https://gist.github.com/jamboree/a2b3fe32eeb8c21e820c
>
> It's my thoughts on the possible joint of Resumable Functions(N4402) and
> Resumable Expressions(N4453).
>
> To be clear, I'm not gonna write a complete proposal, I just hope the
> authors and people behind the aforementioned proposals could take the idea
> into account.
>
> Any feedback is welcome.
>
This is an interesting read.
Some comments:
1. Following this idea, a function marked async (whatever that mean) is not
forced to actually use concurrency in any way,
in the same way that a const member function is not forced to access
any class members,
it's just a contract that it could and might at some point do so.
Is my understanding correct?
2. The async on left or right of the function signature is a bit confusing
when reading the examples then the description.
For example:
async T do_something(...); // A
T do_something(...) async; // B
async T do_something(...) async; // C
My initial understanding is that in A only the returned object is async,
while in B it's the function that is async, which mark it's execution
context.
Am I understanding this correctly? The text around this example gave me
doubts, in particular the overload remarks.
In any way, could you clarify what is the meaning of aving async on both
sides as in C?
3. I do not see any mention on the "monad" type (or maybe async or
synchronization return type?) extension possibilites like in N4402.
Are you suggesting (without describing it) that these types would still
need to be implemented following a similar extension mechanism
as in N4402?
The first comparison is a bit confusing on this point, because if:
std::future<T> do_something(...); // N4402
is equivalent to
async T do_something(...);
then you are suggesting that T's "synchronization" type should be an
implementation detail? Or did you mean that async T is really async
future<T> ?
4. What about executors? How would a user specify an executor instead of
the default implementation on calling asynchronously any function?
I think it would be useful to have this document to be read, at least, by
the concurrency TS people.
--
---
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/.
--089e013c646e1b5475052046ae7e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 21 September 2015 at 17:41, TONGARI J <span dir=3D"ltr"><<a href=
=3D"mailto:tongari95@gmail.com" target=3D"_blank">tongari95@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex"><div dir=3D"ltr">Hi,<div><br></div><di=
v>Please find the draft here:</div><div><a href=3D"https://gist.github.com/=
jamboree/a2b3fe32eeb8c21e820c" target=3D"_blank">https://gist.github.com/ja=
mboree/a2b3fe32eeb8c21e820c</a><br></div><div><br></div>It's my thought=
s on the possible joint of Resumable Functions(N4402) and Resumable Express=
ions(N4453).<div><br></div><div>To be clear, I'm not gonna write a comp=
lete proposal, I just hope the authors and people behind the aforementioned=
proposals could take the idea into account.</div><br>Any feedback is welco=
me.</div></blockquote><div><br></div><div>This is an interesting read.</div=
><div>Some comments:</div><div><br></div><div>1. Following this idea, a fun=
ction marked async (whatever that mean) is not forced to actually use concu=
rrency in any way,</div><div>=C2=A0 =C2=A0 in the same way that a const mem=
ber function is not forced to access any class members,</div><div>=C2=A0 =
=C2=A0 it's just a contract that it could and might at some point do so=
..</div><div>=C2=A0 =C2=A0 Is my understanding correct?</div><div><br></div>=
<div>=C2=A02. The async on left or right of the function signature is a bit=
confusing when reading the examples then the description.</div><div>=C2=A0=
=C2=A0 =C2=A0For example:</div><div>=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0a=
sync T do_something(...); // A</div><div>=C2=A0 =C2=A0=C2=A0</div><div>=C2=
=A0 =C2=A0 =C2=A0T do_something(...) async; =C2=A0// B</div><div><br></div>=
<div>=C2=A0 =C2=A0 =C2=A0=C2=A0async T do_something(...) async; // C</div><=
div><br></div><div><br></div><div>My initial understanding is that in A onl=
y the returned object is async, while in B it's the function that is as=
ync, =C2=A0which mark it's execution context.</div><div>Am I understand=
ing this correctly? The text around this example gave me doubts, in particu=
lar the overload remarks.</div><div>In any way, could you clarify what is t=
he meaning of aving async on both sides as in C?</div><div><br></div><div>=
=C2=A03. I do not see any mention on the "monad" type (or maybe a=
sync or synchronization return type?) extension possibilites like in N4402.=
</div><div>Are you suggesting (without describing it) that these types woul=
d still need to be implemented following a similar extension mechanism</div=
><div>as in N4402?</div><div>The first comparison is a bit confusing on thi=
s point, because if:</div><div><br></div><div>=C2=A0 =C2=A0 std::future<=
T> do_something(...); // N4402</div><div><br></div><div>is equivalent to=
=C2=A0</div><div><br></div><div>=C2=A0 =C2=A0 async T do_something(...);</d=
iv><div><br></div><div>then you are suggesting that T's "synchroni=
zation" type should be an implementation detail? Or did you mean that =
async T is really async future<T> ?</div><div><br></div><div>4. What =
about executors? How would a user specify an executor instead of the defaul=
t implementation on calling asynchronously any function?</div><div><br></di=
v><div>I think it would be useful to have this document to be read, at leas=
t, by the concurrency TS people.</div><div><br></div><div><br></div></div><=
br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e013c646e1b5475052046ae7e--
.
Author: TONGARI J <tongari95@gmail.com>
Date: Tue, 22 Sep 2015 10:17:27 +0800
Raw View
--001a1140f92874784805204c9932
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2015-09-22 3:13 GMT+08:00 Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com>:
>
>
> On 21 September 2015 at 17:41, TONGARI J <tongari95@gmail.com> wrote:
>
>> Hi,
>>
>> Please find the draft here:
>> https://gist.github.com/jamboree/a2b3fe32eeb8c21e820c
>>
>> It's my thoughts on the possible joint of Resumable Functions(N4402) and
>> Resumable Expressions(N4453).
>>
>> To be clear, I'm not gonna write a complete proposal, I just hope the
>> authors and people behind the aforementioned proposals could take the id=
ea
>> into account.
>>
>> Any feedback is welcome.
>>
>
> This is an interesting read.
> Some comments:
>
> 1. Following this idea, a function marked async (whatever that mean) is
> not forced to actually use concurrency in any way,
> in the same way that a const member function is not forced to access
> any class members,
> it's just a contract that it could and might at some point do so.
> Is my understanding correct?
>
It's more like constexpr, a function marked constexpr is not necessary to
be evaluated in constant context.
> 2. The async on left or right of the function signature is a bit
> confusing when reading the examples then the description.
> For example:
>
> async T do_something(...); // A
>
> T do_something(...) async; // B
>
> async T do_something(...) async; // C
>
>
> My initial understanding is that in A only the returned object is async,
> while in B it's the function that is async, which mark it's execution
> context.
> Am I understanding this correctly? The text around this example gave me
> doubts, in particular the overload remarks.
> In any way, could you clarify what is the meaning of aving async on both
> sides as in C?
>
There's no B & C in my example. Note that left-async is part of the
function prototype, but right-async is not.
The left-async is the like "resumable" in N4453. I doesn't represent a
async result of T, it just indicates that the function can be called in
async manner (i.e. resumable).
There's no execution context tied to an async function, the execution
context is always "provided" by the non-async function -- w/o right-async,
a normal context is provided, w/ right-async, the async context will be
used to evaluate the async functions & variables.
When right-async is used, the function return type must conform to
Coroutine Return Object, that is, it must have the corresponding Coroutine
Promise defined.
> 3. I do not see any mention on the "monad" type (or maybe async or
> synchronization return type?) extension possibilites like in N4402.
> Are you suggesting (without describing it) that these types would still
> need to be implemented following a similar extension mechanism
> as in N4402?
>
Yep, in the very front of the "Design" section, I do mention that this
draft is based on Coroutine Promise and Awaitable concepts from N4402.
The first comparison is a bit confusing on this point, because if:
>
> std::future<T> do_something(...); // N4402
>
> is equivalent to
>
> async T do_something(...);
>
> then you are suggesting that T's "synchronization" type should be an
> implementation detail? Or did you mean that async T is really async
> future<T> ?
>
Not at all, `async T do_something(...)` is not really a concrete function,
it's more like a function template that only exists in compile-time.
When `async T do_something(...)` is evaluated with async-context, the code
will be "merged" into the parent frame, no intermediate "monad" thing will
be generated.
The only exception is for recursion, when there's recursion, the compiler
will indeed make some future-like thing behind the scene.
> 4. What about executors? How would a user specify an executor instead of
> the default implementation on calling asynchronously any function?
>
Typically we just call something like `await post(executor)` in N4402 to
schedule the coroutine on executor.
I think it would be useful to have this document to be read, at least, by
> the concurrency TS people.
>
Thanks for your feedback!
--=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/.
--001a1140f92874784805204c9932
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2015=
-09-22 3:13 GMT+08:00 Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr"><<a hr=
ef=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com</a>>=
</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote"><div><div class=3D"h5">On 21 September 201=
5 at 17:41, TONGARI J <span dir=3D"ltr"><<a href=3D"mailto:tongari95@gma=
il.com" target=3D"_blank">tongari95@gmail.com</a>></span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"ltr">Hi,<div><br></div><div>Please find the draft =
here:</div><div><a href=3D"https://gist.github.com/jamboree/a2b3fe32eeb8c21=
e820c" target=3D"_blank">https://gist.github.com/jamboree/a2b3fe32eeb8c21e8=
20c</a><br></div><div><br></div>It's my thoughts on the possible joint =
of Resumable Functions(N4402) and Resumable Expressions(N4453).<div><br></d=
iv><div>To be clear, I'm not gonna write a complete proposal, I just ho=
pe the authors and people behind the aforementioned proposals could take th=
e idea into account.</div><br>Any feedback is welcome.</div></blockquote><d=
iv><br></div></div></div><div>This is an interesting read.</div><div>Some c=
omments:</div><div><br></div><div>1. Following this idea, a function marked=
async (whatever that mean) is not forced to actually use concurrency in an=
y way,</div><div>=C2=A0 =C2=A0 in the same way that a const member function=
is not forced to access any class members,</div><div>=C2=A0 =C2=A0 it'=
s just a contract that it could and might at some point do so.</div><div>=
=C2=A0 =C2=A0 Is my understanding correct?</div></div></div></div></blockqu=
ote><div><br></div><div>It's more like constexpr, a =C2=A0function mark=
ed constexpr is not necessary to be evaluated in constant context.</div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div></div><div>=C2=A02. The async on left or ri=
ght of the function signature is a bit confusing when reading the examples =
then the description.</div><div>=C2=A0 =C2=A0 =C2=A0For example:</div><div>=
=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0async T do_something(...); // A</div><=
div>=C2=A0 =C2=A0=C2=A0</div><div>=C2=A0 =C2=A0 =C2=A0T do_something(...) a=
sync; =C2=A0// B</div><div><br></div><div>=C2=A0 =C2=A0 =C2=A0=C2=A0async T=
do_something(...) async; // C</div><div><br></div><div><br></div><div>My i=
nitial understanding is that in A only the returned object is async, while =
in B it's the function that is async, =C2=A0which mark it's executi=
on context.</div><div>Am I understanding this correctly? The text around th=
is example gave me doubts, in particular the overload remarks.</div><div>In=
any way, could you clarify what is the meaning of aving async on both side=
s as in C?</div></div></div></div></blockquote><div><br></div><div>There=
9;s no B & C in my example. Note that left-async is part of the functio=
n prototype, but right-async is not.</div><div>The left-async is the like &=
quot;resumable" in N4453. I doesn't represent a async result of T,=
it just indicates that the function can be called in async manner (i.e. re=
sumable).</div><div>There's no execution context tied to an async funct=
ion, the execution context is always "provided" by the non-async =
function -- w/o right-async, a normal context is provided, w/=C2=A0right-as=
ync, the async context will be used to evaluate the=C2=A0async functions &a=
mp; variables.</div><div><br></div><div>When right-async is used, the funct=
ion return type must conform to Coroutine Return Object, that is, it must h=
ave the corresponding Coroutine Promise defined.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><div></div><div>=C2=A03. I do not see any mention on the "mon=
ad" type (or maybe async or synchronization return type?) extension po=
ssibilites like in N4402.</div><div>Are you suggesting (without describing =
it) that these types would still need to be implemented following a similar=
extension mechanism</div><div>as in N4402?</div></div></div></div></blockq=
uote><div><br></div>Yep, in the very front of the "Design" sectio=
n, I do mention that this draft is based on Coroutine Promise and Awaitable=
concepts from N4402.</div><div class=3D"gmail_quote"><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>The first comparison is a bit confusing on this point, because if:</div><d=
iv><br></div><div>=C2=A0 =C2=A0 std::future<T> do_something(...); // =
N4402</div><div><br></div><div>is equivalent to=C2=A0</div><div><br></div><=
div>=C2=A0 =C2=A0 async T do_something(...);</div><div><br></div><div>then =
you are suggesting that T's "synchronization" type should be =
an implementation detail? Or did you mean that async T is really async futu=
re<T> ?</div></div></div></div></blockquote><div><br></div><div>Not a=
t all, =C2=A0`async T do_something(...)` is not really a concrete function,=
it's more like a function template that only exists in compile-time.</=
div><div>When `async T do_something(...)` is evaluated with async-context, =
the code will be "merged" into the parent frame, no intermediate =
"monad" thing will be generated.</div><div>The only exception is =
for recursion, when there's recursion, the compiler will indeed make so=
me future-like thing behind the scene.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
div></div><div>4. What about executors? How would a user specify an executo=
r instead of the default implementation on calling asynchronously any funct=
ion?</div></div></div></div></blockquote><div><br></div><div>Typically we j=
ust call something like `await post(executor)` in N4402 to schedule the cor=
outine on executor.</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><=
div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>I think it would =
be useful to have this document to be read, at least, by the concurrency TS=
people.</div></div></div></div></blockquote><div><br></div><div>Thanks for=
your feedback!</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1140f92874784805204c9932--
.
Author: Giovanni Piero Deretta <gpderetta@gmail.com>
Date: Tue, 22 Sep 2015 08:14:28 -0700 (PDT)
Raw View
------=_Part_609_491428224.1442934868487
Content-Type: multipart/alternative;
boundary="----=_Part_610_1295023432.1442934868487"
------=_Part_610_1295023432.1442934868487
Content-Type: text/plain; charset=UTF-8
On Monday, September 21, 2015 at 4:41:30 PM UTC+1, TONGARI J wrote:
>
> Hi,
>
> Please find the draft here:
> https://gist.github.com/jamboree/a2b3fe32eeb8c21e820c
>
> It's my thoughts on the possible joint of Resumable Functions(N4402) and
> Resumable Expressions(N4453).
>
> To be clear, I'm not gonna write a complete proposal, I just hope the
> authors and people behind the aforementioned proposals could take the idea
> into account.
>
> Any feedback is welcome.
>
From the document:
"In yield-first approach, however, there's no way to make the coroutine
ready-to-suspend before it is really suspended. To prevent the coroutine
from being resumed before it is suspended, sychronization is needed, which
imposes some runtime overhead that the await-first approach is free from. "
That doesn't seem right to me and doesn't match my experience. It is
certainly possible to suspend the coroutine and then start the operation
from inside the async function given a rich enough interface. Can you
expand on it?
-- gpd
--
---
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_610_1295023432.1442934868487
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, September 21, 2015 at 4:41:30 PM UTC+1, TONGARI J wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hi,<div><br></div><di=
v>Please find the draft here:</div><div><a href=3D"https://gist.github.com/=
jamboree/a2b3fe32eeb8c21e820c" target=3D"_blank" rel=3D"nofollow" onmousedo=
wn=3D"this.href=3D'https://www.google.com/url?q\75https%3A%2F%2Fgist.gi=
thub.com%2Fjamboree%2Fa2b3fe32eeb8c21e820c\46sa\75D\46sntz\0751\46usg\75AFQ=
jCNHJ3aVyiSk4aYnbiZV8XxnunUhhUA';return true;" onclick=3D"this.href=3D&=
#39;https://www.google.com/url?q\75https%3A%2F%2Fgist.github.com%2Fjamboree=
%2Fa2b3fe32eeb8c21e820c\46sa\75D\46sntz\0751\46usg\75AFQjCNHJ3aVyiSk4aYnbiZ=
V8XxnunUhhUA';return true;">https://gist.github.com/<wbr>jamboree/a2b3f=
e32eeb8c21e820c</a><br></div><div><br></div>It's my thoughts on the pos=
sible joint of Resumable Functions(N4402) and Resumable Expressions(N4453).=
<div><br></div><div>To be clear, I'm not gonna write a complete proposa=
l, I just hope the authors and people behind the aforementioned proposals c=
ould take the idea into account.</div><br>Any feedback is welcome.</div></b=
lockquote><div><br>From the document:<br><br>"In yield-first approach,=
however, there's no way to make the coroutine=20
ready-to-suspend before it is really suspended. To prevent the coroutine
from being resumed before it is suspended, sychronization is needed,=20
which imposes some runtime overhead that the await-first approach is=20
free from. "<br><br>That doesn't seem right to me and doesn't =
match my experience. It is certainly possible to suspend the coroutine and =
then start the operation from inside the async function given a rich enough=
interface. Can you expand on it? <br><br>-- gpd<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_610_1295023432.1442934868487--
------=_Part_609_491428224.1442934868487--
.