Topic: P0057, continuations, and scope creep
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 23 Nov 2015 08:35:23 -0800 (PST)
Raw View
------=_Part_617_2115986663.1448296523444
Content-Type: multipart/alternative;
boundary="----=_Part_618_917826916.1448296523444"
------=_Part_618_917826916.1448296523444
Content-Type: text/plain; charset=UTF-8
I've been reading through some of the criticisms of P0057 that has been
written up in formal proposals. P0158's criticism <http://wg21.link/P0158>
is interesting, but it occassionally has a tone that seems... petulant,
particularly the "nobody implemented it on a compiler that works in Linux,
so you don't really know anything" bit. But I found P0162
<http://wg21.link/P0162> to be particularly disconcerting, making me wonder
what happened with P0057 to bring this about.
As I thought about it, what I feel has happened is that P0057 has succumbed
to two problems: trying to do too much, and trying to use the wrong
abstraction to do so.
At its core, P0057 is conceptually about one thing: continuations. If you
boil down all of the extraneous stuff in the feature, its purpose is to
make continuations work more effectively in C++. You take a function, tell
it to stop right here, and then you hand the function off to some other
code that decides when you get to continue.
This is the "suspend up" model, because the code that decides when you
continue is defined ultimately by the expression you are "awaiting" on. The
promise machinery in such coroutines exist to allow the caller of them to
be able to interact with the coroutine, regardless of where it actually
gets finished.
This all ought to make P0057 ideal for continuation-based programming. And
the networking TS is all about continuation-based async programming. And
yet... P0162 makes it abundantly clear that P0057 kinda sucks at it. That
however much the syntax may be nicer, it is no better in performance than
doing it manually and in some cases non-trivially worse (percentage-wise).
It is certainly far from being the widely touted "negative overhead
abstraction" in these use cases.
How is it that a language feature intended for continuations fails so
miserably at working with a continuation-based API?
Well, I think part of the problem is that P0057 is really trying to do too
much. If resumable functions are all about continuations, why does
`co_yield` exist? After all, `co_yield` doesn't schedule anything; it
always suspends the coroutine and returns the given value. The code that's
ultimately intended to schedule the resumption is the caller.
In short, `co_yield` is all about turning a suspend-up model into a suspend-
*down* model.
Let's look at some of the things that have to be added to the feature in
order to support a suspend-down model.
First, you have to have a way to get rid of the allocation of the
coroutine's stack. In normal continuation code, that allocation must
happen, because the function is never local to its scope. But with
generators, the function is usually local, so the allocation is pointless.
This means that P0057 must have specific wording allowing the compiler to
elide the stack's allocation. But that's fairly minor.
A more major issue is that promises have to be given access to their
coroutine handles. The only reason to do this is to allow the return object
(and the promise that delivers it) to actually cause the resumption of the
coroutine. So this is one bit of machinery that exists solely to transform
suspend-up into suspend-down; a suspend-up-based promise doesn't care about
the handle.
And speaking of such machinery, there is P0057R1's `await_transform`
mechanic. This is a mechanism by which the promise can get involved in each
`co_await` expression.
Why does the promise object need to involve itself in the particular await
style that's happening? This is in part to allow a promise to decide if it
should always suspend regardless of whether the value is ready (thus
"solving" one of the criticisms of the proposal). But it also exists to
allow a single promise to support suspend-up and suspend-down, depending on
what is being awaited on. This means that the promise can force suspend
down or up, that the promise can involve itself in the decision of how to
schedule the resumption.
This leads to the behavior of `co_await` being a highly complicated
convergence of the type of the expression, the overload for operator
co_await on that type, and the promise type (which itself is derived in
part from the function's return type and possibly its parameters).
It seems like every time a problem is raised with the proposal, the
solution is to make it more complex. `operator await` was added to allow
users to await on types that don't have the await machinery already in
them. `await_transform` was added so that promises could get involved in
the await process. And so forth.
When you patch something so much that the result looks like a mass of
patches rather than a logical feature, you have to ask yourself a question:
is this the right way to solve the problem to begin with?
I'm not saying that resumable expressions is better. It's a fine tool for
suspend-down, but it absolutely *sucks* at continuation support. Indeed,
most suspend-down proposal suck at continuations. Even N4398 is really just
suspend-down with possible compiler-based optimizations; it's just as bad
at continuations as any other suspend-down model.
What I think we need is a low-level continuation syntax that is based on
just the core feature of pausing a function and transferring its resumption
to someone else (the latter part being what resumable expressions, P0099,
and all other suspend-down models are terrible at).
The main problem with it is that, to make continuations work, you need to
be able to do all of the following. But they all have to happen
*simultaneously*, in a single C++ operation, all locally to that function:
1) return a value to the immediate caller
2) take the object representing the function and give it to someone else,
who will schedule its resumption (which may or may not happen immediately)
3) suspend the function
All the other stuff about promises, awaitables, and such is just syntactic
cruft that seems to have accrued around the basic concept. I would suggest
that a reconceptualization of P0057, based on just the absolute bare
minimum needed to do the above, should be looked at.
The ultimate focus of such a project should be on making a
continuation-based model that the networking TS can work effectively with.
Because if a continuation-based coroutine model doesn't match well with an
API who's asynchronous model is built on continuations, then what good is
it?
--
---
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_618_917826916.1448296523444
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I've been reading through some of the criticisms of P0=
057 that has been written up in formal proposals. <a href=3D"http://wg21.li=
nk/P0158">P0158's criticism</a> is interesting, but it occassionally ha=
s a tone that seems... petulant, particularly the "nobody implemented =
it on a compiler that works in Linux, so you don't really know anything=
" bit. But I found <a href=3D"http://wg21.link/P0162">P0162</a> to be =
particularly disconcerting, making me wonder what happened with P0057 to br=
ing this about.<br><br>As I thought about it, what I feel has happened is t=
hat P0057 has succumbed to two problems: trying to do too much, and trying =
to use the wrong abstraction to do so.<br><br>At its core, P0057 is concept=
ually about one thing: continuations. If you boil down all of the extraneou=
s stuff in the feature, its purpose is to make continuations work more effe=
ctively in C++. You take a function, tell it to stop right here, and then y=
ou hand the function off to some other code that decides when you get to co=
ntinue.<br><br>This is the "suspend up" model, because the code t=
hat decides when you continue is defined ultimately by the expression you a=
re "awaiting" on. The promise machinery in such coroutines exist =
to allow the caller of them to be able to interact with the coroutine, rega=
rdless of where it actually gets finished.<br><br>This all ought to make P0=
057 ideal for continuation-based programming. And the networking TS is all =
about continuation-based async programming. And yet... P0162 makes it abund=
antly clear that P0057 kinda sucks at it. That however much the syntax may =
be nicer, it is no better in performance than doing it manually and in some=
cases non-trivially worse (percentage-wise).<br><br>It is certainly far fr=
om being the widely touted "negative overhead abstraction" in the=
se use cases.<br><br>How is it that a language feature intended for continu=
ations fails so miserably at working with a continuation-based API?<br><br>=
Well, I think part of the problem is that P0057 is really trying to do too =
much. If resumable functions are all about continuations, why does `co_yiel=
d` exist? After all, `co_yield` doesn't schedule anything; it always su=
spends the coroutine and returns the given value. The code that's ultim=
ately intended to schedule the resumption is the caller.<br><br>In short, `=
co_yield` is all about turning a suspend-up model into a suspend-<i>down</i=
> model.<br><br>Let's look at some of the things that have to be added =
to the feature in order to support a suspend-down model.<br><br>First, you =
have to have a way to get rid of the allocation of the coroutine's stac=
k. In normal continuation code, that allocation must happen, because the fu=
nction is never local to its scope. But with generators, the function is us=
ually local, so the allocation is pointless. This means that P0057 must hav=
e specific wording allowing the compiler to elide the stack's allocatio=
n. But that's fairly minor.<br><br>A more major issue is that promises =
have to be given access to their coroutine handles. The only reason to do t=
his is to allow the return object (and the promise that delivers it) to act=
ually cause the resumption of the coroutine. So this is one bit of machiner=
y that exists solely to transform suspend-up into suspend-down; a suspend-u=
p-based promise doesn't care about the handle.<br><br>And speaking of s=
uch machinery, there is P0057R1's `await_transform` mechanic. This is a=
mechanism by which the promise can get involved in each `co_await` express=
ion.<br><br>Why does the promise object need to involve itself in the parti=
cular await style that's happening? This is in part to allow a promise =
to decide if it should always suspend regardless of whether the value is re=
ady (thus "solving" one of the criticisms of the proposal). But i=
t also exists to allow a single promise to support suspend-up and suspend-d=
own, depending on what is being awaited on. This means that the promise can=
force suspend down or up, that the promise can involve itself in the decis=
ion of how to schedule the resumption.<br><br>This leads to the behavior of=
`co_await` being a highly complicated=20
convergence of the type of the expression, the overload for operator=20
co_await on that type, and the promise type (which itself is derived in=20
part from the function's return type and possibly its parameters).<br><=
br>It seems like every time a problem is raised with the proposal, the solu=
tion is to make it more complex. `operator await` was added to allow users =
to await on types that don't have the await machinery already in them. =
`await_transform` was added so that promises could get involved in the awai=
t process. And so forth.<br><br>When you patch something so much that the r=
esult looks like a mass of patches rather than a logical feature, you have =
to ask yourself a question: is this the right way to solve the problem to b=
egin with?<br><br>I'm not saying that resumable expressions is better. =
It's a fine tool for suspend-down, but it absolutely <i>sucks</i> at co=
ntinuation support. Indeed, most suspend-down proposal suck at continuation=
s. Even N4398 is really just suspend-down with possible compiler-based opti=
mizations; it's just as bad at continuations as any other suspend-down =
model.<br><br>What I think we need is a low-level continuation syntax that =
is based on just the core feature of pausing a function and transferring it=
s resumption to someone else (the latter part being what resumable expressi=
ons, P0099, and all other suspend-down models are terrible at).<br><br>The =
main problem with it is that, to make continuations work, you need to be ab=
le to do all of the following. But they all have to happen <i>simultaneousl=
y</i>, in a single C++ operation, all locally to that function:<br><br>1) r=
eturn a value to the immediate caller<br>2) take the object representing th=
e function and give it to someone else, who will schedule its resumption (w=
hich may or may not happen immediately)<br>3) suspend the function<br><br>A=
ll the other stuff about promises, awaitables, and such is just syntactic c=
ruft that seems to have accrued around the basic concept. I would suggest t=
hat a reconceptualization of P0057, based on just the absolute bare minimum=
needed to do the above, should be looked at.<br><br>The ultimate focus of =
such a project should be on making a continuation-based model that the netw=
orking TS can work effectively with. Because if a continuation-based corout=
ine model doesn't match well with an API who's asynchronous model i=
s built on continuations, then what good is it?<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_618_917826916.1448296523444--
------=_Part_617_2115986663.1448296523444--
.
Author: petke <patrik.kahari@gmail.com>
Date: Sat, 13 Feb 2016 15:59:05 -0800 (PST)
Raw View
------=_Part_3619_1140912873.1455407945678
Content-Type: multipart/alternative;
boundary="----=_Part_3620_1091453850.1455407945679"
------=_Part_3620_1091453850.1455407945679
Content-Type: text/plain; charset=UTF-8
I'm a casual observer. I find your arguments convincing and the topic
interesting. The topic of "suspend up" vs "suspend down" being
fundamentally different and irreconcilable. I'm a bit surprised there
hasn't been any replies here (in almost 3 months). Have you gotten some
feedback on this through other channels? Or has there been any new
developments on this topic?
Regards /Petke
On Monday, November 23, 2015 at 4:35:23 PM UTC, Nicol Bolas wrote:
>
> I've been reading through some of the criticisms of P0057 that has been
> written up in formal proposals. P0158's criticism <http://wg21.link/P0158>
> is interesting, but it occassionally has a tone that seems... petulant,
> particularly the "nobody implemented it on a compiler that works in Linux,
> so you don't really know anything" bit. But I found P0162
> <http://wg21.link/P0162> to be particularly disconcerting, making me
> wonder what happened with P0057 to bring this about.
>
> As I thought about it, what I feel has happened is that P0057 has
> succumbed to two problems: trying to do too much, and trying to use the
> wrong abstraction to do so.
>
> At its core, P0057 is conceptually about one thing: continuations. If you
> boil down all of the extraneous stuff in the feature, its purpose is to
> make continuations work more effectively in C++. You take a function, tell
> it to stop right here, and then you hand the function off to some other
> code that decides when you get to continue.
>
> This is the "suspend up" model, because the code that decides when you
> continue is defined ultimately by the expression you are "awaiting" on. The
> promise machinery in such coroutines exist to allow the caller of them to
> be able to interact with the coroutine, regardless of where it actually
> gets finished.
>
> This all ought to make P0057 ideal for continuation-based programming. And
> the networking TS is all about continuation-based async programming. And
> yet... P0162 makes it abundantly clear that P0057 kinda sucks at it. That
> however much the syntax may be nicer, it is no better in performance than
> doing it manually and in some cases non-trivially worse (percentage-wise).
>
> It is certainly far from being the widely touted "negative overhead
> abstraction" in these use cases.
>
> How is it that a language feature intended for continuations fails so
> miserably at working with a continuation-based API?
>
> Well, I think part of the problem is that P0057 is really trying to do too
> much. If resumable functions are all about continuations, why does
> `co_yield` exist? After all, `co_yield` doesn't schedule anything; it
> always suspends the coroutine and returns the given value. The code that's
> ultimately intended to schedule the resumption is the caller.
>
> In short, `co_yield` is all about turning a suspend-up model into a
> suspend-*down* model.
>
> Let's look at some of the things that have to be added to the feature in
> order to support a suspend-down model.
>
> First, you have to have a way to get rid of the allocation of the
> coroutine's stack. In normal continuation code, that allocation must
> happen, because the function is never local to its scope. But with
> generators, the function is usually local, so the allocation is pointless.
> This means that P0057 must have specific wording allowing the compiler to
> elide the stack's allocation. But that's fairly minor.
>
> A more major issue is that promises have to be given access to their
> coroutine handles. The only reason to do this is to allow the return object
> (and the promise that delivers it) to actually cause the resumption of the
> coroutine. So this is one bit of machinery that exists solely to transform
> suspend-up into suspend-down; a suspend-up-based promise doesn't care about
> the handle.
>
> And speaking of such machinery, there is P0057R1's `await_transform`
> mechanic. This is a mechanism by which the promise can get involved in each
> `co_await` expression.
>
> Why does the promise object need to involve itself in the particular await
> style that's happening? This is in part to allow a promise to decide if it
> should always suspend regardless of whether the value is ready (thus
> "solving" one of the criticisms of the proposal). But it also exists to
> allow a single promise to support suspend-up and suspend-down, depending on
> what is being awaited on. This means that the promise can force suspend
> down or up, that the promise can involve itself in the decision of how to
> schedule the resumption.
>
> This leads to the behavior of `co_await` being a highly complicated
> convergence of the type of the expression, the overload for operator
> co_await on that type, and the promise type (which itself is derived in
> part from the function's return type and possibly its parameters).
>
> It seems like every time a problem is raised with the proposal, the
> solution is to make it more complex. `operator await` was added to allow
> users to await on types that don't have the await machinery already in
> them. `await_transform` was added so that promises could get involved in
> the await process. And so forth.
>
> When you patch something so much that the result looks like a mass of
> patches rather than a logical feature, you have to ask yourself a question:
> is this the right way to solve the problem to begin with?
>
> I'm not saying that resumable expressions is better. It's a fine tool for
> suspend-down, but it absolutely *sucks* at continuation support. Indeed,
> most suspend-down proposal suck at continuations. Even N4398 is really just
> suspend-down with possible compiler-based optimizations; it's just as bad
> at continuations as any other suspend-down model.
>
> What I think we need is a low-level continuation syntax that is based on
> just the core feature of pausing a function and transferring its resumption
> to someone else (the latter part being what resumable expressions, P0099,
> and all other suspend-down models are terrible at).
>
> The main problem with it is that, to make continuations work, you need to
> be able to do all of the following. But they all have to happen
> *simultaneously*, in a single C++ operation, all locally to that function:
>
> 1) return a value to the immediate caller
> 2) take the object representing the function and give it to someone else,
> who will schedule its resumption (which may or may not happen immediately)
> 3) suspend the function
>
> All the other stuff about promises, awaitables, and such is just syntactic
> cruft that seems to have accrued around the basic concept. I would suggest
> that a reconceptualization of P0057, based on just the absolute bare
> minimum needed to do the above, should be looked at.
>
> The ultimate focus of such a project should be on making a
> continuation-based model that the networking TS can work effectively with.
> Because if a continuation-based coroutine model doesn't match well with an
> API who's asynchronous model is built on continuations, then what good is
> it?
>
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3620_1091453850.1455407945679
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm a casual observer. I find your arguments convincin=
g and the topic interesting. The topic of "suspend up" vs "s=
uspend down" being fundamentally different and irreconcilable. I'm=
a bit surprised there hasn't been any replies here (in almost 3 months=
). Have you gotten some feedback on this through other channels? Or has the=
re been any new developments on this topic?<div><br></div><div>Regards /Pet=
ke<br><br><br>On Monday, November 23, 2015 at 4:35:23 PM UTC, Nicol Bolas w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I've=
been reading through some of the criticisms of P0057 that has been written=
up in formal proposals. <a href=3D"http://wg21.link/P0158" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/u=
rl?q\75http%3A%2F%2Fwg21.link%2FP0158\46sa\75D\46sntz\0751\46usg\75AFQjCNH0=
T3UB0flMUlDqcqiEqZDwmqi9Qw';return true;" onclick=3D"this.href=3D'h=
ttp://www.google.com/url?q\75http%3A%2F%2Fwg21.link%2FP0158\46sa\75D\46sntz=
\0751\46usg\75AFQjCNH0T3UB0flMUlDqcqiEqZDwmqi9Qw';return true;">P0158&#=
39;s criticism</a> is interesting, but it occassionally has a tone that see=
ms... petulant, particularly the "nobody implemented it on a compiler =
that works in Linux, so you don't really know anything" bit. But I=
found <a href=3D"http://wg21.link/P0162" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%=
2Fwg21.link%2FP0162\46sa\75D\46sntz\0751\46usg\75AFQjCNG4PJ1v0h6S_6NtZOljFO=
xdNtMceg';return true;" onclick=3D"this.href=3D'http://www.google.c=
om/url?q\75http%3A%2F%2Fwg21.link%2FP0162\46sa\75D\46sntz\0751\46usg\75AFQj=
CNG4PJ1v0h6S_6NtZOljFOxdNtMceg';return true;">P0162</a> to be particula=
rly disconcerting, making me wonder what happened with P0057 to bring this =
about.<br><br>As I thought about it, what I feel has happened is that P0057=
has succumbed to two problems: trying to do too much, and trying to use th=
e wrong abstraction to do so.<br><br>At its core, P0057 is conceptually abo=
ut one thing: continuations. If you boil down all of the extraneous stuff i=
n the feature, its purpose is to make continuations work more effectively i=
n C++. You take a function, tell it to stop right here, and then you hand t=
he function off to some other code that decides when you get to continue.<b=
r><br>This is the "suspend up" model, because the code that decid=
es when you continue is defined ultimately by the expression you are "=
awaiting" on. The promise machinery in such coroutines exist to allow =
the caller of them to be able to interact with the coroutine, regardless of=
where it actually gets finished.<br><br>This all ought to make P0057 ideal=
for continuation-based programming. And the networking TS is all about con=
tinuation-based async programming. And yet... P0162 makes it abundantly cle=
ar that P0057 kinda sucks at it. That however much the syntax may be nicer,=
it is no better in performance than doing it manually and in some cases no=
n-trivially worse (percentage-wise).<br><br>It is certainly far from being =
the widely touted "negative overhead abstraction" in these use ca=
ses.<br><br>How is it that a language feature intended for continuations fa=
ils so miserably at working with a continuation-based API?<br><br>Well, I t=
hink part of the problem is that P0057 is really trying to do too much. If =
resumable functions are all about continuations, why does `co_yield` exist?=
After all, `co_yield` doesn't schedule anything; it always suspends th=
e coroutine and returns the given value. The code that's ultimately int=
ended to schedule the resumption is the caller.<br><br>In short, `co_yield`=
is all about turning a suspend-up model into a suspend-<i>down</i> model.<=
br><br>Let's look at some of the things that have to be added to the fe=
ature in order to support a suspend-down model.<br><br>First, you have to h=
ave a way to get rid of the allocation of the coroutine's stack. In nor=
mal continuation code, that allocation must happen, because the function is=
never local to its scope. But with generators, the function is usually loc=
al, so the allocation is pointless. This means that P0057 must have specifi=
c wording allowing the compiler to elide the stack's allocation. But th=
at's fairly minor.<br><br>A more major issue is that promises have to b=
e given access to their coroutine handles. The only reason to do this is to=
allow the return object (and the promise that delivers it) to actually cau=
se the resumption of the coroutine. So this is one bit of machinery that ex=
ists solely to transform suspend-up into suspend-down; a suspend-up-based p=
romise doesn't care about the handle.<br><br>And speaking of such machi=
nery, there is P0057R1's `await_transform` mechanic. This is a mechanis=
m by which the promise can get involved in each `co_await` expression.<br><=
br>Why does the promise object need to involve itself in the particular awa=
it style that's happening? This is in part to allow a promise to decide=
if it should always suspend regardless of whether the value is ready (thus=
"solving" one of the criticisms of the proposal). But it also ex=
ists to allow a single promise to support suspend-up and suspend-down, depe=
nding on what is being awaited on. This means that the promise can force su=
spend down or up, that the promise can involve itself in the decision of ho=
w to schedule the resumption.<br><br>This leads to the behavior of `co_awai=
t` being a highly complicated=20
convergence of the type of the expression, the overload for operator=20
co_await on that type, and the promise type (which itself is derived in=20
part from the function's return type and possibly its parameters).<br><=
br>It seems like every time a problem is raised with the proposal, the solu=
tion is to make it more complex. `operator await` was added to allow users =
to await on types that don't have the await machinery already in them. =
`await_transform` was added so that promises could get involved in the awai=
t process. And so forth.<br><br>When you patch something so much that the r=
esult looks like a mass of patches rather than a logical feature, you have =
to ask yourself a question: is this the right way to solve the problem to b=
egin with?<br><br>I'm not saying that resumable expressions is better. =
It's a fine tool for suspend-down, but it absolutely <i>sucks</i> at co=
ntinuation support. Indeed, most suspend-down proposal suck at continuation=
s. Even N4398 is really just suspend-down with possible compiler-based opti=
mizations; it's just as bad at continuations as any other suspend-down =
model.<br><br>What I think we need is a low-level continuation syntax that =
is based on just the core feature of pausing a function and transferring it=
s resumption to someone else (the latter part being what resumable expressi=
ons, P0099, and all other suspend-down models are terrible at).<br><br>The =
main problem with it is that, to make continuations work, you need to be ab=
le to do all of the following. But they all have to happen <i>simultaneousl=
y</i>, in a single C++ operation, all locally to that function:<br><br>1) r=
eturn a value to the immediate caller<br>2) take the object representing th=
e function and give it to someone else, who will schedule its resumption (w=
hich may or may not happen immediately)<br>3) suspend the function<br><br>A=
ll the other stuff about promises, awaitables, and such is just syntactic c=
ruft that seems to have accrued around the basic concept. I would suggest t=
hat a reconceptualization of P0057, based on just the absolute bare minimum=
needed to do the above, should be looked at.<br><br>The ultimate focus of =
such a project should be on making a continuation-based model that the netw=
orking TS can work effectively with. Because if a continuation-based corout=
ine model doesn't match well with an API who's asynchronous model i=
s built on continuations, then what good is it?<br></div></blockquote></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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_3620_1091453850.1455407945679--
------=_Part_3619_1140912873.1455407945678--
.