------=_Part_2198_465842834.1443872478474
Content-Type: multipart/alternative;
 boundary="----=_Part_2199_66584921.1443872478474"

------=_Part_2199_66584921.1443872478474
Content-Type: text/plain; charset=UTF-8

Hello everyone,

I do not mean to start a flame here, but I am still wondering why the
coroutines from
P0057R0 are still being considered.

For what it is worth, I find the paper from Christopher Kohlhoff very
clarifying, very well
reasoned, and providing alternatives for all the important use cases from
P0057R0 with
superior implementations.

I still share the same concerns as before for P0057R0, mainly:

- mandatory type erasure.
- as Christopher mentions, embedding a scheduler into the language is not a
nice thing.
- viral await is also something to be aware of.


On top of that, he shows alternatives for implementations:

1. Generators (reified and type-erased).
2. await.



You also have yield as an object, which I think can be of advantage in many
situations.

But my real question is, since I am not an expert:

1. There is something that can be done in P0057R0 that simply cannot be
done by resumable expressions + reasonable library support?

For me await/async + embedded scheduler is something like getting married
to an implementation detail that
a run-time must support. The mandatory type-erasure is not nice, compared
to being able to generate
what you would write by hand, a function object, which is what resumable
expressions do.

Am I missing anything here? As I say, my knowledge is quite limited in this
area.



--

---
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_2199_66584921.1443872478474
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello everyone,<div><br></div><div>I do not mean to start =
a flame here, but I am still wondering why the coroutines from</div><div>P0=
057R0 are still being considered.</div><div><br></div><div>For what it is w=
orth, I find the paper from Christopher Kohlhoff very clarifying, very well=
</div><div>reasoned, and providing alternatives for all the important use c=
ases from P0057R0 with</div><div>superior implementations.</div><div><br></=
div><div>I still share the same concerns as before for P0057R0, mainly:</di=
v><div><br></div><div>- mandatory type erasure.</div><div>- as Christopher =
mentions, embedding a scheduler into the language is not a nice thing.</div=
><div>- viral await is also something to be aware of.</div><div><br></div><=
div><br></div><div>On top of that, he shows alternatives for implementation=
s:</div><div><br></div><div>1. Generators (reified and type-erased).</div><=
div>2. await.</div><div><br></div><div><br></div><div><br></div><div>You al=
so have yield as an object, which I think can be of advantage in many situa=
tions.</div><div><br></div><div>But my real question is, since I am not an =
expert:</div><div><br></div><div>1. There is something that can be done in =
P0057R0 that simply cannot be done by resumable expressions + reasonable li=
brary support?</div><div><br></div><div>For me await/async + embedded sched=
uler is something like getting married to an implementation detail that</di=
v><div>a run-time must support. The mandatory type-erasure is not nice, com=
pared to being able to generate</div><div>what you would write by hand, a f=
unction object, which is what resumable expressions do.=C2=A0</div><div><br=
></div><div>Am I missing anything here? As I say, my knowledge is quite lim=
ited in this area.</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&quot; 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_2199_66584921.1443872478474--
------=_Part_2198_465842834.1443872478474--

.

------=_Part_1774_1046105529.1443880638336
Content-Type: multipart/alternative;
 boundary="----=_Part_1775_507360727.1443880638336"

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



On Saturday, October 3, 2015 at 7:41:18 AM UTC-4, Germ=C3=A1n Diago wrote:
>
> Hello everyone,
>
> I do not mean to start a flame here, but I am still wondering why the=20
> coroutines from
> P0057R0 are still being considered.
>
> For what it is worth, I find the paper from Christopher Kohlhoff very=20
> clarifying, very well
> reasoned, and providing alternatives for all the important use cases from=
=20
> P0057R0 with
> superior implementations.
>

I am in no way deeply familiar with either of these two proposals. However,=
=20
after skimming P0114, one thing seems very clear: P0057 is *much* farther=
=20
along, in terms of actually creating an implementable standard.

The P0057 paper itself is actual wording, ready to be incorporated into the=
=20
standard. Not only that, P0057 has actual, *live* implementation experience=
=20
behind it. You can go get VS2015 right now and play with their=20
implementation of a version of this functionality=20
<https://paoloseverini.wordpress.com/2015/03/06/stackless-coroutines-with-v=
s2015/>
..

P0114 seems more... experimental. It sounds like something that has been=20
discussed to some degree, but is as of yet lacking a proof-of-concept=20
implementation. A lot is said about how it would be "possible" to implement=
=20
some particular facet under their new rules. But the paper never claims=20
that they've taken Clang or GCC or whatever and actually implemented it.

That's not to say that P0114 is dead and all effort should be focused on=20
P0057. But however much you may find P0114 to be technically superior,=20
P0057 has *earned* the right to be considered.

--=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_1775_507360727.1443880638336
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, October 3, 2015 at 7:41:18 AM UTC-4, =
Germ=C3=A1n Diago wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">Hello everyone,<div><br></div><div>I do not mean to start a flam=
e here, but I am still wondering why the coroutines from</div><div>P0057R0 =
are still being considered.</div><div><br></div><div>For what it is worth, =
I find the paper from Christopher Kohlhoff very clarifying, very well</div>=
<div>reasoned, and providing alternatives for all the important use cases f=
rom P0057R0 with</div><div>superior implementations.</div></div></blockquot=
e><div><br>I am in no way deeply familiar with either of these two proposal=
s. However, after skimming P0114, one thing seems very clear: P0057 is <i>m=
uch</i> farther along, in terms of actually creating an implementable stand=
ard.<br><br>The P0057 paper itself is actual wording, ready to be incorpora=
ted into the standard. Not only that, P0057 has actual, <i>live</i> impleme=
ntation experience behind it. You can go get VS2015 right now and <a href=
=3D"https://paoloseverini.wordpress.com/2015/03/06/stackless-coroutines-wit=
h-vs2015/">play with their implementation of a version of this functionalit=
y</a>.<br><br>P0114 seems more... experimental. It sounds like something th=
at has been discussed to some degree, but is as of yet lacking a proof-of-c=
oncept implementation. A lot is said about how it would be &quot;possible&q=
uot; to implement some particular facet under their new rules. But the pape=
r never claims that they&#39;ve taken Clang or GCC or whatever and actually=
 implemented it.<br><br>That&#39;s not to say that P0114 is dead and all ef=
fort should be focused on P0057. But however much you may find P0114 to be =
technically superior, P0057 has <i>earned</i> the right to be considered.</=
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&quot; 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_1775_507360727.1443880638336--
------=_Part_1774_1046105529.1443880638336--

.

------=_Part_2751_2024941593.1443928328101
Content-Type: multipart/alternative;
 boundary="----=_Part_2752_234557836.1443928328101"

------=_Part_2752_234557836.1443928328101
Content-Type: text/plain; charset=UTF-8


>
>
> P0114 seems more... experimental. It sounds like something that has been
> discussed to some degree, but is as of yet lacking a proof-of-concept
> implementation. A lot is said about how it would be "possible" to implement
> some particular facet under their new rules. But the paper never claims
> that they've taken Clang or GCC or whatever and actually implemented it.
>
> There is an experimental implementation.


> That's not to say that P0114 is dead and all effort should be focused on
> P0057. But however much you may find P0114 to be technically superior,
> P0057 has *earned* the right to be considered.
>

Well, to me P0057 violates the *zero-overhead principle* that can be
avoided by the other proposal, in my humble opinion. You do need boxing.
Besides that, it has other disadvantages, and I see a bit of a mistake,
again, in my opinion, to embed a scheduler into the language, when you
could do it in a library, as Christopher's paper shows.

But I am not in the commitee or proposed anything. It just seems to me that
Christopher's proposal is more lightweight and can do everything
that P0057 can do 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_2752_234557836.1443928328101
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><br>P0114 seems more... experimental. It sounds like something tha=
t has been discussed to some degree, but is as of yet lacking a proof-of-co=
ncept implementation. A lot is said about how it would be &quot;possible&qu=
ot; to implement some particular facet under their new rules. But the paper=
 never claims that they&#39;ve taken Clang or GCC or whatever and actually =
implemented it.<br><br></div></div></blockquote><div>There is an experiment=
al implementation.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><div>That&#39;s not to say that P0114 is dead a=
nd all effort should be focused on P0057. But however much you may find P01=
14 to be technically superior, P0057 has <i>earned</i> the right to be cons=
idered.</div></div></blockquote><div><br></div><div>Well, to me P0057 viola=
tes the *zero-overhead principle* that can be avoided by the other proposal=
, in my humble opinion. You do need boxing.<br></div><div>Besides that, it =
has other disadvantages, and I see a bit of a mistake, again, in my opinion=
, to embed a scheduler into the language, when you could do it in a library=
, as Christopher&#39;s paper shows.</div><div><br></div><div>But I am not i=
n the commitee or proposed anything. It just seems to me that Christopher&#=
39;s proposal is more lightweight and can do everything</div><div>that P005=
7 can do better.</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&quot; 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_2752_234557836.1443928328101--
------=_Part_2751_2024941593.1443928328101--

.

Nicol Bolas wrote:
>
> The P0057 paper itself is actual wording, ready to be incorporated into the
> standard. Not only that, P0057 has actual, live implementation experience
> behind it. You can go get VS2015 right now and play with their
> implementation of a version of this functionality.
>
> P0114 seems more... experimental. It sounds like something that has been
> discussed to some degree, but is as of yet lacking a proof-of-concept
> implementation.
>

I believe CK may have a POC implementation available - that is a set
of patches against clang that adds the various features needed eg:
'resumable' et al.



That said, no single proposal has yet discussed why a compliant
compiler will never be able to deduce such scenarios without extra
keywords and rearranging of code - Similar things have been done to
achieve tail call optimizations, why can this not be done with
coroutines?

--

---
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_2807_63227893.1443933888162
Content-Type: multipart/alternative;
 boundary="----=_Part_2808_1911604701.1443933888162"

------=_Part_2808_1911604701.1443933888162
Content-Type: text/plain; charset=UTF-8


>
> I see a bit of a mistake, again, in my opinion, to embed a scheduler into
> the language, when you could do it in a library, as Christopher's paper
> shows.
>

There is absolutely no embedded scheduler in P0057 and never was. P0057 and
its predecessors provide syntactic sugar for common async and sync patterns
and it is up to the library to decide what meaning to imbue the coroutine
with.

I suggest to look at this presentation:

http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4287.pdf

which walks through some of the aspects of P0057 proposal. Note, that the
await syntax is actually quite old. It first appeared as do-notation in
Haskell in 1998 and you may notice that P0057 can be used to perform more
general "monadic" transformations and not only limited to coroutines.

Another thing that the presentation above highlights is that the
abstraction proposed is unique as it is not just zero-overhead. It is
negative overhead :-) . Meaning that for some problems, taking the
well-written code that uses functions / callbacks and rewriting it using
higher level abstractions, namely, the coroutines as proposed by PP0057
will result in simpler implementation, smaller object size and faster
execution.

--

---
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_2808_1911604701.1443933888162
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">I see a bit =
of a mistake, again, in my opinion, to embed a scheduler into the language,=
 when you could do it in a library, as Christopher&#39;s paper shows.</div>=
</blockquote><div><br></div><div>There is absolutely no embedded scheduler =
in P0057 and never was. P0057 and its predecessors provide syntactic sugar =
for common async and sync patterns and it is up to the library to decide wh=
at meaning to imbue the coroutine with. </div><div><br></div><div>I suggest=
 to look at this presentation:</div><div><br></div><div><a href=3D"http://o=
pen-std.org/JTC1/SC22/WG21/docs/papers/2014/n4287.pdf">http://open-std.org/=
JTC1/SC22/WG21/docs/papers/2014/n4287.pdf</a></div><div><br></div><div>whic=
h walks through some of the aspects of P0057 proposal. Note, that the await=
 syntax is actually quite old. It first appeared as do-notation in Haskell =
in 1998 and you may notice that=C2=A0P0057 can be used to perform more gene=
ral &quot;monadic&quot; transformations and=C2=A0not only limited to corout=
ines.</div><div><br></div><div>Another thing that the presentation above hi=
ghlights is that the abstraction proposed is unique as it is not just zero-=
overhead. It=C2=A0is negative overhead :-) . Meaning that for some problems=
, taking the well-written code that uses functions / callbacks=C2=A0and rew=
riting it using higher level abstractions, namely,=C2=A0the coroutines as p=
roposed by PP0057 will result in=C2=A0simpler implementation, smaller objec=
t size and faster execution. </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&quot; 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_2808_1911604701.1443933888162--
------=_Part_2807_63227893.1443933888162--

.

------=_Part_3043_1223282699.1443957245613
Content-Type: multipart/alternative;
 boundary="----=_Part_3044_787210307.1443957245613"

------=_Part_3044_787210307.1443957245613
Content-Type: text/plain; charset=UTF-8



On Sunday, October 4, 2015 at 11:44:48 AM UTC+7, Gor Nishanov wrote:
>
> I see a bit of a mistake, again, in my opinion, to embed a scheduler into
>> the language, when you could do it in a library, as Christopher's paper
>> shows.
>>
>
> There is absolutely no embedded scheduler in P0057 and never was.
>

Hello Gor. If there is no scheduler, I do not understand how await can
work. Forgive my ignorance, as I said above, I do not know to detail. But
my understanding is that if you have a call to await, that state for the
suspended coroutine must be kept somewhere. Where? I understand that this
state must live somewhere. Where is that state held?




> P0057 and its predecessors provide syntactic sugar for common async and
> sync patterns and it is up to the library to decide what meaning to imbue
> the coroutine with.
>


> I suggest to look at this presentation:
>
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4287.pdf
>


> Another thing that the presentation above highlights is that the
> abstraction proposed is unique as it is not just zero-overhead. It is
> negative overhead :-) . Meaning that for some problems, taking the
> well-written code that uses functions / callbacks and rewriting it using
> higher level abstractions, namely, the coroutines as proposed by PP0057
> will result in simpler implementation, smaller object size and faster
> execution.
>

I do not get yet how it can achieve this negative overhead. Even the
coroutines are type erased, as mentioned by Chris' papers. What can be
better than having inlinable, reified coroutines? I just do not get it.

I have three questions here:

1. How is the negative overhead achieved?
2. This would have negative overhead *compared* to an implementation with
resumable expressions?
3. Do these optimizations are fancy? We have had good inliners for years,
but it seems the coroutines from P0057 mandate
type erasure.

Sorry if I make any mistakes during my explanation, I am not an expert on
this papers, I just happen to understand quite well
Christopher's metaphor of function objects and I see very difficult
something more performant that non-type erased coroutines
that only take the space strictly required.


Regards

--

---
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_3044_787210307.1443957245613
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Sunday, October 4, 2015 at 11:44:48 AM UTC+7, G=
or Nishanov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;pa=
dding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bor=
der-left-style:solid"><div dir=3D"ltr">I see a bit of a mistake, again, in =
my opinion, to embed a scheduler into the language, when you could do it in=
 a library, as Christopher&#39;s paper shows.</div></blockquote><div><br></=
div><div>There is absolutely no embedded scheduler in P0057 and never was. =
</div></div></blockquote><div><br></div><div>Hello Gor. If there is no sche=
duler, I do not understand how await can work. Forgive my ignorance, as I s=
aid above, I do not know to detail. But</div><div>my understanding is that =
if you have a call to await, that state for the suspended coroutine must be=
 kept somewhere. Where? I understand that this state must live somewhere. W=
here is that state held?</div><div><br></div><div><br></div><div>=C2=A0</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>P0057 =
and its predecessors provide syntactic sugar for common async and sync patt=
erns and it is up to the library to decide what meaning to imbue the corout=
ine with.</div></div></blockquote><div>=C2=A0<br></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>I suggest to look at this pr=
esentation:</div><div><br></div><div><a href=3D"http://open-std.org/JTC1/SC=
22/WG21/docs/papers/2014/n4287.pdf" target=3D"_blank" rel=3D"nofollow" onmo=
usedown=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fopen=
-std.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn4287.pdf\46sa\75D\4=
6sntz\0751\46usg\75AFQjCNFV2sRDoffKgvwikfBo54XuRjPl4Q&#39;;return true;" on=
click=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fopen-s=
td.org%2FJTC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn4287.pdf\46sa\75D\46s=
ntz\0751\46usg\75AFQjCNFV2sRDoffKgvwikfBo54XuRjPl4Q&#39;;return true;">http=
://open-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2014/n4287.<wbr>pdf</a></di=
v></div></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div>Another thing that the presentation above hig=
hlights is that the abstraction proposed is unique as it is not just zero-o=
verhead. It=C2=A0is negative overhead :-) . Meaning that for some problems,=
 taking the well-written code that uses functions / callbacks=C2=A0and rewr=
iting it using higher level abstractions, namely,=C2=A0the coroutines as pr=
oposed by PP0057 will result in=C2=A0simpler implementation, smaller object=
 size and faster execution.</div></div></blockquote><div><br></div><div>I d=
o not get yet how it can achieve this negative overhead. Even the coroutine=
s are type erased, as mentioned by Chris&#39; papers. What can be better th=
an having inlinable, reified coroutines? I just do not get it.</div><div>=
=C2=A0</div><div>I have three questions here:<br></div><div><br></div><div>=
1. How is the negative overhead achieved?</div><div>2. This would have nega=
tive overhead *compared* to an implementation with resumable expressions?</=
div><div>3. Do these optimizations are fancy? We have had good inliners for=
 years, but it seems the coroutines from P0057 mandate</div><div>type erasu=
re.</div><div><br></div><div>Sorry if I make any mistakes during my explana=
tion, I am not an expert on this papers, I just happen to understand quite =
well</div><div>Christopher&#39;s metaphor of function objects and I see ver=
y difficult something more performant that non-type erased coroutines</div>=
<div>that only take the space strictly required.</div><div><br></div><div><=
br></div><div>Regards</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&quot; 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_3044_787210307.1443957245613--
------=_Part_3043_1223282699.1443957245613--

.

------=_Part_2958_1914055703.1443957379112
Content-Type: multipart/alternative;
 boundary="----=_Part_2959_139753148.1443957379113"

------=_Part_2959_139753148.1443957379113
Content-Type: text/plain; charset=UTF-8

Oh my english! I write too fast:

3. Do these optimizations are fancy? ----> Are these optimizations fancy?

On Sunday, October 4, 2015 at 6:14:05 PM UTC+7, german...@hubblehome.com
wrote:
>
>
>
> On Sunday, October 4, 2015 at 11:44:48 AM UTC+7, Gor Nishanov wrote:
>>
>> I see a bit of a mistake, again, in my opinion, to embed a scheduler into
>>> the language, when you could do it in a library, as Christopher's paper
>>> shows.
>>>
>>
>> There is absolutely no embedded scheduler in P0057 and never was.
>>
>
> Hello Gor. If there is no scheduler, I do not understand how await can
> work. Forgive my ignorance, as I said above, I do not know to detail. But
> my understanding is that if you have a call to await, that state for the
> suspended coroutine must be kept somewhere. Where? I understand that this
> state must live somewhere. Where is that state held?
>
>
>
>
>> P0057 and its predecessors provide syntactic sugar for common async and
>> sync patterns and it is up to the library to decide what meaning to imbue
>> the coroutine with.
>>
>
>
>> I suggest to look at this presentation:
>>
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4287.pdf
>>
>
>
>> Another thing that the presentation above highlights is that the
>> abstraction proposed is unique as it is not just zero-overhead. It is
>> negative overhead :-) . Meaning that for some problems, taking the
>> well-written code that uses functions / callbacks and rewriting it using
>> higher level abstractions, namely, the coroutines as proposed by PP0057
>> will result in simpler implementation, smaller object size and faster
>> execution.
>>
>
> I do not get yet how it can achieve this negative overhead. Even the
> coroutines are type erased, as mentioned by Chris' papers. What can be
> better than having inlinable, reified coroutines? I just do not get it.
>
> I have three questions here:
>
> 1. How is the negative overhead achieved?
> 2. This would have negative overhead *compared* to an implementation with
> resumable expressions?
> 3. Do these optimizations are fancy? We have had good inliners for years,
> but it seems the coroutines from P0057 mandate
> type erasure.
>
> Sorry if I make any mistakes during my explanation, I am not an expert on
> this papers, I just happen to understand quite well
> Christopher's metaphor of function objects and I see very difficult
> something more performant that non-type erased coroutines
> that only take the space strictly required.
>
>
> Regards
>

--

---
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_2959_139753148.1443957379113
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Oh my english! I write too fast:<div><br></div><div><div>3=
.. Do these optimizations are fancy? ----&gt; Are these optimizations fancy?=
<br></div><br>On Sunday, October 4, 2015 at 6:14:05 PM UTC+7, german...@hub=
blehome.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><br><br>On Sunday, October 4, 2015 at 11:44:48 AM UTC+7, Gor Nishanov =
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"><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;bo=
rder-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:so=
lid"><div dir=3D"ltr">I see a bit of a mistake, again, in my opinion, to em=
bed a scheduler into the language, when you could do it in a library, as Ch=
ristopher&#39;s paper shows.</div></blockquote><div><br></div><div>There is=
 absolutely no embedded scheduler in P0057 and never was. </div></div></blo=
ckquote><div><br></div><div>Hello Gor. If there is no scheduler, I do not u=
nderstand how await can work. Forgive my ignorance, as I said above, I do n=
ot know to detail. But</div><div>my understanding is that if you have a cal=
l to await, that state for the suspended coroutine must be kept somewhere. =
Where? I understand that this state must live somewhere. Where is that stat=
e held?</div><div><br></div><div><br></div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div>P0057 and its predecessors p=
rovide syntactic sugar for common async and sync patterns and it is up to t=
he library to decide what meaning to imbue the coroutine with.</div></div><=
/blockquote><div>=C2=A0<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>I suggest to look at this presentation:</div><div><br><=
/div><div><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4=
287.pdf" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39=
;http://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG=
21%2Fdocs%2Fpapers%2F2014%2Fn4287.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFV=
2sRDoffKgvwikfBo54XuRjPl4Q&#39;;return true;" onclick=3D"this.href=3D&#39;h=
ttp://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21=
%2Fdocs%2Fpapers%2F2014%2Fn4287.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFV2s=
RDoffKgvwikfBo54XuRjPl4Q&#39;;return true;">http://open-std.org/JTC1/SC22/<=
wbr>WG21/docs/papers/2014/n4287.<wbr>pdf</a></div></div></blockquote><div>=
=C2=A0</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>A=
nother thing that the presentation above highlights is that the abstraction=
 proposed is unique as it is not just zero-overhead. It=C2=A0is negative ov=
erhead :-) . Meaning that for some problems, taking the well-written code t=
hat uses functions / callbacks=C2=A0and rewriting it using higher level abs=
tractions, namely,=C2=A0the coroutines as proposed by PP0057 will result in=
=C2=A0simpler implementation, smaller object size and faster execution.</di=
v></div></blockquote><div><br></div><div>I do not get yet how it can achiev=
e this negative overhead. Even the coroutines are type erased, as mentioned=
 by Chris&#39; papers. What can be better than having inlinable, reified co=
routines? I just do not get it.</div><div>=C2=A0</div><div>I have three que=
stions here:<br></div><div><br></div><div>1. How is the negative overhead a=
chieved?</div><div>2. This would have negative overhead *compared* to an im=
plementation with resumable expressions?</div><div>3. Do these optimization=
s are fancy? We have had good inliners for years, but it seems the coroutin=
es from P0057 mandate</div><div>type erasure.</div><div><br></div><div>Sorr=
y if I make any mistakes during my explanation, I am not an expert on this =
papers, I just happen to understand quite well</div><div>Christopher&#39;s =
metaphor of function objects and I see very difficult something more perfor=
mant that non-type erased coroutines</div><div>that only take the space str=
ictly required.</div><div><br></div><div><br></div><div>Regards</div></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&quot; 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_2959_139753148.1443957379113--
------=_Part_2958_1914055703.1443957379112--

.

------=_Part_2563_873033673.1443965197135
Content-Type: multipart/alternative;
 boundary="----=_Part_2564_1053926674.1443965197135"

------=_Part_2564_1053926674.1443965197135
Content-Type: text/plain; charset=UTF-8

On Sunday, October 4, 2015 at 12:01:52 AM UTC-4, Arash Partow wrote:
>
> That said, no single proposal has yet discussed why a compliant
> compiler will never be able to deduce such scenarios without extra
> keywords and rearranging of code - Similar things have been done to
> achieve tail call optimizations, why can this not be done with
> coroutines?
>

.... I don't understand what you mean.

Again, this may just be my ignorance on the details of these coroutine
ideas, but I thought the idea of resumable functions (P0057), at its core,
was the ability to halt the execution of a function (yield) and later
return to where that function's execution was halted (resume). That is, to
my understanding, the core feature.

How could the compiler *deduce* that I want to do that... without giving me
syntax to actually do that (at which point it's not "deduction" anymore)?

You may be confusing P0057 with a pure await/async model that is bound to
CPU threadings and so forth. It's rather lower-level than that. And even
that is not something which is deducible by the compiler, since it very
much affects the apparent behavior of the program.

By contrast, proper tail calls is not apparent behavior. Well, not with
regard to the standard at any rate.

--

---
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_2564_1053926674.1443965197135
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, October 4, 2015 at 12:01:52 AM UTC-4, Arash Par=
tow wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">That said, no single=
 proposal has yet discussed why a compliant
<br>compiler will never be able to deduce such scenarios without extra
<br>keywords and rearranging of code - Similar things have been done to
<br>achieve tail call optimizations, why can this not be done with
<br>coroutines?
<br></blockquote><div><br>... I don&#39;t understand what you mean.<br><br>=
Again, this may just be my ignorance on the details of these coroutine idea=
s, but I thought the idea of resumable functions (P0057), at its core, was =
the ability to halt the execution of a function (yield) and later return to=
 where that function&#39;s execution was halted (resume). That is, to my un=
derstanding, the core feature.<br><br>How could the compiler <i>deduce</i> =
that I want to do that... without giving me syntax to actually do that (at =
which point it&#39;s not &quot;deduction&quot; anymore)?<br><br>You may be =
confusing P0057 with a pure await/async model that is bound to CPU threadin=
gs and so forth. It&#39;s rather lower-level than that. And even that is no=
t something which is deducible by the compiler, since it very much affects =
the apparent behavior of the program.<br><br>By contrast, proper tail calls=
 is not apparent behavior. Well, not with regard to the standard at any rat=
e.<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&quot; 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_2564_1053926674.1443965197135--
------=_Part_2563_873033673.1443965197135--

.

------=_Part_1625_1099703307.1444056124710
Content-Type: multipart/alternative;
 boundary="----=_Part_1626_530967356.1444056124719"

------=_Part_1626_530967356.1444056124719
Content-Type: text/plain; charset=UTF-8

On Sunday, October 4, 2015 at 7:14:05 AM UTC-4, german...@hubblehome.com
wrote:
>
> On Sunday, October 4, 2015 at 11:44:48 AM UTC+7, Gor Nishanov wrote:
>>
>> I see a bit of a mistake, again, in my opinion, to embed a scheduler into
>>> the language, when you could do it in a library, as Christopher's paper
>>> shows.
>>>
>>
>> There is absolutely no embedded scheduler in P0057 and never was.
>>
>
> Hello Gor. If there is no scheduler, I do not understand how await can
> work. Forgive my ignorance, as I said above, I do not know to detail. But
> my understanding is that if you have a call to await, that state for the
> suspended coroutine must be kept somewhere. Where? I understand that this
> state must live somewhere. Where is that state held?
>

After reading the proposal a bit, it's clear that `await` does not actually
"wait" on anything. For the most part, it's a syntactic transformation on
an expression.

The expression that `await` applies to must result in an object that has a
certain interface. And the logic for `await` calls that interface. If there
is any scheduling logic going on, it is in the implementation of that
interface, not in `await` itself.

As such, the storage in question is in the object resulting from the
`await` expression.

And the closest to scheduling that `await` gets is the decision to check if
the value is ready before yielding.

Sorry if I make any mistakes during my explanation, I am not an expert on
> this papers, I just happen to understand quite well
> Christopher's metaphor of function objects and I see very difficult
> something more performant that non-type erased coroutines
> that only take the space strictly required.
>

How much more performant? Is it enough to be worth arguing about? After
all, most things you'll be using await for won't be cheap operations. Will
you actually *notice* any such performance loss?

That's not to say that I much *like* resumable functions as a proposal. I
can't say I look forward to doing a bunch of `await`ing and using
specialized return values just to be able to allow some deeply nested
function perform a `yield` back to the original caller. And that's not even
using threading.

That being said, I noticed one thing about resumable expressions that makes
it a complete deal-breaker for me:

When a resumable function is used in a resumable expression, the definition
> of the function must appear before the end of the translation unit.
>

Um, no. I understand that this requirement is not necessarily recursive.
That is, you don't need the definition of every function the resumable one
calls. However, if the resumable one you call *itself* makes a resumable
call, you will need those definitions. And if they make resumable calls,
you'll need *those* definitions. And so forth.

If it's a choice between forbidding inlining and *forcing* inlining, I'll
accept the overhead of forbidding inlining.

--

---
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_1626_530967356.1444056124719
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sunday, October 4, 2015 at 7:14:05 AM UTC-4, german...@hubblehome.com wr=
ote:<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">On Sunday=
, October 4, 2015 at 11:44:48 AM UTC+7, Gor Nishanov wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(20=
4,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr">=
I see a bit of a mistake, again, in my opinion, to embed a scheduler into t=
he language, when you could do it in a library, as Christopher&#39;s paper =
shows.</div></blockquote><div><br></div><div>There is absolutely no embedde=
d scheduler in P0057 and never was. </div></div></blockquote><div><br></div=
><div>Hello Gor. If there is no scheduler, I do not understand how await ca=
n work. Forgive my ignorance, as I said above, I do not know to detail. But=
</div><div>my understanding is that if you have a call to await, that state=
 for the suspended coroutine must be kept somewhere. Where? I understand th=
at this state must live somewhere. Where is that state held?</div></div></b=
lockquote><div><br>After reading the proposal a bit, it&#39;s clear that `a=
wait` does not actually &quot;wait&quot; on anything. For the most part, it=
&#39;s a syntactic transformation on an expression.<br><br>The expression t=
hat `await` applies to must result in an object that has a certain interfac=
e. And the logic for `await` calls that interface. If there is any scheduli=
ng logic going on, it is in the implementation of that interface, not in `a=
wait` itself.<br><br>As such, the storage in question is in the object resu=
lting from the `await` expression.<br><br>And the closest to scheduling tha=
t `await` gets is the decision to check if the value is ready before yieldi=
ng.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div></div><div>Sorry if I make any mistakes during my explanation, I a=
m not an expert on this papers, I just happen to understand quite well</div=
><div>Christopher&#39;s metaphor of function objects and I see very difficu=
lt something more performant that non-type erased coroutines</div><div>that=
 only take the space strictly required.</div></div></blockquote><div><br>Ho=
w much more performant? Is it enough to be worth arguing about? After all, =
most things you&#39;ll be using await for won&#39;t be cheap operations. Wi=
ll you actually <i>notice</i> any such performance loss?<br><br>That&#39;s =
not to say that I much <i>like</i> resumable functions as a proposal. I can=
&#39;t say I look forward to doing a bunch of `await`ing and using speciali=
zed return values just to be able to allow some deeply nested function perf=
orm a `yield` back to the original caller. And that&#39;s not even using th=
reading.<br><br>That being said, I noticed one thing about resumable expres=
sions that makes it a complete deal-breaker for me: <br><br><blockquote sty=
le=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204);=
 padding-left: 1ex;" class=3D"gmail_quote">When a resumable function is use=
d in a resumable expression, the definition of the function must appear bef=
ore the end of the translation unit.<br></blockquote><br>Um, no. I understa=
nd that this requirement is not necessarily recursive. That is, you don&#39=
;t need the definition of every function the resumable one calls. However, =
if the resumable one you call <i>itself</i> makes a resumable call, you wil=
l need those definitions. And if they make resumable calls, you&#39;ll need=
 <i>those</i> definitions. And so forth.<br><br>If it&#39;s a choice betwee=
n forbidding inlining and <i>forcing</i> inlining, I&#39;ll accept the over=
head of forbidding inlining.<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&quot; 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_1626_530967356.1444056124719--
------=_Part_1625_1099703307.1444056124710--

.

------=_Part_6158_1606441187.1444131243023
Content-Type: multipart/alternative;
 boundary="----=_Part_6159_1670705577.1444131243023"

------=_Part_6159_1670705577.1444131243023
Content-Type: text/plain; charset=UTF-8



How much more performant? Is it enough to be worth arguing about? After
> all, most things you'll be using await for won't be cheap operations. Will
> you actually *notice* any such performance loss?
>

Well this is a usual argument to use "productivity languages". As far as I
know, the definition of performance for C++ is that between C++ and machine
code, we can only choose assembly.
So far, it has been good to me. Boxing is bad, bad, bad. I do not think it
is a good idea in a language abstraction. About the scheduling, not sure,
but I believe what you say for now :).



> When a resumable function is used in a resumable expression, the
> definition of the function must appear before the end of the translation
> unit.
>

There is an example of a boxed generator with separate compilation in the
paper. Doesn't that contradict whay you are claiming?



--

---
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_6159_1670705577.1444131243023
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>=
How much more performant? Is it enough to be worth arguing about? After all=
, most things you&#39;ll be using await for won&#39;t be cheap operations. =
Will you actually <i>notice</i> any such performance loss?<br></div></block=
quote><div><br>Well this is a usual argument to use &quot;productivity lang=
uages&quot;. As far as I know, the definition of performance for C++ is tha=
t between C++ and machine code, we can only choose assembly.<br>So far, it =
has been good to me. Boxing is bad, bad, bad. I do not think it is a good i=
dea in a language abstraction. About the scheduling, not sure, but I believ=
e what you say for now :).<br>=C2=A0<br></div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div>When a resumable function is used in =
a resumable expression, the definition of the function must appear before t=
he end of the translation unit.<br></div></blockquote><div><br>There is an =
example of a boxed generator with separate compilation in the paper. Doesn&=
#39;t that contradict whay you are claiming?<br><br>=C2=A0<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&quot; 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_6159_1670705577.1444131243023--
------=_Part_6158_1606441187.1444131243023--

.

------=_Part_2579_92502196.1444140265107
Content-Type: multipart/alternative;
 boundary="----=_Part_2580_932835893.1444140265107"

------=_Part_2580_932835893.1444140265107
Content-Type: text/plain; charset=UTF-8


>
> How much more performant? Is it enough to be worth arguing about? After
> all, most things you'll be using await for won't be cheap operations. Will
> you actually *notice* any such performance loss?
>

You should not expect any performance loss. When applied to concrete
problems, you should expect Coroutines proposal to be as fast or faster
than equivalent solution using resumable expressions.


> If it's a choice between forbidding inlining and *forcing* inlining, I'll
> accept the overhead of forbidding inlining.
>

If coroutine lifetime is fully enclosed in the lifetime of the calling
function, then we can
1) elide allocation and use a temporary on the stack of the caller
2) replace indirect calls with direct calls and inline as appropriate:

For example:

auto hello(char const* p) {

   while (*p) yield *p++;

}

int main() {

   for (auto c : hello("Hello, world"))

      putchar(c);

}


Should produce the same code as if you had written:

int main() {

   auto p = "Hello, world";

   while (*p) putchar(*p++);

}


--

---
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_2580_932835893.1444140265107
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div>How much more performant=
? Is it enough to be worth arguing about? After all, most things you&#39;ll=
 be using await for won&#39;t be cheap operations. Will you actually <i>not=
ice</i> any such performance loss?<br></div></blockquote><div><br></div><di=
v>You should not expect any performance loss. When applied to concrete prob=
lems, you should expect Coroutines proposal to be as fast or faster than eq=
uivalent solution using resumable expressions.</div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-lef=
t: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bord=
er-left-style: solid;"><div>If it&#39;s a choice between forbidding inlinin=
g and <i>forcing</i> inlining, I&#39;ll accept the overhead of forbidding i=
nlining.<br></div></blockquote><div><br></div><div>If coroutine lifetime is=
 fully enclosed in the lifetime of the calling function,=C2=A0then we can</=
div><div>1) elide allocation and use a temporary on the stack of the caller=
</div><div>2) replace indirect calls with direct calls and inline as approp=
riate:</div><div><br></div><div>For example:</div><div><br></div><div><p><f=
ont color=3D"#0000ff" face=3D"Consolas" size=3D"2"><font color=3D"#0000ff" =
face=3D"Consolas" size=3D"2"><font color=3D"#0000ff" face=3D"Consolas" size=
=3D"2">auto</font></font></font><font face=3D"Consolas" size=3D"2"><font fa=
ce=3D"Consolas" size=3D"2"> hello(</font></font><font color=3D"#0000ff" fac=
e=3D"Consolas" size=3D"2"><font color=3D"#0000ff" face=3D"Consolas" size=3D=
"2"><font color=3D"#0000ff" face=3D"Consolas" size=3D"2">char</font></font>=
</font><font face=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=3D"2=
"> </font></font><font color=3D"#0000ff" face=3D"Consolas" size=3D"2"><font=
 color=3D"#0000ff" face=3D"Consolas" size=3D"2"><font color=3D"#0000ff" fac=
e=3D"Consolas" size=3D"2">const</font></font></font><font face=3D"Consolas"=
 size=3D"2"><font face=3D"Consolas" size=3D"2">* </font></font><font color=
=3D"#808080" face=3D"Consolas" size=3D"2"><font color=3D"#808080" face=3D"C=
onsolas" size=3D"2"><font color=3D"#808080" face=3D"Consolas" size=3D"2">p<=
/font></font></font><font face=3D"Consolas" size=3D"2"><font face=3D"Consol=
as" size=3D"2">) {</font></font></p><font face=3D"Consolas" size=3D"2"><fon=
t face=3D"Consolas" size=3D"2">
</font></font><p><font face=3D"Consolas" size=3D"2"><font face=3D"Consolas"=
 size=3D"2">   </font></font><font color=3D"#0000ff" face=3D"Consolas" size=
=3D"2"><font color=3D"#0000ff" face=3D"Consolas" size=3D"2"><font color=3D"=
#0000ff" face=3D"Consolas" size=3D"2">=C2=A0=C2=A0 while</font></font></fon=
t><font face=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=3D"2"> (*=
</font></font><font color=3D"#808080" face=3D"Consolas" size=3D"2"><font co=
lor=3D"#808080" face=3D"Consolas" size=3D"2"><font color=3D"#808080" face=
=3D"Consolas" size=3D"2">p</font></font></font><font face=3D"Consolas" size=
=3D"2"><font face=3D"Consolas" size=3D"2">) </font></font><font color=3D"#0=
000ff" face=3D"Consolas" size=3D"2"><font color=3D"#0000ff" face=3D"Consola=
s" size=3D"2"><font color=3D"#0000ff" face=3D"Consolas" size=3D"2">yield</f=
ont></font></font><font face=3D"Consolas" size=3D"2"><font face=3D"Consolas=
" size=3D"2"> *</font></font><font color=3D"#808080" face=3D"Consolas" size=
=3D"2"><font color=3D"#808080" face=3D"Consolas" size=3D"2"><font color=3D"=
#808080" face=3D"Consolas" size=3D"2">p</font></font></font><font face=3D"C=
onsolas" size=3D"2"><font face=3D"Consolas" size=3D"2">++;</font></font></p=
><font face=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=3D"2">
<p>}</p>
</font></font><font color=3D"#0000ff" face=3D"Consolas" size=3D"2"><font co=
lor=3D"#0000ff" face=3D"Consolas" size=3D"2"><font color=3D"#0000ff" face=
=3D"Consolas" size=3D"2"></font></font></font><p><font color=3D"#0000ff" fa=
ce=3D"Consolas" size=3D"2"><font color=3D"#0000ff" face=3D"Consolas" size=
=3D"2"><font color=3D"#0000ff" face=3D"Consolas" size=3D"2">int</font></fon=
t></font><font face=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=3D=
"2"> main() {</font></font></p><font face=3D"Consolas" size=3D"2"><font fac=
e=3D"Consolas" size=3D"2">
</font></font><p><font face=3D"Consolas" size=3D"2"><font face=3D"Consolas"=
 size=3D"2">   </font></font><font color=3D"#0000ff" face=3D"Consolas" size=
=3D"2"><font color=3D"#0000ff" face=3D"Consolas" size=3D"2"><font color=3D"=
#0000ff" face=3D"Consolas" size=3D"2">=C2=A0=C2=A0 for</font></font></font>=
<font face=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=3D"2"> (</f=
ont></font><font color=3D"#0000ff" face=3D"Consolas" size=3D"2"><font color=
=3D"#0000ff" face=3D"Consolas" size=3D"2"><font color=3D"#0000ff" face=3D"C=
onsolas" size=3D"2">auto</font></font></font><font face=3D"Consolas" size=
=3D"2"><font face=3D"Consolas" size=3D"2"> c : hello(</font></font><font co=
lor=3D"#a31515" face=3D"Consolas" size=3D"2"><font color=3D"#a31515" face=
=3D"Consolas" size=3D"2"><font color=3D"#a31515" face=3D"Consolas" size=3D"=
2">&quot;Hello, world&quot;</font></font></font><font face=3D"Consolas" siz=
e=3D"2"><font face=3D"Consolas" size=3D"2">)) </font></font></p><font face=
=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=3D"2">
<p>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0putchar(c);</p>
<p>}</p><p><br></p></font></font></div><div>Should produce the same code as=
 if you had written:</div><div><br></div><div><div><p><font color=3D"#0000f=
f" face=3D"Consolas" size=3D"2"><font color=3D"#0000ff" face=3D"Consolas" s=
ize=3D"2"><font color=3D"#0000ff" face=3D"Consolas" size=3D"2">int</font></=
font></font><font face=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=
=3D"2"> main() {</font></font></p><font face=3D"Consolas" size=3D"2"><font =
face=3D"Consolas" size=3D"2">
</font></font><p><font face=3D"Consolas" size=3D"2"><font face=3D"Consolas"=
 size=3D"2">   </font></font><font color=3D"#0000ff" face=3D"Consolas" size=
=3D"2"><font color=3D"#0000ff" face=3D"Consolas" size=3D"2"><font color=3D"=
#0000ff" face=3D"Consolas" size=3D"2">=C2=A0=C2=A0 auto</font></font></font=
><font face=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=3D"2"> p =
=3D </font></font><font color=3D"#a31515" face=3D"Consolas" size=3D"2"><fon=
t color=3D"#a31515" face=3D"Consolas" size=3D"2"><font color=3D"#a31515" fa=
ce=3D"Consolas" size=3D"2">&quot;Hello, world&quot;</font></font></font><fo=
nt face=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=3D"2">;</font>=
</font></p><font face=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=
=3D"2">
</font></font><p><font face=3D"Consolas" size=3D"2"><font face=3D"Consolas"=
 size=3D"2">   </font></font><font color=3D"#0000ff" face=3D"Consolas" size=
=3D"2"><font color=3D"#0000ff" face=3D"Consolas" size=3D"2"><font color=3D"=
#0000ff" face=3D"Consolas" size=3D"2">=C2=A0=C2=A0 while</font></font></fon=
t><font face=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=3D"2"> (*=
p) putchar(*p++);</font></font></p><font face=3D"Consolas" size=3D"2"><font=
 face=3D"Consolas" size=3D"2">
<p>}</p><p><br></p></font></font></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&quot; 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_2580_932835893.1444140265107--
------=_Part_2579_92502196.1444140265107--

.

------=_Part_354_1568678149.1444140311503
Content-Type: multipart/alternative;
 boundary="----=_Part_355_1209397268.1444140311504"

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

On Tuesday, October 6, 2015 at 7:34:03 AM UTC-4, Germ=C3=A1n Diago wrote:
>
> How much more performant? Is it enough to be worth arguing about? After=
=20
>> all, most things you'll be using await for won't be cheap operations. Wi=
ll=20
>> you actually *notice* any such performance loss?
>>
>
> Well this is a usual argument to use "productivity languages". As far as =
I=20
> know, the definition of performance for C++ is that between C++ and machi=
ne=20
> code, we can only choose assembly.
>

Yeah, tell that to iostream.

While that might be a goal of C++, it's not an *overriding* goal. It=20
doesn't automatically pre-empt all other considerations.

So far, it has been good to me. Boxing is bad, bad, bad.
>

Why?

I do not think it is a good idea in a language abstraction. About the=20
> scheduling, not sure, but I believe what you say for now :).
> =20
> =20
>
>> When a resumable function is used in a resumable expression, the=20
>> definition of the function must appear before the end of the translation=
=20
>> unit.
>>
>
> There is an example of a boxed generator with separate compilation in the=
=20
> paper. Doesn't that contradict whay you are claiming?
>

So let me get this straight.

A resumable function, under this design, is inline. However, by making my=
=20
function *not* resumable, I can get the effect of a non-inline resumable=20
function by making the function body actually a lambda (which the compiler=
=20
will deduce is a resumable function), and returning it in some object. And=
=20
if I have allocation needs, I have to explicitly specify them in the body=
=20
of every function that has those needs. And so forth.

Meaning that, in a rather common case, the user has to do a lot of work.=20
Isn't the whole point of a compiler to do that sort of gruntwork *for you*?=
=20
Why not make `resumable` do this "boxing" work for you, and have `inline=20
resumable` do what the current thing suggests? After all, the current=20
`resumable` implies `inline`, so we'd just be making it explicit.

So `inline resumable` means to do what it currently says. And `resumable`=
=20
means to automatically do boxing and so forth. Or if you prefer `resumable`=
=20
to mean the current case, introduce another keyword to have the compiler=20
generate the "boxing" code for you.

Users should not have to do this nonsense manually, especially considering=
=20
how common such code will be.

--=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_355_1209397268.1444140311504
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 6, 2015 at 7:34:03 AM UTC-4, Germ=C3=
=A1n Diago wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div>How much more performant? =
Is it enough to be worth arguing about? After all, most things you&#39;ll b=
e using await for won&#39;t be cheap operations. Will you actually <i>notic=
e</i> any such performance loss?<br></div></blockquote><div><br>Well this i=
s a usual argument to use &quot;productivity languages&quot;. As far as I k=
now, the definition of performance for C++ is that between C++ and machine =
code, we can only choose assembly.<br></div></div></blockquote><div><br>Yea=
h, tell that to iostream.<br><br>While that might be a goal of C++, it&#39;=
s not an <i>overriding</i> goal. It doesn&#39;t automatically pre-empt all =
other considerations.<br><br></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>So far, it has been good to me. Boxing is bad, =
bad, bad.</div></div></blockquote><div><br>Why?<br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>I do not think it is a=
 good idea in a language abstraction. About the scheduling, not sure, but I=
 believe what you say for now :).<br>=C2=A0<br></div><div>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div>When a resumable function is used i=
n a resumable expression, the definition of the function must appear before=
 the end of the translation unit.<br></div></blockquote><div><br>There is a=
n example of a boxed generator with separate compilation in the paper. Does=
n&#39;t that contradict whay you are claiming?<br></div></div></blockquote>=
<div><br>So let me get this straight.<br><br></div>A resumable function, un=
der this design, is inline. However, by making my function <i>not</i> resum=
able, I can get the effect of a non-inline resumable function by making the=
 function body actually a lambda (which the compiler will deduce is a resum=
able function), and returning it in some object. And if I have allocation n=
eeds, I have to explicitly specify them in the body of every function that =
has those needs. And so forth.<br><br>Meaning that, in a rather common case=
, the user has to do a lot of work. Isn&#39;t the whole point of a compiler=
 to do that sort of gruntwork <i>for you</i>? Why not make `resumable` do t=
his &quot;boxing&quot; work for you, and have `inline resumable` do what th=
e current thing suggests? After all, the current `resumable` implies `inlin=
e`, so we&#39;d just be making it explicit.<br><br>So `inline resumable` me=
ans to do what it currently says. And `resumable` means to automatically do=
 boxing and so forth. Or if you prefer `resumable` to mean the current case=
, introduce another keyword to have the compiler generate the &quot;boxing&=
quot; code for you.<br><br>Users should not have to do this nonsense manual=
ly, especially considering how common such code will be.<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&quot; 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_355_1209397268.1444140311504--
------=_Part_354_1568678149.1444140311503--

.

------=_Part_262_1179512238.1444143435719
Content-Type: multipart/alternative;
 boundary="----=_Part_263_1320150312.1444143435719"

------=_Part_263_1320150312.1444143435719
Content-Type: text/plain; charset=UTF-8



On Tuesday, October 6, 2015 at 10:04:25 AM UTC-4, Gor Nishanov wrote:
>
> If it's a choice between forbidding inlining and *forcing* inlining, I'll
>> accept the overhead of forbidding inlining.
>>
>
> If coroutine lifetime is fully enclosed in the lifetime of the calling
> function, then we can
> 1) elide allocation and use a temporary on the stack of the caller
> 2) replace indirect calls with direct calls and inline as appropriate:
>

How exactly does std::experimental::generator<T> accomplish that? How can
the object know that it is contained entirely in this way? After all, the
promise type is what holds the state, and therefore the promise has to
decide whether to statically or dynamically allocate memory, as well as how
to handle the forwarding to the function to be resumed.

Is `generator` a magical compiler-only type, or could a user somehow
implement these optimizations themselves? Or am I misunderstanding
something about how all this works?

--

---
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_263_1320150312.1444143435719
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, October 6, 2015 at 10:04:25 AM UTC-4, =
Gor Nishanov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;p=
adding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bo=
rder-left-style:solid"><div>If it&#39;s a choice between forbidding inlinin=
g and <i>forcing</i> inlining, I&#39;ll accept the overhead of forbidding i=
nlining.<br></div></blockquote><div><br></div><div>If coroutine lifetime is=
 fully enclosed in the lifetime of the calling function,=C2=A0then we can</=
div><div>1) elide allocation and use a temporary on the stack of the caller=
</div><div>2) replace indirect calls with direct calls and inline as approp=
riate:</div></div></blockquote><div><br>How exactly does std::experimental:=
:generator&lt;T&gt; accomplish that? How can the object know that it is con=
tained entirely in this way? After all, the promise type is what holds the =
state, and therefore the promise has to decide whether to statically or dyn=
amically allocate memory, as well as how to handle the forwarding to the fu=
nction to be resumed.<br><br>Is `generator` a magical compiler-only type, o=
r could a user somehow implement these optimizations themselves? Or am I mi=
sunderstanding something about how all this works?<font size=3D"2"><font fa=
ce=3D"Consolas"><br></font></font></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&quot; 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_263_1320150312.1444143435719--
------=_Part_262_1179512238.1444143435719--

.

------=_Part_6045_1744045774.1444147030396
Content-Type: multipart/alternative;
 boundary="----=_Part_6046_333429548.1444147030396"

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



On Tuesday, October 6, 2015 at 7:57:15 AM UTC-7, Nicol Bolas wrote:
>
> How exactly does std::experimental::generator<T> accomplish that? How can=
=20
> the object know that it is contained entirely in this way? After all, the=
=20
> promise type is what holds the state, and therefore the promise has to=20
> decide whether to statically or dynamically allocate memory, as well as h=
ow=20
> to handle the forwarding to the function to be resumed.
>

There are only two magic types in this proposal. coroutine_traits, which=20
let the compiler figure out which promise_type describes the coroutine=20
semantics and coroutine_handle<P> which is synthesized by the compiler to=
=20
allow resumption and destruction of the coroutine.

If you look at the implementation of coroutine_handle in=20
<experimental/resumable>, you will notice the following two members:

void coroutine_handle::resume() { _coro_resume(_Ptr); }

void coroutine_handle::destroy() { _coro_destroy(_Ptr); }

_coro_resume and _coro_destroy are intrinsics that are implemented in our=
=20
optimizer. After inlining, in the main, optimizer will observe the=20
following sequence:

$fp =3D _coro_alloc_elision() ? alloca(_coro_frame_size()) : operator new=
=20
(_coro_frame_size()); // frame size of hello$ coroutine
bla
_coro_resume($fp)
bla
_coro_destroy($fp); <-- here

Now optimizer can reason about the lifetime and also to which function=20
_coro_resume($fp) and _coro_destroy($fp) go.=20
Since in this example, $fp does not escape. Optimizer replaces=20
_coro_alloc_elision with 1, thus, allocation is done via alloca(constant)=
=20
which optimizer makes into a normal automatic variable. _coro_resume and=20
_coro_destroy are replaced with direct calls to hello$resume_coro, which=20
after inlining will lead to what I showed in my previous post.

I talked to Clang implementers and they are planning to add this=20
optimization too. Note that it is explicitly allowed by=20

P0057/[dcl.fct.def.coroutine]/8 A coroutine *may* need to allocate memory=
=20
to store objects with automatic storage duration local
to the coroutine. *If so*, it shall obtain the storage by calling an=20
allocation function (3.7.4.1).
The allocation function=E2=80=99s name is looked up in the scope of the pro=
mise=20
type of the coroutine.
If this lookup fails to find the name, the allocation function=E2=80=99s na=
me is=20
looked up in the global
scope...


In other words, when allocation is needed, here is how the compiler figures=
=20
out what allocation functions to use. But, if hte compiler does not need to=
=20
allocate, it does not have to.

--=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_6046_333429548.1444147030396
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, October 6, 2015 at 7:57:15 AM UTC-7, N=
icol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>How exa=
ctly does std::experimental::generator&lt;<wbr>T&gt; accomplish that? How c=
an the object know that it is contained entirely in this way? After all, th=
e promise type is what holds the state, and therefore the promise has to de=
cide whether to statically or dynamically allocate memory, as well as how t=
o handle the forwarding to the function to be resumed.<br></div></div></blo=
ckquote><div><br></div><div>There are only two magic types in this proposal=
.. coroutine_traits, which let the compiler figure out which promise_type de=
scribes the coroutine semantics and coroutine_handle&lt;P&gt; which is synt=
hesized by the compiler to allow resumption and destruction of the coroutin=
e.</div><div><br></div><div>If you look at the implementation of coroutine_=
handle in &lt;experimental/resumable&gt;, you will notice the following two=
 members:</div><div><br></div><div><font face=3D"Consolas" size=3D"2"><font=
 face=3D"Consolas" size=3D"2"><p>  void coroutine_handle::resume() { _coro_=
resume(_Ptr); }</p>

<p>  void coroutine_handle::destroy() { _coro_destroy(_Ptr); }</p></font></=
font></div><div><br></div><div>_coro_resume and _coro_destroy are intrinsic=
s that are implemented in our optimizer. After inlining, in the main, optim=
izer will observe the following sequence:</div><div><br></div><div>$fp =3D =
_coro_alloc_elision() ? alloca(_coro_frame_size()) : operator new (_coro_fr=
ame_size()); // frame size of hello$ coroutine</div><div>bla</div><div>_cor=
o_resume($fp)</div><div>bla</div><div>_coro_destroy($fp); &lt;-- here</div>=
<div><br></div><div>Now optimizer can reason about the lifetime and also to=
 which function _coro_resume($fp) and _coro_destroy($fp) go. </div><div>Sin=
ce in this example, $fp does not escape. Optimizer replaces _coro_alloc_eli=
sion with 1, thus, allocation is done via alloca(constant) which optimizer =
makes into a=C2=A0normal automatic variable. _coro_resume and _coro_destroy=
 are replaced with direct calls to hello$resume_coro, which after inlining =
will lead to what I showed in my previous post.</div><div><br></div><div>I =
talked to Clang implementers and they are planning to add this optimization=
 too. Note that it is explicitly allowed by </div><div><font face=3D"LMRoma=
n10-Bold" size=3D"3"><font face=3D"LMRoman10-Bold" size=3D"3"><br></font></=
font></div><font face=3D"LMRoman10-Bold" size=3D"3"><font face=3D"LMRoman10=
-Bold" size=3D"3"><p>P0057/[dcl.fct.def.coroutine]/8 A coroutine <strong><f=
ont size=3D"4">may</font></strong> need to allocate memory to store objects=
 with automatic storage duration local<br>to the coroutine. <strong><font s=
ize=3D"4">If so</font></strong>, it shall obtain the storage by calling an =
allocation function (3.7.4.1).<br>The allocation function=E2=80=99s name is=
 looked up in the scope of the promise type of the coroutine.<br>If this lo=
okup fails to find the name, the allocation function=E2=80=99s name is look=
ed up in the global<br>scope...<br></p><font face=3D"LMRoman10-Regular" siz=
e=3D"2"><p align=3D"LEFT"><br></p></font></font></font><div><font size=3D"2=
"><font face=3D"Consolas">In other words, when allocation is needed, here i=
s how the compiler figures out what allocation functions to use. But, if ht=
e=C2=A0compiler does not need to allocate, it does not have to.<br></font><=
/font></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&quot; 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_6046_333429548.1444147030396--
------=_Part_6045_1744045774.1444147030396--

.

------=_Part_6480_746191626.1444152751441
Content-Type: multipart/alternative;
 boundary="----=_Part_6481_565983731.1444152751441"

------=_Part_6481_565983731.1444152751441
Content-Type: text/plain; charset=UTF-8


>
> Why not make `resumable` do this "boxing" work for you, and have `inline
> resumable` do what the current thing suggests?
>

Because you can provide library solutions  for the boxing in the proposals,
without embedding mandatory boxing into the feature.
Just provide a generator<int> and you are done. Nothing prevents you from
giving these library types, that can box, but
it does not *force* you from the beginning.

I cannot see how resumable expressions are worse than await when:

1. can still provide types for boxing on the lib side.
2. it can emulate async from a library.
3. no viral await when refactoring.
4. it does *not* mandate boxing.
5. it can embed member variables. Maybe even relax restrictions for
copy/move as needed in later proposals.
6. does not need a fancy escape analysis that await, as of now, needs, and
is a Microsoft-specific compiler optimization as of today.


Users should not have to do this nonsense manually, especially considering
> how common such code will be.
>

Just providing a library type solves the full problem.

--

---
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_6481_565983731.1444152751441
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Why not make `resumable` do this &quot;boxing&quot; work for you, and h=
ave `inline resumable` do what the current thing suggests?=C2=A0<br></div><=
/blockquote><div><br></div><div>Because you can provide library solutions =
=C2=A0for the boxing in the proposals, without embedding mandatory boxing i=
nto the feature.=C2=A0</div><div>Just provide a generator&lt;int&gt; and yo=
u are done. Nothing prevents you from giving these library types, that can =
box, but</div><div>it does not *force* you from the beginning.</div><div><b=
r></div><div>I cannot see how resumable expressions are worse than await wh=
en:</div><div><br></div><div>1. can still provide types for boxing on the l=
ib side.</div><div>2. it can emulate async from a library.</div><div>3. no =
viral await when refactoring.</div><div>4. it does *not* mandate boxing.</d=
iv><div>5. it can embed member variables. Maybe even relax restrictions for=
 copy/move as needed in later proposals.</div><div>6. does not need a fancy=
 escape analysis that await, as of now, needs, and is a Microsoft-specific =
compiler optimization as of today.</div><div>=C2=A0</div><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Users should not=
 have to do this nonsense manually, especially considering how common such =
code will be.<br></div></blockquote><div><br></div><div>Just providing a li=
brary type solves the full problem.=C2=A0<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&quot; 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_6481_565983731.1444152751441--
------=_Part_6480_746191626.1444152751441--

.

------=_Part_6345_61596373.1444161628182
Content-Type: multipart/alternative;
 boundary="----=_Part_6346_2033837297.1444161628182"

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

On Tuesday, October 6, 2015 at 10:32:31 AM UTC-7, Germ=C3=A1n Diago wrote:
>
> Why not make `resumable` do this "boxing" work for you, and have `inline=
=20
>> resumable` do what the current thing suggests?=20
>>
>
> Because you can provide library solutions  for the boxing in the=20
> proposals, without embedding mandatory boxing into the feature.
>

Germ=C3=A1n:

*On Boilerplate:*

The starting point for my proposal was lambda-*. A lambda that keeps all of=
=20
the objects with automatic storage duration in the body in the lambda=20
function object. I wanted an abstraction that is more fundamental than what=
=20
was offered by earlier await proposals pre N4134 and awaits in other=20
languages, but the one, on top of which I can efficiently build C# like=20
await syntax. After running around with that idea for a month I came to the=
=20
conclusion that when applied to concrete problems, it requires more=20
boilerplate code and does not result in more efficient code. Moreover, in=
=20
those cases where you don't need to allocate your lambda* on the heap and=
=20
can put it on the stack, I could elide heap allocation in the optimizer for=
=20
N4134. Hence, I tabled lambda* until better times.=20

Chris proposal suffers from the same problem as lambda*. It requires you to=
=20
write more code as a user without providing tangible benefit. As I said=20
before, for any concrete problem, you will get the same or more efficient=
=20
code with my proposal than with Chris'es. Thus, there is no justification=
=20
for added complexity.

Look at the async state machine problem which I discussed in the=20
http://wg21.link/N4287. Or look at http://wg21.link/P0055 which explains=20
how await SomeAsyncOp is expanded. Now, compare what does it take to get=20
from await f() in my proposal and await(f()) or f(use_await) in *P0114R0*=
=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0114r0.pdf> to=20
the actual OS call. Abstraction overhead is lower in P0057.

*On Optimizations*

C++ is a language that offers an ability to create zero-overhead=20
abstractions (or negative overhead in case of P0057). However,=20
zero-overhead part comes from the optimizer. When STL was first proposed in=
=20
1994, no compiler in the world could make it efficient. It took more than=
=20
ten years before compilers caught up. Optimization technology is=20
fundamental to C++ abstractions.=20

*Await or Not*

If you look at http://wg21.link/P0054, you will find a section "Exploring=
=20
design space" which sketches out how you can evolve P0057 to add the=20
"magic" so that you don't have to write awaits. However, I am not sure that=
=20
absence of explicit indication of suspend points is a good thing, but, may=
=20
get convinced otherwise in the future.

Cheers,
Gor

--=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_6346_2033837297.1444161628182
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 6, 2015 at 10:32:31 AM UTC-7, Germ=C3=
=A1n Diago wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex=
; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-lef=
t-style: solid;"><div dir=3D"ltr">Why not make `resumable` do this &quot;bo=
xing&quot; work for you, and have `inline resumable` do what the current th=
ing suggests?=C2=A0<br></div></blockquote><div><br></div><div>Because you c=
an provide library solutions =C2=A0for the boxing in the proposals, without=
 embedding mandatory boxing into the feature.</div></div></blockquote><div>=
<br></div><div>Germ=C3=A1n:</div><div><br></div><div><strong>On Boilerplate=
:</strong></div><div><br></div><div>The starting point for my proposal was =
lambda-*. A lambda that keeps all of the objects with automatic storage dur=
ation in the body in the lambda function object. I wanted an abstraction th=
at is more fundamental than what was offered by earlier await proposals pre=
 N4134 and awaits in other languages, but the one, on top of which=C2=A0I c=
an efficiently build C# like await syntax. After running around with that i=
dea for a month I came to the conclusion that when applied to concrete prob=
lems, it requires more boilerplate code and does not result in more efficie=
nt code. Moreover, in those cases where you don&#39;t need to allocate your=
 lambda* on the heap and can put it on the stack, I could elide heap alloca=
tion in the optimizer for N4134. Hence, I tabled lambda* until better times=
.. </div><div><br></div><div>Chris proposal suffers from the same problem as=
 lambda*. It requires you to write more code as a user without providing ta=
ngible benefit. As I said before, for any concrete problem, you will get th=
e same or more efficient code with my proposal than with Chris&#39;es. Thus=
, there is no justification for added complexity.</div><div><br></div><div>=
Look at the async state machine problem which I discussed in the <a href=3D=
"http://wg21.link/N4287">http://wg21.link/N4287</a>. Or look at <a href=3D"=
http://wg21.link/P0055">http://wg21.link/P0055</a>=C2=A0which explains how =
await SomeAsyncOp is expanded. Now, compare what does it take to get from a=
wait f() in my proposal and await(f()) or f(use_await) in <a href=3D"http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0114r0.pdf"><u><font col=
or=3D"#0066cc">P0114R0</font></u></a> to the actual OS call. Abstraction ov=
erhead is lower in P0057.</div><div><br></div><div><u><strong>On Optimizati=
ons</strong></u></div><div><br></div><div>C++ is a language that offers an =
ability to create zero-overhead abstractions (or negative overhead in case =
of P0057). However, zero-overhead part comes from the optimizer. When STL w=
as first proposed in 1994, no compiler in the world could make it efficient=
.. It took more than ten years before compilers caught up. Optimization tech=
nology is fundamental to C++ abstractions. </div><div><br></div><div><stron=
g><u>Await or Not</u></strong></div><div><br></div><div>If you look at <a h=
ref=3D"http://wg21.link/P0054">http://wg21.link/P0054</a>, you will find a =
section=C2=A0&quot;Exploring design space&quot;=C2=A0which sketches out how=
 you can evolve P0057 to add the &quot;magic&quot; so that you don&#39;t ha=
ve to write awaits. However, I am not sure that absence of explicit indicat=
ion of suspend points is a good thing, but, may get convinced otherwise in =
the future.</div><div><br></div><div>Cheers,</div><div>Gor<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&quot; 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_6346_2033837297.1444161628182--
------=_Part_6345_61596373.1444161628182--

.

------=_Part_5649_1756200278.1444182486942
Content-Type: multipart/alternative;
 boundary="----=_Part_5650_79037013.1444182486942"

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



On Tuesday, October 6, 2015 at 1:32:31 PM UTC-4, Germ=C3=A1n Diago wrote:
>
> Why not make `resumable` do this "boxing" work for you, and have `inline=
=20
>> resumable` do what the current thing suggests?=20
>>
>
> Because you can provide library solutions  for the boxing in the=20
> proposals, without embedding mandatory boxing into the feature.=20
> Just provide a generator<int> and you are done. Nothing prevents you from=
=20
> giving these library types, that can box, but
> it does not *force* you from the beginning.
>

Perhaps you misunderstood what I meant when I was talking about "boxing".

I'm not talking about `generator<T>`. I'm talking about the lambda wrapper=
=20
part, with optional allocator and whatnot. Having to write `return=20
[=3D](){<actual function>};` around every resumable function I write is a=
=20
pain that I would rather not have to deal with.

There is absolutely no reason why that boilerplate can't be written by the=
=20
compiler.

I cannot see how resumable expressions are worse than await when:
>

"Worse" is ultimately a matter of opinion. Some restrictions will be=20
considered worse by some people than others.

However, I have to say that Gor Nishanov seems to be winning the argument=
=20
here, since P0057 is being implemented *efficiently*, with all the inlining=
=20
and other simplifications that you claimed was not possible. That was your=
=20
biggest argument against resumable functions, and it turned out to be wrong=
=20
in at least some of the cases. You can try to dismiss the fact that a good=
=20
optimizer made the code equivalent if you like, but that doesn't change the=
=20
fact that optimizer aren't getting worse over time. They're getting *better=
*
..

If there is no objective performance difference between them, then most of=
=20
your case just evaporated. So the only remaining function difference is=20
that P0114 requires explicit "boxing" if your code needs boxing.

If you're going to bring up having to use `await` frequently:

3. no viral await when refactoring.


You say that as though resumable expressions don't have their viral aspects=
=20
too. You can only call a resumable function as part of a resumable context:=
=20
either the calling function is resumable or the expression making that call=
=20
is resumable. Both of these require explicit annotation (except in those=20
cases where the compiler magically works it out for you... somehow).

Oh sure, you won't be using `resumable` like you would `await`, or quite as=
=20
much. But the fact is, you can't call a `resumable` function unless you've=
=20
typed `resumable` somewhere nearby. So you still have to annotate up your=
=20
call graph. And you still can't call coroutines of either kind without some=
=20
kind of annotation.

So I'm not seeing how that's a point in resumable expression's favor.

Oh, and I have to agree with P0054: I think I'd rather see awaiting and=20
yielding happen than for them to be implicit. Also, I seem to recall that=
=20
an explicit `await` was something that the `expected` guys wanted to be=20
able to key off of. So there is the power to be able to use the=20
functionality for other uses.

--=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_5650_79037013.1444182486942
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, October 6, 2015 at 1:32:31 PM UTC-4, G=
erm=C3=A1n Diago wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><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">Why not =
make `resumable` do this &quot;boxing&quot; work for you, and have `inline =
resumable` do what the current thing suggests?=C2=A0<br></div></blockquote>=
<div><br></div><div>Because you can provide library solutions =C2=A0for the=
 boxing in the proposals, without embedding mandatory boxing into the featu=
re.=C2=A0</div><div>Just provide a generator&lt;int&gt; and you are done. N=
othing prevents you from giving these library types, that can box, but</div=
><div>it does not *force* you from the beginning.</div></div></blockquote><=
div><br>Perhaps you misunderstood what I meant when I was talking about &qu=
ot;boxing&quot;.<br><br>I&#39;m not talking about `generator&lt;T&gt;`. I&#=
39;m talking about the lambda wrapper part, with optional allocator and wha=
tnot. Having to write `return [=3D](){&lt;actual function&gt;};` around eve=
ry resumable function I write is a pain that I would rather not have to dea=
l with.<br><br>There is absolutely no reason why that boilerplate can&#39;t=
 be written by the compiler.<br><br></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><div>I cannot see how resumable exp=
ressions are worse than await when:</div></div></blockquote><div><br>&quot;=
Worse&quot; is ultimately a matter of opinion. Some restrictions will be co=
nsidered worse by some people than others.<br><br>However, I have to say th=
at Gor Nishanov seems to be winning the argument here, since P0057 is being=
 implemented <i>efficiently</i>, with all the inlining and other simplifica=
tions that you claimed was not possible. That was your biggest argument aga=
inst resumable functions, and it turned out to be wrong in at least some of=
 the cases. You can try to dismiss the fact that a good optimizer made the =
code equivalent if you like, but that doesn&#39;t change the fact that opti=
mizer aren&#39;t getting worse over time. They&#39;re getting <i>better</i>=
..<br><br>If there is no objective performance difference between them, then=
 most of your case just evaporated. So the only remaining function differen=
ce is that P0114 requires explicit &quot;boxing&quot; if your code needs bo=
xing.<br><br>If you&#39;re going to bring up having to use `await` frequent=
ly:<br></div><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">=
3. no viral await when refactoring.</blockquote><div><br>You say that as th=
ough resumable expressions don&#39;t have their viral aspects too. You can =
only call a resumable function as part of a resumable context: either the c=
alling function is resumable or the expression making that call is resumabl=
e. Both of these require explicit annotation (except in those cases where t=
he compiler magically works it out for you... somehow).<br><br>Oh sure, you=
 won&#39;t be using `resumable` like you would `await`, or quite as much. B=
ut the fact is, you can&#39;t call a `resumable` function unless you&#39;ve=
 typed `resumable` somewhere nearby. So you still have to annotate up your =
call graph. And you still can&#39;t call coroutines of either kind without =
some kind of annotation.<br><br>So I&#39;m not seeing how that&#39;s a poin=
t in resumable expression&#39;s favor.<br><br>Oh, and I have to agree with =
P0054: I think I&#39;d rather see awaiting and yielding happen than for the=
m to be implicit. Also, I seem to recall that an explicit `await` was somet=
hing that the `expected` guys wanted to be able to key off of. So there is =
the power to be able to use the functionality for other uses.<br></div></di=
v>

<p></p>

-- <br />
<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 <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_5650_79037013.1444182486942--
------=_Part_5649_1756200278.1444182486942--

.

------=_Part_5372_74874860.1444183813808
Content-Type: multipart/alternative;
 boundary="----=_Part_5373_1238479447.1444183813808"

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

On Tuesday, October 6, 2015 at 1:32:31 PM UTC-4, Germ=C3=A1n Diago wrote:
>
>
> 2. it can emulate async from a library.
>

Just FYI: `async` doesn't exist, and hasn't existed in the resumable=20
functions proposals for quite some time.

--=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_5373_1238479447.1444183813808
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, October 6, 2015 at 1:32:31 PM UTC-4, Germ=C3=
=A1n Diago wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><br><div>2. it can emulate async from a library.</div></div></blockquot=
e><div><br>Just FYI: `async` doesn&#39;t exist, and hasn&#39;t existed in t=
he resumable functions proposals for quite some time.</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&quot; 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_5373_1238479447.1444183813808--
------=_Part_5372_74874860.1444183813808--

.

------=_Part_6775_2052637602.1444189489269
Content-Type: multipart/alternative;
 boundary="----=_Part_6776_775534366.1444189489269"

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



On Wednesday, October 7, 2015 at 9:10:14 AM UTC+7, Nicol Bolas wrote:
>
> On Tuesday, October 6, 2015 at 1:32:31 PM UTC-4, Germ=C3=A1n Diago wrote:
>>
>>
>> 2. it can emulate async from a library.
>>
>
> Just FYI: `async` doesn't exist, and hasn't existed in the resumable=20
> functions proposals for quite some time.
>

Sorry, I meant await. But it is good that it is disappeared.=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_6776_775534366.1444189489269
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, October 7, 2015 at 9:10:14 AM UTC+7,=
 Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">On Tuesday, October 6, 2015 at 1:32:31 PM UTC-4, Germ=C3=A1n Diago wr=
ote:<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"><br><div>2. it=
 can emulate async from a library.</div></div></blockquote><div><br>Just FY=
I: `async` doesn&#39;t exist, and hasn&#39;t existed in the resumable funct=
ions proposals for quite some time.</div></div></blockquote><div><br>Sorry,=
 I meant await. But it is good that it is disappeared. <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&quot; 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_6776_775534366.1444189489269--
------=_Part_6775_2052637602.1444189489269--

.

------=_Part_7278_352397507.1444190434220
Content-Type: multipart/alternative;
 boundary="----=_Part_7279_1889214159.1444190434221"

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



El mi=C3=A9rcoles, 7 de octubre de 2015, 3:00:28 (UTC+7), Gor Nishanov escr=
ibi=C3=B3:
>
> On Tuesday, October 6, 2015 at 10:32:31 AM UTC-7, Germ=C3=A1n Diago wrote=
:
>>
>> Why not make `resumable` do this "boxing" work for you, and have `inline=
=20
>>> resumable` do what the current thing suggests?=20
>>>
>>
>> Because you can provide library solutions  for the boxing in the=20
>> proposals, without embedding mandatory boxing into the feature.
>>
>
> Germ=C3=A1n:
>
> *On Boilerplate:*
>
=20

> Chris proposal suffers from the same problem as lambda*. It requires you=
=20
> to write more code as a user without providing tangible benefit.
>

Well, I am not sure the boilerplate that you are talking about. Chris=20
proposal is more "low-level". But you can build on top of that everything
that can be done by await in a library, can't you? Also, implementing=20
resumable expressions in a compiler cannot be hard,
and you can reuse existing technology from optimizer: basically the=20
inliner. =20
In the C++ style of things, where we are starting to use things as=20
"Regular" objects and so on, I see the funcion object metaphor very clear.
But I also see some benefits, please, tell me how this is compared to your=
=20
proposal, because I understand Chris proposal better, so I could be wrong:

About the negative overhead: I saw your slides and it is impressive, I must=
=20
admit. But:=20

1. I do not understand how negative overhead is achieved.
2. That negative overhead *cannot* be achieved by Chris proposal, is it=20
something exclusive of your implementation?


In Chris proposal:

1. You can also implement await. It is a matter of providing a library=20
solution.
2. You can embed as member a resumable expression.
3. You do not need yield keyword, actually, yield is reified in an object,=
=20
and simple to implement. You could save also this state somewhere, as an=20
object. Can this be done=20
by await?
4. What is the space overhead of await? As far as I know, resumable=20
expressions just need the strictly necessary space. To eliminate this=20
overhead we need optimizations? Can be done?
5. Reified resumable expressions (no type erased) -- is this possible in=20
your proposal? I think it was mentioned before that the optimizer can=20
discover this and do inlining when needed, anyway?
Can also do escape analysis.
6. Type erased resumable expressions. This is an opt-in in Chris proposal.=
=20
It is a must in your proposal, right? You rely on the optimizer for=20
eliminating this overhead?




Look at the async state machine problem which I discussed in the=20
http://wg21.link/N4287. Or look at http://wg21.link/P0055 which explains=20
how await SomeAsyncOp is expanded. Now, compare what does it take to get=20
from await f() in my proposal and await(f()) or f(use_await) in *P0114R0*=
=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0114r0.pdf> to=20
the actual OS call. Abstraction overhead is lower in P0057.

*On Optimizations*

C++ is a language that offers an ability to create zero-overhead=20
abstractions (or negative overhead in case of P0057). However,=20
zero-overhead part comes from the optimizer. When STL was first proposed in=
=20
1994, no compiler in the world could make it efficient. It took more than=
=20
ten years before compilers caught up. Optimization technology is=20
fundamental to C++ abstractions.=20

*Await or Not*

If you look at http://wg21.link/P0054, you will find a section "Exploring=
=20
design space" which sketches out how you can evolve P0057 to add the=20
"magic" so that you don't have to write awaits. However, I am not sure that=
=20
absence of explicit indication of suspend points is a good thing, but, may=
=20
get convinced otherwise in the future.

Cheers,
Gor

--=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_7279_1889214159.1444190434221
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>El mi=C3=A9rcoles, 7 de octubre de 2015, 3:00:28 (UTC+7), Gor Nisha=
nov  escribi=C3=B3:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">On Tuesday, October 6, 2015 at 10:32:31 AM UTC-7, Germ=C3=A1n Diago w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;pa=
dding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bor=
der-left-style:solid"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" st=
yle=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"><div dir=3D"ltr">Wh=
y not make `resumable` do this &quot;boxing&quot; work for you, and have `i=
nline resumable` do what the current thing suggests?=C2=A0<br></div></block=
quote><div><br></div><div>Because you can provide library solutions =C2=A0f=
or the boxing in the proposals, without embedding mandatory boxing into the=
 feature.</div></div></blockquote><div><br></div><div>Germ=C3=A1n:</div><di=
v><br></div><div><b>On Boilerplate:</b></div></div></blockquote><div>=C2=A0=
</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>Ch=
ris proposal suffers from the same problem as lambda*. It requires you to w=
rite more code as a user without providing tangible benefit.</div></div></b=
lockquote><div><br>Well, I am not sure the boilerplate that you are talking=
 about. Chris proposal is more &quot;low-level&quot;. But you can build on =
top of that everything<br>that can be done by await in a library, can&#39;t=
 you? Also, implementing resumable expressions in a compiler cannot be hard=
,<br>and you can reuse existing technology from optimizer: basically the in=
liner.=C2=A0 <br>In the C++ style of things, where we are starting to use t=
hings as &quot;Regular&quot; objects and so on, I see the funcion object me=
taphor very clear.<br>But I also see some benefits, please, tell me how thi=
s is compared to your proposal, because I understand Chris proposal better,=
 so I could be wrong:<br><br>About the negative overhead: I saw your slides=
 and it is impressive, I must admit. But: <br><br>1. I do not understand ho=
w negative overhead is achieved.<br>2. That negative overhead *cannot* be a=
chieved by Chris proposal, is it something exclusive of your implementation=
?<br><br><br>In Chris proposal:<br><br>1. You can also implement await. It =
is a matter of providing a library solution.<br>2. You can embed as member =
a resumable expression.<br>3. You do not need yield keyword, actually, yiel=
d is reified in an object, and simple to implement. You could save also thi=
s state somewhere, as an object. Can this be done <br>by await?<br>4. What =
is the space overhead of await? As far as I know, resumable expressions jus=
t need the strictly necessary space. To eliminate this overhead we need opt=
imizations? Can be done?<br>5. Reified resumable expressions (no type erase=
d) -- is this possible in your proposal? I think it was mentioned before th=
at the optimizer can discover this and do inlining when needed, anyway?<br>=
Can also do escape analysis.<br>6. Type erased resumable expressions. This =
is an opt-in in Chris proposal. It is a must in your proposal, right? You r=
ely on the optimizer for eliminating this overhead?<br><br><br><br></div><d=
iv dir=3D"ltr"><br><div>Look at the async state machine problem which I dis=
cussed in the <a href=3D"http://wg21.link/N4287" target=3D"_blank" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\75http=
%3A%2F%2Fwg21.link%2FN4287\46sa\75D\46sntz\0751\46usg\75AFQjCNGd5AKPNNo0D2e=
U5bR9S1oVur6i_Q&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.g=
oogle.com/url?q\75http%3A%2F%2Fwg21.link%2FN4287\46sa\75D\46sntz\0751\46usg=
\75AFQjCNGd5AKPNNo0D2eU5bR9S1oVur6i_Q&#39;;return true;">http://wg21.link/N=
4287</a>. Or look at <a href=3D"http://wg21.link/P0055" target=3D"_blank" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q=
\75http%3A%2F%2Fwg21.link%2FP0055\46sa\75D\46sntz\0751\46usg\75AFQjCNGpBejv=
-GXczYPJHk9I8ZIAruL2Eg&#39;;return true;" onclick=3D"this.href=3D&#39;http:=
//www.google.com/url?q\75http%3A%2F%2Fwg21.link%2FP0055\46sa\75D\46sntz\075=
1\46usg\75AFQjCNGpBejv-GXczYPJHk9I8ZIAruL2Eg&#39;;return true;">http://wg21=
..link/P0055</a>=C2=A0which explains how await SomeAsyncOp is expanded. Now,=
 compare what does it take to get from await f() in my proposal and await(f=
()) or f(use_await) in <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/do=
cs/papers/2015/p0114r0.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-st=
d.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0114r0.pdf\46sa\75D\46=
sntz\0751\46usg\75AFQjCNFNqLe77pF1GzVb5bWPiWymVXUZFw&#39;;return true;" onc=
lick=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.ope=
n-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fp0114r0.pdf\46sa\75=
D\46sntz\0751\46usg\75AFQjCNFNqLe77pF1GzVb5bWPiWymVXUZFw&#39;;return true;"=
><u><font color=3D"#0066cc">P0114R0</font></u></a> to the actual OS call. A=
bstraction overhead is lower in P0057.</div><div><br></div><div><u><b>On Op=
timizations</b></u></div><div><br></div><div>C++ is a language that offers =
an ability to create zero-overhead abstractions (or negative overhead in ca=
se of P0057). However, zero-overhead part comes from the optimizer. When ST=
L was first proposed in 1994, no compiler in the world could make it effici=
ent. It took more than ten years before compilers caught up. Optimization t=
echnology is fundamental to C++ abstractions. </div><div><br></div><div><b>=
<u>Await or Not</u></b></div><div><br></div><div>If you look at <a href=3D"=
http://wg21.link/P0054" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwg21.link%2FP005=
4\46sa\75D\46sntz\0751\46usg\75AFQjCNE_Xd2ORz68C1M17EI_rNWVeEc5Ww&#39;;retu=
rn true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A=
%2F%2Fwg21.link%2FP0054\46sa\75D\46sntz\0751\46usg\75AFQjCNE_Xd2ORz68C1M17E=
I_rNWVeEc5Ww&#39;;return true;">http://wg21.link/P0054</a>, you will find a=
 section=C2=A0&quot;Exploring design space&quot;=C2=A0which sketches out ho=
w you can evolve P0057 to add the &quot;magic&quot; so that you don&#39;t h=
ave to write awaits. However, I am not sure that absence of explicit indica=
tion of suspend points is a good thing, but, may get convinced otherwise in=
 the future.</div><div><br></div><div>Cheers,</div><div>Gor<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&quot; 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_7279_1889214159.1444190434221--
------=_Part_7278_352397507.1444190434220--

.

------=_Part_116_884720068.1444190968623
Content-Type: multipart/alternative;
 boundary="----=_Part_117_805488869.1444190968624"

------=_Part_117_805488869.1444190968624
Content-Type: text/plain; charset=UTF-8



3. no viral await when refactoring.
>
>
> You say that as though resumable expressions don't have their viral
> aspects too. You can only call a resumable function as part of a resumable
> context: either the calling function is resumable or the expression making
> that call is resumable. Both of these require explicit annotation (except
> in those cases where the compiler magically works it out for you...
> somehow).
>
> Oh sure, you won't be using `resumable` like you would `await`, or quite
> as much. But the fact is, you can't call a `resumable` function unless
> you've typed `resumable` somewhere nearby. So you still have to annotate up
> your call graph. And you still can't call coroutines of either kind without
> some kind of annotation.
>

I think that comparison is simply no honest: if you put await 7 levels down
the stack, you need to decorate all the way up with await. For resumable,
you would need to do it in the 7th level only, and you
would not need to refactor the rest of the code. That is 7 vs 1
refactoring. Needless to say the reusability problem that Chris exposes in
the paper: you cannot reuse algorithms, for example,
with await. You cannot have member variables with await either, right?
These are all tangible benefits from having a function object as a
representation.


>
> So I'm not seeing how that's a point in resumable expression's favor.
>

You can see it: Imagine a deep stack of calls. How much refactoring do you
need in each of the proposals? Imagine code reuse: resumable expressions
can reuse code.
We cannot say the same about await *unless* I missed something. In the C++
style, I think resumable functions are more well behaved than await, in the
sense that
it is just a function object, you know what it is doing, you could make it
(maybe in future proposals) copyable, movable, you know the representation:
jump point + strictly needed data.
I think the resumable expressions proposal puts the bar very high to the
rest of the proposals, because besides its benefits, you can also implement
what other proposals are proposing.



>
> Oh, and I have to agree with P0054: I think I'd rather see awaiting and
> yielding happen than for them to be implicit.
>

For me, implicit yielding is precisely what a non-object based yield does.
In Chris proposal, a yielder is an object you could pass around.
On top of that you could make more abstractions. He got it right. He did
not hide anything that prevents any functionality.

I see Gor's proposal powerful also but I think it is hiding too much stuff,
but the point is not that actually, the point is that you can do
what that proposal does on top of resumable expressions, unless I am
misunderstanding something.


>
>
>

--

---
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_117_805488869.1444190968624
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br><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"><bloc=
kquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex" class=3D"gmail_quote">3. no viral await when refacto=
ring.</blockquote><div><br>You say that as though resumable expressions don=
&#39;t have their viral aspects too. You can only call a resumable function=
 as part of a resumable context: either the calling function is resumable o=
r the expression making that call is resumable. Both of these require expli=
cit annotation (except in those cases where the compiler magically works it=
 out for you... somehow).<br><br>Oh sure, you won&#39;t be using `resumable=
` like you would `await`, or quite as much. But the fact is, you can&#39;t =
call a `resumable` function unless you&#39;ve typed `resumable` somewhere n=
earby. So you still have to annotate up your call graph. And you still can&=
#39;t call coroutines of either kind without some kind of annotation.<br></=
div></div></blockquote><div><br>I think that comparison is simply no honest=
: if you put await 7 levels down the stack, you need to decorate all the wa=
y up with await. For resumable, you would need to do it in the 7th level on=
ly, and you<br>would not need to refactor the rest of the code. That is 7 v=
s 1 refactoring. Needless to say the reusability problem that Chris exposes=
 in the paper: you cannot reuse algorithms, for example,<br>with await. You=
 cannot have member variables with await either, right? These are all tangi=
ble benefits from having a function object as a representation.<br>=C2=A0<b=
r></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>=
<br>So I&#39;m not seeing how that&#39;s a point in resumable expression&#3=
9;s favor.<br></div></div></blockquote><div><br>You can see it: Imagine a d=
eep stack of calls. How much refactoring do you need in each of the proposa=
ls? Imagine code reuse: resumable expressions can reuse code. <br>We cannot=
 say the same about await *unless* I missed something. In the C++ style, I =
think resumable functions are more well behaved than await, in the sense th=
at<br>it is just a function object, you know what it is doing, you could ma=
ke it (maybe in future proposals) copyable, movable, you know the represent=
ation: jump point + strictly needed data.<br>I think the resumable expressi=
ons proposal puts the bar very high to the rest of the proposals, because b=
esides its benefits, you can also implement<br>what other proposals are pro=
posing.<br><br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div><br>Oh, and I have to agree with P0054: I think I&#3=
9;d rather see awaiting and yielding happen than for them to be implicit.<b=
r></div></div></blockquote><div><br>For me, implicit yielding is precisely =
what a non-object based yield does. In Chris proposal, a yielder is an obje=
ct you could pass around.<br>On top of that you could make more abstraction=
s. He got it right. He did not hide anything that prevents any functionalit=
y.<br><br>I see Gor&#39;s proposal powerful also but I think it is hiding t=
oo much stuff, but the point is not that actually, the point is that you ca=
n do<br>what that proposal does on top of resumable expressions, unless I a=
m misunderstanding something.<br>=C2=A0<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div><br>=C2=A0</div></div></blockquote=
>

<p></p>

-- <br />
<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 <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_117_805488869.1444190968624--
------=_Part_116_884720068.1444190968623--

.

------=_Part_0_1413399998.1444191428285
Content-Type: multipart/alternative;
 boundary="----=_Part_1_1446400807.1444191428287"

------=_Part_1_1446400807.1444191428287
Content-Type: text/plain; charset=UTF-8



> *Await or Not*
>
> If you look at http://wg21.link/P0054, you will find a section "Exploring
> design space" which sketches out how you can evolve P0057 to add the
> "magic" so that you don't have to write awaits. However, I am not sure that
> absence of explicit indication of suspend points is a good thing, but, may
> get convinced otherwise in the future.
>
>
Would this make other code reusable as Chris proposal? That would be a good
thing then. Because if you want to be explicit, you do not need to infect
things with await everywhere up the stack.
I favor this, sure.

--

---
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_1_1446400807.1444191428287
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><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><b><u>Await or Not</u></b></div><div><br></div><div>If you lo=
ok at <a href=3D"http://wg21.link/P0054" target=3D"_blank" rel=3D"nofollow"=
 onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2=
Fwg21.link%2FP0054\46sa\75D\46sntz\0751\46usg\75AFQjCNE_Xd2ORz68C1M17EI_rNW=
VeEc5Ww&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.co=
m/url?q\75http%3A%2F%2Fwg21.link%2FP0054\46sa\75D\46sntz\0751\46usg\75AFQjC=
NE_Xd2ORz68C1M17EI_rNWVeEc5Ww&#39;;return true;">http://wg21.link/P0054</a>=
, you will find a section=C2=A0&quot;Exploring design space&quot;=C2=A0whic=
h sketches out how you can evolve P0057 to add the &quot;magic&quot; so tha=
t you don&#39;t have to write awaits. However, I am not sure that absence o=
f explicit indication of suspend points is a good thing, but, may get convi=
nced otherwise in the future.</div><div><br></div></div></blockquote><div><=
br>Would this make other code reusable as Chris proposal? That would be a g=
ood thing then. Because if you want to be explicit, you do not need to infe=
ct things with await everywhere up the stack.<br>I favor this, sure. <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&quot; 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_1_1446400807.1444191428287--
------=_Part_0_1413399998.1444191428285--

.

------=_Part_637_1122649585.1444228746758
Content-Type: multipart/alternative;
 boundary="----=_Part_638_1451834436.1444228746759"

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

On Wednesday, October 7, 2015 at 12:09:28 AM UTC-4, Germ=C3=A1n Diago wrote=
:
>
> 3. no viral await when refactoring.
>>
>>
>> You say that as though resumable expressions don't have their viral=20
>> aspects too. You can only call a resumable function as part of a resumab=
le=20
>> context: either the calling function is resumable or the expression maki=
ng=20
>> that call is resumable. Both of these require explicit annotation (excep=
t=20
>> in those cases where the compiler magically works it out for you...=20
>> somehow).
>>
>> Oh sure, you won't be using `resumable` like you would `await`, or quite=
=20
>> as much. But the fact is, you can't call a `resumable` function unless=
=20
>> you've typed `resumable` somewhere nearby. So you still have to annotate=
 up=20
>> your call graph. And you still can't call coroutines of either kind with=
out=20
>> some kind of annotation.
>>
>
> I think that comparison is simply no honest: if you put await 7 levels=20
> down the stack, you need to decorate all the way up with await.
>

The way `await` works is that it halts the current function and returns=20
control to the calling function in such a way that the calling function can=
=20
resume it later.

Therefore, the only reason you would need to "put await 7 levels down the=
=20
stack" is if you want every function in that call graph to halt when the=20
top-most function does, and thus return control to the caller "7 levels=20
down". Correct?

If so:
=20

> For resumable, you would need to do it in the 7th level only, and you
> would not need to refactor the rest of the code.
>

That's not true.

A function marked `resumable` can *only be called* from a resumable=20
context. This is either another function marked `resumable` or from an=20
expression marked `resumable`.

So this is illegal:

resumable int level3()
{
  return 5;
}

int level2()
{
  return level3(); //Cannot call a resumeable function here.
}

Therefore, *every one of those 7 levels* is going to have to be a=20
`resumable` function. So every one of those levels will have to mark their=
=20
signature with `resumable`. Any code that calls into any one of those 7=20
levels will have to mark each use of them with `resumable`, or will=20
themselves have to be coroutines.

So yes, it's just as viral. Only it's worse, because not only do you have=
=20
to mark them `resumable`, they *must be inline*.

The only saving grace you get is that the proposal allows automatic=20
deduction of resumeable functions. But not everywhere; only in template=20
code and lambdas. So normal functions don't provide this feature.

That is 7 vs 1 refactoring. Needless to say the reusability problem that=20
> Chris exposes in the paper: you cannot reuse algorithms, for example,=20
>
with await.
>

That helps demonstrate the viral nature of resumable expressions. If I call=
=20
an algorithm that internally does an implicitly resumable operation, then=
=20
that algorithm internally becomes a coroutine. It becomes resumable.

Which means... I now *must* call that algorithm instantiation from a=20
resumable context. So either my function itself is `resumable`, or I have=
=20
to say `resumable for_each(...)`.

This doesn't invalidate your point, namely that algorithms will deduce how=
=20
to properly be `resumable` for their contents. The exact suspend/resume=20
points will not be defined by the writer of the algorithm, but by the=20
functions the algorithm actually calls. And there is value to that.

At this point, that is basically the only advantage of resumable=20
expressions. It's a non-trivial thing to be sure, but I don't see anything=
=20
about resumable functions that would prevent you from addressing these=20
concerns there.

What resumable functions lack relative to resumable expressions are two=20
things:

1) A way for a function to effectively force the caller to become a=20
coroutine (implicit await).

2) A way for the caller of a function to *reverse* the implicit `await` of=
=20
a function call (that's what `resumable` applied to expressions does).

These features are all it takes to allow for the kind of template code=20
reuse you're talking about. Though it does make it slightly more=20
inconvenient than the resumable expressions model, since RE coroutines=20
don't have return type requirements.

But neither of these is *impossible* with the resumable functions model.=20
It's simply a matter of finding the best way to add those features in.

And of deciding if we want them at all (that's not necessarily a given).

You cannot have member variables with await either, right?
>

I don't know what you mean by this.
=20

> These are all tangible benefits from having a function object as a=20
> representation.
>

.... huh? Those benefits have nothing to do with "having a function object=
=20
as a representation." Those benefits come from having to declare whether a=
=20
function is a coroutine at the function level, rather than in the=20
function's implementation.

So I'm not seeing how that's a point in resumable expression's favor.
>>
>
> You can see it: Imagine a deep stack of calls. How much refactoring do yo=
u=20
> need in each of the proposals? Imagine code reuse: resumable expressions=
=20
> can reuse code.
>

Code reuse in template functions, perhaps. Code reuse elsewhere? Not so=20
much.
=20

> We cannot say the same about await *unless* I missed something. In the C+=
+=20
> style, I think resumable functions are more well behaved than await, in t=
he=20
> sense that
> it is just a function object, you know what it is doing, you could make i=
t=20
> (maybe in future proposals) copyable, movable, you know the representatio=
n:=20
> jump point + strictly needed data.
> I think the resumable expressions proposal puts the bar very high to the=
=20
> rest of the proposals, because besides its benefits, you can also impleme=
nt
> what other proposals are proposing.
>

Yes, you could implement resumable functions on top of resumable=20
expressions. But that doesn't prove resumable expressions are better. Not=
=20
does it prove that anything you could build atop resumable expressions=20
cannot also be built atop resumable functions.

The thing is that there is one really important fact that cannot be gotten=
=20
around.

Resumable functions are a pretty-well proven concept. We have multiple=20
implementations of them, apparently. We have experience in implementing=20
them, with an evaluation of optimization opportunities. We have actual=20
standard wording for it.

Can you tell me that resumable expressions have anywhere *near* the field=
=20
experience?

--=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_638_1451834436.1444228746759
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wednesday, October 7, 2015 at 12:09:28 AM UTC-4, Germ=C3=A1n Diago wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><blockquote style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quot=
e">3. no viral await when refactoring.</blockquote><div><br>You say that as=
 though resumable expressions don&#39;t have their viral aspects too. You c=
an only call a resumable function as part of a resumable context: either th=
e calling function is resumable or the expression making that call is resum=
able. Both of these require explicit annotation (except in those cases wher=
e the compiler magically works it out for you... somehow).<br><br>Oh sure, =
you won&#39;t be using `resumable` like you would `await`, or quite as much=
.. But the fact is, you can&#39;t call a `resumable` function unless you&#39=
;ve typed `resumable` somewhere nearby. So you still have to annotate up yo=
ur call graph. And you still can&#39;t call coroutines of either kind witho=
ut some kind of annotation.<br></div></div></blockquote><div><br>I think th=
at comparison is simply no honest: if you put await 7 levels down the stack=
, you need to decorate all the way up with await.</div></blockquote><div><b=
r>The way `await` works is that it halts the current function and returns c=
ontrol to the calling function in such a way that the calling function can =
resume it later.<br><br>Therefore, the only reason you would need to &quot;=
put await 7 levels down the stack&quot; is if you want every function in th=
at call graph to halt when the top-most function does, and thus return cont=
rol to the caller &quot;7 levels down&quot;. Correct?<br><br>If so:<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>For resumable, y=
ou would need to do it in the 7th level only, and you<br>would not need to =
refactor the rest of the code.</div></blockquote><div><br>That&#39;s not tr=
ue.<br><br>A function marked `resumable` can <i>only be called</i> from a r=
esumable context. This is either another function marked `resumable` or fro=
m an expression marked `resumable`.<br><br>So this is illegal:<br><br><div =
class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border=
-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wr=
ap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #000;" class=3D"styled-by-prettify">resumable </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> level3</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">5</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> level2</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> level3</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">//Cannot call a resumeable function here.</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span></div></code></div><br>Therefore, <i>every one=
 of those 7 levels</i> is going to have to be a `resumable` function. So ev=
ery one of those levels will have to mark their signature with `resumable`.=
 Any code that calls into any one of those 7 levels will have to mark each =
use of them with `resumable`, or will themselves have to be coroutines.<br>=
<br>So yes, it&#39;s just as viral. Only it&#39;s worse, because not only d=
o you have to mark them `resumable`, they <i>must be inline</i>.<br><br>The=
 only saving grace you get is that the proposal allows automatic deduction =
of resumeable functions. But not everywhere; only in template code and lamb=
das. So normal functions don&#39;t provide this feature.<br><br></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>That is 7 vs 1 refactoring. Ne=
edless to say the reusability problem that Chris exposes in the paper: you =
cannot reuse algorithms, for example,=C2=A0</div></blockquote><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div>with await.</div></blockquote><div><br=
>That helps demonstrate the viral nature of resumable expressions. If I cal=
l an algorithm that internally does an implicitly resumable operation, then=
 that algorithm internally becomes a coroutine. It becomes resumable.<br><b=
r>Which means... I now <i>must</i> call that algorithm instantiation from a=
 resumable context. So either my function itself is `resumable`, or I have =
to say `resumable for_each(...)`.<br><br>This doesn&#39;t invalidate your p=
oint, namely that algorithms will deduce how to properly be `resumable` for=
 their contents. The exact suspend/resume points will not be defined by the=
 writer of the algorithm, but by the functions the algorithm actually calls=
.. And there is value to that.<br><br>At this point, that is basically the o=
nly advantage of resumable expressions. It&#39;s a non-trivial thing to be =
sure, but I don&#39;t see anything about resumable functions that would pre=
vent you from addressing these concerns there.<br><br>What resumable functi=
ons lack relative to resumable expressions are two things:<br><br>1) A way =
for a function to effectively force the caller to become a coroutine (impli=
cit await).<br><br>2) A way for the caller of a function to <i>reverse</i> =
the implicit `await` of a function call (that&#39;s what `resumable` applie=
d to expressions does).<br><br>These features are all it takes to allow for=
 the kind of template code reuse you&#39;re talking about. Though it does m=
ake it slightly more inconvenient than the resumable expressions model, sin=
ce RE coroutines don&#39;t have return type requirements.<br><br>But neithe=
r of these is <i>impossible</i> with the resumable functions model. It&#39;=
s simply a matter of finding the best way to add those features in.<br><br>=
And of deciding if we want them at all (that&#39;s not necessarily a given)=
..<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>You cannot=
 have member variables with await either, right?</div></blockquote><div><br=
>I don&#39;t know what you mean by this.<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div>These are all tangible benefits from havin=
g a function object as a representation.</div></blockquote><div><br>... huh=
? Those benefits have nothing to do with &quot;having a function object as =
a representation.&quot; Those benefits come from having to declare whether =
a function is a coroutine at the function level, rather than in the functio=
n&#39;s implementation.<br><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div> </div><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>So I&#39;m not seeing how that&#39;s a point in resumable expression&=
#39;s favor.<br></div></div></blockquote><div><br>You can see it: Imagine a=
 deep stack of calls. How much refactoring do you need in each of the propo=
sals? Imagine code reuse: resumable expressions can reuse code.<br></div></=
blockquote><div><br>Code reuse in template functions, perhaps. Code reuse e=
lsewhere? Not so much.<br>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div>We cannot say the same about await *unless* I missed something=
.. In the C++ style, I think resumable functions are more well behaved than =
await, in the sense that<br>it is just a function object, you know what it =
is doing, you could make it (maybe in future proposals) copyable, movable, =
you know the representation: jump point + strictly needed data.<br>I think =
the resumable expressions proposal puts the bar very high to the rest of th=
e proposals, because besides its benefits, you can also implement<br>what o=
ther proposals are proposing.<br></div></blockquote><div><br>Yes, you could=
 implement resumable functions on top of resumable expressions. But that do=
esn&#39;t prove resumable expressions are better. Not does it prove that an=
ything you could build atop resumable expressions cannot also be built atop=
 resumable functions.<br><br>The thing is that there is one really importan=
t fact that cannot be gotten around.<br><br>Resumable functions are a prett=
y-well proven concept. We have multiple implementations of them, apparently=
.. We have experience in implementing them, with an evaluation of optimizati=
on opportunities. We have actual standard wording for it.<br><br>Can you te=
ll me that resumable expressions have anywhere <i>near</i> the field experi=
ence?</div>

<p></p>

-- <br />
<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 <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_638_1451834436.1444228746759--
------=_Part_637_1122649585.1444228746758--

.

------=_Part_204_674066700.1444231318942
Content-Type: multipart/alternative;
 boundary="----=_Part_205_1539282392.1444231318943"

------=_Part_205_1539282392.1444231318943
Content-Type: text/plain; charset=UTF-8


Actually, I misunderstood two things about resumable expressions, both of
which lead me to believe that P0114 is *broken*. Though not irreparably.

*1) Implicit resumable deduction.*

Apparently, implicit resumable deduction happens more often than I thought.
It happens on `inline` functions, member functions in class definitions,
and so forth. Indeed, pretty much the only place where resumable deduction
is not implicit... is in normal functions in .cpp files.

Which leads to breakage #1:

//Some header file.
inline int a_func()
{
  return 5;
}

inline int b_func()
{
  break resumable;
  return 5;
}

//Some cpp file.

static void func()
{
  auto x = a_func() + b_func();
  internal_global_var += x;
}

void caller()
{
  func();
}

OK, where will the compile error point? Well, the compile error will cite
the first line of `func`. Which seems OK. You're calling a resumable
function from a non-resumable context, and the function isn't inline, so it
won't be implicitly deduced. That sounds legitimate.

But wait: what happens if you stick `inline` in front of `func`? It's a
static function, so making it `inline` seems harmless (though silly). Yet
suddenly... the error moves. Now it points at `caller`.

Why? The last time anyone mentioned `resumable` was 2 function levels below
`caller`, and in a completely different file. All because someone thought
they'd help the compiler out with inlining by (mis)using the `inline`
keyword.

The distance between where the last `resumable` was and where the improper
use of a resumable function call is (ie: where the error actually happened)
should be exactly one. That is, one call. The compiler should be able to
point at the call, and the user should be able to see, *from the call
itself*, that this function can't be called in this way.

I should not have to look at the implementation of your code, and the code
you call, ad-infinitium, before I'm able to decide whether and/or how I can
call your function.

If the question is this: should it be possible to *accidentally* write a
coroutine by calling a coroutine? My answer to that should be "only if the
caller can easily see that they've done so." And the only way to do that is
to put something in the function *signature* that says "hey, I'm a
coroutine; if you call me, so are you."

For resumable expressions, that's spelled `resumable`. And therefore, every
resumable function ought to be *explicitly* tagged as such.

Of course, taking away implicit `resumable` deduction breaks the marquee
feature of resumable expressions: the ability for templates to become
coroutines based on what template parameters they're given.

I don't care. The downsides of this approach are not worth the advantages.

`resumable` may not be "viral". But it is just as infectious as await. And
a silent infection is far more pernicious than a noisy one.

*2) Implicit `resumable` deduction oversight.*

I must assume that this is an oversight. Otherwise, the proposal makes no
sense.

The proposal states that a function is implicitly resumable if it calls
`break resumable` or calls any resumable function. *Period*.

What about calling a resumable function within a resumable expression? IE:
`resumable auto x = resumable_func()`. No exception is listed for this;
calling `resumable_func` makes the calling function resumable, period. And
if it's not in an implicitly resumable deduction context, it is a compile
error.

I have to assume that this was simply a mistake. That the section on
implicit deduction was meant to have allowances for resumable expressions,
that any functions called in such an expression effectively don't count.
Otherwise, *main itself* will have to be resumable if you call any
resumable function.

--

---
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_205_1539282392.1444231318943
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>Actually, I misunderstood two things about resumable e=
xpressions, both of which lead me to believe that P0114 is <i>broken</i>. T=
hough not irreparably.<br><br><u><b>1) Implicit resumable deduction.</b></u=
><br><br>Apparently, implicit resumable deduction happens more often than I=
 thought. It happens on `inline` functions, member functions in class defin=
itions, and so forth. Indeed, pretty much the only place where resumable de=
duction is not implicit... is in normal functions in .cpp files.<br><br>Whi=
ch leads to breakage #1:<br><br><div class=3D"prettyprint" style=3D"backgro=
und-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #800;" class=3D"=
styled-by-prettify">//Some header file.</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">inline</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> a_func</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #066;" class=3D"styled-by-prettify">5</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">inline</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> b_func</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">break</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> resumable</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">5</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><sp=
an style=3D"color: #800;" class=3D"styled-by-prettify">//Some cpp file.</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">static</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> func</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> x </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a_f=
unc</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> b_func</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>=C2=A0 internal_global_var </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">+=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">ca=
ller</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 func</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span></div></code></div><br>OK,=
 where will the compile error point? Well, the compile error will cite the =
first line of `func`. Which seems OK. You&#39;re calling a resumable functi=
on from a non-resumable context, and the function isn&#39;t inline, so it w=
on&#39;t be implicitly deduced. That sounds legitimate.<br><br>But wait: wh=
at happens if you stick `inline` in front of `func`? It&#39;s a static func=
tion, so making it `inline` seems harmless (though silly). Yet suddenly... =
the error moves. Now it points at `caller`.<br><br>Why? The last time anyon=
e mentioned `resumable` was 2 function levels below `caller`, and in a comp=
letely different file. All because someone thought they&#39;d help the comp=
iler out with inlining by (mis)using the `inline` keyword.<br><br>The dista=
nce between where the last `resumable` was and where the improper use of a =
resumable function call is (ie: where the error actually happened) should b=
e exactly one. That is, one call. The compiler should be able to point at t=
he call, and the user should be able to see, <i>from the call itself</i>, t=
hat this function can&#39;t be called in this way.<br><br>I should not have=
 to look at the implementation of your code, and the code you call, ad-infi=
nitium, before I&#39;m able to decide whether and/or how I can call your fu=
nction.<br><br>If the question is this: should it be possible to <i>acciden=
tally</i> write a coroutine by calling a coroutine? My answer to that shoul=
d be &quot;only if the caller can easily see that they&#39;ve done so.&quot=
; And the only way to do that is to put something in the function <i>signat=
ure</i> that says &quot;hey, I&#39;m a coroutine; if you call me, so are yo=
u.&quot;<br><br>For resumable expressions, that&#39;s spelled `resumable`. =
And therefore, every resumable function ought to be <i>explicitly</i> tagge=
d as such.<br><br>Of course, taking away implicit `resumable` deduction bre=
aks the marquee feature of resumable expressions: the ability for templates=
 to become coroutines based on what template parameters they&#39;re given.<=
br><br>I don&#39;t care. The downsides of this approach are not worth the a=
dvantages.<br><br>`resumable` may not be &quot;viral&quot;. But it is just =
as infectious as await. And a silent infection is far more pernicious than =
a noisy one.<br><br><b><u>2) Implicit `resumable` deduction oversight.</u><=
/b><br><br>I must assume that this is an oversight. Otherwise, the proposal=
 makes no sense.<br><br>The proposal states that a function is implicitly r=
esumable if it calls `break resumable` or calls any resumable function. <i>=
Period</i>.<br><br>What about calling a resumable function within a resumab=
le expression? IE: `resumable auto x =3D resumable_func()`. No exception is=
 listed for this; calling `resumable_func` makes the calling function resum=
able, period. And if it&#39;s not in an implicitly resumable deduction cont=
ext, it is a compile error.<br><br>I have to assume that this was simply a =
mistake. That the section on implicit deduction was meant to have allowance=
s for resumable expressions, that any functions called in such an expressio=
n effectively don&#39;t count. Otherwise, <i>main itself</i> will have to b=
e resumable if you call any resumable function.<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&quot; 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_205_1539282392.1444231318943--
------=_Part_204_674066700.1444231318942--

.

------=_Part_7595_1022848722.1444232265172
Content-Type: multipart/alternative;
 boundary="----=_Part_7596_406258332.1444232265173"

------=_Part_7596_406258332.1444232265173
Content-Type: text/plain; charset=UTF-8



>
> Therefore, the only reason you would need to "put await 7 levels down the
> stack" is if you want every function in that call graph to halt when the
> top-most function does, and thus return control to the caller "7 levels
> down". Correct?
>
> If so:
>
>
>> For resumable, you would need to do it in the 7th level only, and you
>> would not need to refactor the rest of the code.
>>
>
> That's not true.
>

As I understood it, maybe I am wrong, the function will suspend inside.


>
> A function marked `resumable` can *only be called* from a resumable
> context. This is either another function marked `resumable` or from an
> expression marked `resumable`.
>
> So this is illegal:
>
> resumable int level3()
> {
>   return 5;
> }
>
> int level2()
> {
>   return level3(); //Cannot call a resumeable function here.
> }
>
> Therefore, *every one of those 7 levels* is going to have to be a
> `resumable` function. So every one of those levels will have to mark their
> signature with `resumable`. Any code that calls into any one of those 7
> levels will have to mark each use of them with `resumable`, or will
> themselves have to be coroutines.
>
>

> So yes, it's just as viral. Only it's worse, because not only do you have
> to mark them `resumable`, they *must be inline*.
>
> I am not sure about this limitation. I will take a look again.



> The only saving grace you get is that the proposal allows automatic
> deduction of resumeable functions. But not everywhere; only in template
> code and lambdas. So normal functions don't provide this feature.
>

Now I understand why it works. I did not catch this at first.


>
> That is 7 vs 1 refactoring. Needless to say the reusability problem that
>> Chris exposes in the paper: you cannot reuse algorithms, for example,
>>
> with await.
>>
>
> That helps demonstrate the viral nature of resumable expressions. If I
> call an algorithm that internally does an implicitly resumable operation,
> then that algorithm internally becomes a coroutine. It becomes resumable.
>

Yes. True. Though, still more reusable than await in this regard.


>
> Which means... I now *must* call that algorithm instantiation from a
> resumable context. So either my function itself is `resumable`, or I have
> to say `resumable for_each(...)`.
>
> This doesn't invalidate your point, namely that algorithms will deduce how
> to properly be `resumable` for their contents. The exact suspend/resume
> points will not be defined by the writer of the algorithm, but by the
> functions the algorithm actually calls. And there is value to that.
>

Agree.


>
> At this point, that is basically the only advantage of resumable
> expressions. It's a non-trivial thing to be sure, but I don't see anything
> about resumable functions that would prevent you from addressing these
> concerns there.
>
> What resumable functions lack relative to resumable expressions are two
> things:
>
> 1) A way for a function to effectively force the caller to become a
> coroutine (implicit await).
>
> 2) A way for the caller of a function to *reverse* the implicit `await`
> of a function call (that's what `resumable` applied to expressions does).
>
> These features are all it takes to allow for the kind of template code
> reuse you're talking about. Though it does make it slightly more
> inconvenient than the resumable expressions model, since RE coroutines
> don't have return type requirements.
>



> But neither of these is *impossible* with the resumable functions model.
> It's simply a matter of finding the best way to add those features in.
>

Would be nice to have those.


>
> And of deciding if we want them at all (that's not necessarily a given).
>
> You cannot have member variables with await either, right?
>>
>
I mean a member variable that holds a resumable expression, you can have
that, it is a function object.
Can this be done with resumable functions? As far as I understand, but
again, you seem
to understand the proposal better than me, you can only store the result,
but not the object itself.



>
> I don't know what you mean by this.
>
>
>> These are all tangible benefits from having a function object as a
>> representation.
>>
>
> If you have a function object, we understand how to save it, reified
(non-type erased) and how to extend that to
a copyable, movable object when it makes sense. That is what I meant.


> ... huh? Those benefits have nothing to do with "having a function object
> as a representation." Those benefits come from having to declare whether a
> function is a coroutine at the function level, rather than in the
> function's implementation.
>


> Code reuse in template functions, perhaps. Code reuse elsewhere? Not so
> much.
>

All the STL is not a small thing to dismiss... Not to mention all the
template libs there are in the wild.


Yes, you could implement resumable functions on top of resumable
> expressions. But that doesn't prove resumable expressions are better. Not
> does it prove that anything you could build atop resumable expressions
> cannot also be built atop resumable functions.
>

Maybe it is me only, but I find resumable expressions so easy to translate,
in my head, to what it really is.
I cannot say the same about await. It has its merits also, sure, but
resumable expressions seem simpler to me,
and everything else seems to be composable on top of it.


Can you tell me that resumable expressions have anywhere *near* the field
> experience?
>

 Well, the closest thing we can have is creating function objects with
stackless
coroutines: http://www.boost.org/doc/libs/1_59_0/doc/html/boost_asio/overview/core/coroutine.html

That is a function object with resumable feature. I think what a resumable
expression does can fit in my head
the same way a lambda fits.
I cannot say the same when I reason about await. At least not so easily.
And I am still not convinced about
cannot hold it as an object (am I right?) you can only get its result, and
the fact that you must type-erase it
(sure, there are optimizations for that, but for now they are in MS
compiler only?).

Thank you very much for your feedback, it made me understand a few points I
was wrong about.


--

---
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_7596_406258332.1444232265173
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><br>=
Therefore, the only reason you would need to &quot;put await 7 levels down =
the stack&quot; is if you want every function in that call graph to halt wh=
en the top-most function does, and thus return control to the caller &quot;=
7 levels down&quot;. Correct?<br><br>If so:<br>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div>For resumable, you would need to do it in the =
7th level only, and you<br>would not need to refactor the rest of the code.=
</div></blockquote><div><br>That&#39;s not true.<br></div></blockquote><div=
><br></div><div>As I understood it, maybe I am wrong, the function will sus=
pend inside.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div><br>A function marked `resumable` can <i>only be called</i> from=
 a resumable context. This is either another function marked `resumable` or=
 from an expression marked `resumable`.<br><br>So this is illegal:<br><br><=
div style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187=
);border-style:solid;border-width:1px;word-wrap:break-word"><code><div><spa=
n style=3D"color:#000">resumable </span><span style=3D"color:#008">int</spa=
n><span style=3D"color:#000"> level3</span><span style=3D"color:#660">()</s=
pan><span style=3D"color:#000"><br></span><span style=3D"color:#660">{</spa=
n><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">r=
eturn</span><span style=3D"color:#000"> </span><span style=3D"color:#066">5=
</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br></=
span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br><br>=
</span><span style=3D"color:#008">int</span><span style=3D"color:#000"> lev=
el2</span><span style=3D"color:#660">()</span><span style=3D"color:#000"><b=
r></span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=
=C2=A0 </span><span style=3D"color:#008">return</span><span style=3D"color:=
#000"> level3</span><span style=3D"color:#660">();</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#800">//Cannot call a resumeable func=
tion here.</span><span style=3D"color:#000"><br></span><span style=3D"color=
:#660">}</span><span style=3D"color:#000"><br></span></div></code></div><br=
>Therefore, <i>every one of those 7 levels</i> is going to have to be a `re=
sumable` function. So every one of those levels will have to mark their sig=
nature with `resumable`. Any code that calls into any one of those 7 levels=
 will have to mark each use of them with `resumable`, or will themselves ha=
ve to be coroutines.<br><br></div></blockquote><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div>So yes, it&#39;s just as viral. Only=
 it&#39;s worse, because not only do you have to mark them `resumable`, the=
y <i>must be inline</i>.<br><br></div></blockquote><div>I am not sure about=
 this limitation. I will take a look again.</div><div><br></div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>The only saving gra=
ce you get is that the proposal allows automatic deduction of resumeable fu=
nctions. But not everywhere; only in template code and lambdas. So normal f=
unctions don&#39;t provide this feature.<br></div></blockquote><div><br></d=
iv><div>Now I understand why it works. I did not catch this at first.</div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div>That is 7 vs 1 refactoring. =
Needless to say the reusability problem that Chris exposes in the paper: yo=
u cannot reuse algorithms, for example,=C2=A0</div></blockquote><blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div>with await.</div></blockquote><div><br>Th=
at helps demonstrate the viral nature of resumable expressions. If I call a=
n algorithm that internally does an implicitly resumable operation, then th=
at algorithm internally becomes a coroutine. It becomes resumable.<br></div=
></blockquote><div><br></div><div>Yes. True. Though, still more reusable th=
an await in this regard.</div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div><br>Which means... I now <i>must</i> call that algori=
thm instantiation from a resumable context. So either my function itself is=
 `resumable`, or I have to say `resumable for_each(...)`.<br><br>This doesn=
&#39;t invalidate your point, namely that algorithms will deduce how to pro=
perly be `resumable` for their contents. The exact suspend/resume points wi=
ll not be defined by the writer of the algorithm, but by the functions the =
algorithm actually calls. And there is value to that.<br></div></blockquote=
><div><br></div><div>Agree.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div><br>At this point, that is basically the only adva=
ntage of resumable expressions. It&#39;s a non-trivial thing to be sure, bu=
t I don&#39;t see anything about resumable functions that would prevent you=
 from addressing these concerns there.<br><br>What resumable functions lack=
 relative to resumable expressions are two things:<br><br>1) A way for a fu=
nction to effectively force the caller to become a coroutine (implicit awai=
t).<br><br>2) A way for the caller of a function to <i>reverse</i> the impl=
icit `await` of a function call (that&#39;s what `resumable` applied to exp=
ressions does).<br><br>These features are all it takes to allow for the kin=
d of template code reuse you&#39;re talking about. Though it does make it s=
lightly more inconvenient than the resumable expressions model, since RE co=
routines don&#39;t have return type requirements.<br></div></blockquote><di=
v><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div>But neither of these is <i>impossible</i> with the resumable functions =
model. It&#39;s simply a matter of finding the best way to add those featur=
es in.<br></div></blockquote><div><br></div><div>Would be nice to have thos=
e.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>=
<br>And of deciding if we want them at all (that&#39;s not necessarily a gi=
ven).<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>You cannot =
have member variables with await either, right?</div></blockquote></blockqu=
ote><div><br></div><div>I mean a member variable that holds a resumable exp=
ression, you can have that, it is a function object.</div><div>Can this be =
done with resumable functions? As far as I understand, but again, you seem<=
/div><div>to understand the proposal better than me, you can only store the=
 result, but not the object itself.</div><div><br></div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div><br>I don&#39;t know what y=
ou mean by this.<br>=C2=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>These are all tangible benefits from having a function object as a repres=
entation.</div></blockquote><div><br></div></blockquote><div>If you have a =
function object, we understand how to save it, reified (non-type erased) an=
d how to extend that to</div><div>a copyable, movable object when it makes =
sense. That is what I meant.</div><div>=C2=A0</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div>... huh? Those benefits have nothing to do with &=
quot;having a function object as a representation.&quot; Those benefits com=
e from having to declare whether a function is a coroutine at the function =
level, rather than in the function&#39;s implementation.<br></div></blockqu=
ote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div></di=
v><div>Code reuse in template functions, perhaps. Code reuse elsewhere? Not=
 so much.</div></blockquote><div><br></div><div>All the STL is not a small =
thing to dismiss... Not to mention all the template libs there are in the w=
ild.</div><div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div>Yes, you could implement resumable functions on top of res=
umable expressions. But that doesn&#39;t prove resumable expressions are be=
tter. Not does it prove that anything you could build atop resumable expres=
sions cannot also be built atop resumable functions.<br></div></blockquote>=
<div><br></div><div>Maybe it is me only, but I find resumable expressions s=
o easy to translate, in my head, to what it really is.</div><div>I cannot s=
ay the same about await. It has its merits also, sure, but resumable expres=
sions seem simpler to me,</div><div>and everything else seems to be composa=
ble on top of it.</div><div>=C2=A0</div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div>Can you tell me that resumable expressions ha=
ve anywhere <i>near</i> the field experience?</div></blockquote><div><br></=
div><div>=C2=A0Well, the closest thing we can have is creating function obj=
ects with stackless coroutines:=C2=A0http://www.boost.org/doc/libs/1_59_0/d=
oc/html/boost_asio/overview/core/coroutine.html</div><div><br></div><div>Th=
at is a function object with resumable feature. I think what a resumable ex=
pression does can fit in my head</div><div>the same way a lambda fits.</div=
><div>I cannot say the same when I reason about await. At least not so easi=
ly. And I am still not convinced about</div><div>cannot hold it as an objec=
t (am I right?) you can only get its result, and the fact that you must typ=
e-erase it</div><div>(sure, there are optimizations for that, but for now t=
hey are in MS compiler only?).</div><div><br></div><div>Thank you very much=
 for your feedback, it made me understand a few points I was wrong about.</=
div><div>=C2=A0</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&quot; 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_7596_406258332.1444232265173--
------=_Part_7595_1022848722.1444232265172--

.

------=_Part_29_25111370.1444239108439
Content-Type: multipart/alternative;
 boundary="----=_Part_30_1347966130.1444239108439"

------=_Part_30_1347966130.1444239108439
Content-Type: text/plain; charset=UTF-8

German:

If you noticed the theme of my answers to your questions was to move you
away from feature list style comparison and take a look at how it is
reduced to practice.

Alex Stepanov said many insightful things and one of them was: "I still
believe in abstraction, but now I know that one ends with abstraction, not
starts with it. I learned that one has to adapt abstractions to reality and
not the other way around." (
http://web.archive.org/web/20071120015600/http://www.research.att.com/~bs/hopl-almost-final.pdf page
18).

I suggested earlier to take some concrete example, such as tcp_reader.
Write it both ways and analyze from three angles.

1) how much code a user has to write to use this abstraction to solve the
problem
2) how much code a library/framework developer has to write to support this
abstraction
3) what is the abstraction penalty. How many (after optimization)
instructions need to get executed to get from the abstraction to the
hardware.

I believe approaching the comparisons in this way, will help you discover
the answers to the questions you seek.

*On hidden magic:*

Coroutine proposal is similar to a range-base-for. A compiler does the
syntactic sugar. The magic is an idea of iterable that allows a compiler to
communicate with the library.

Similarly, with coroutine proposal, the magic that gets you
zero/negative-overhead is in an idea of awaitable. You do the magic
yourself. You can find samples of "negative-overhead" awaitable in the
slides http://wg21.link/N4287. Also http://wg21.link/P0055 shows how
this magic can be extended via CompletionToken technique to any template
library that models their API after the networking library.

The transformation that compiler does is specified in
http://wg21.link/P0057.

Cheers,
Gor

--

---
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_30_1347966130.1444239108439
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>German:</div><div><br></div><div>If you noticed the t=
heme of my answers to your questions was to move you away from feature list=
 style comparison and take a look=C2=A0at=C2=A0how it is reduced to practic=
e.</div><div><br></div><div>Alex Stepanov said many insightful things and o=
ne of=C2=A0them was: &quot;I still believe in abstraction, but now I know t=
hat one ends with abstraction, not starts with it. I learned that one has t=
o adapt abstractions to reality and not the other way around.&quot; (<a hre=
f=3D"http://web.archive.org/web/20071120015600/http://www.research.att.com/=
~bs/hopl-almost-final.pdf">http://web.archive.org/web/20071120015600/http:/=
/www.research.att.com/~bs/hopl-almost-final.pdf</a>=C2=A0page 18).</div><di=
v><br></div><div>I suggested earlier to take some concrete example, such as=
 tcp_reader. Write it both ways and analyze from three angles. </div><div><=
br></div><div>1) how much code a user has to write to use this abstraction =
to solve the problem</div><div>2) how much code=C2=A0a library/framework=C2=
=A0developer has to write to support this abstraction</div><div>3) what is =
the abstraction penalty. How=C2=A0many (after optimization) instructions ne=
ed to get executed to get from the abstraction to the hardware.</div><div><=
br></div><div>I believe approaching the comparisons in this way, will help =
you discover the answers to the questions you seek.</div><div><br></div><di=
v><strong>On hidden magic:</strong></div><div><br></div><div>Coroutine prop=
osal is similar to a=C2=A0range-base-for. A compiler does the syntactic sug=
ar. The magic is an idea of iterable that allows a compiler to communicate =
with the library.</div><div><br></div><div>Similarly, with coroutine propos=
al, the magic that gets you zero/negative-overhead is in an idea of awaitab=
le. You do the magic yourself. You can find samples of &quot;negative-overh=
ead&quot; awaitable in=C2=A0the slides <a href=3D"http://wg21.link/N4287">h=
ttp://wg21.link/N4287</a>. Also <a href=3D"http://wg21.link/P0055">http://w=
g21.link/P0055</a> shows how this=C2=A0magic can be=C2=A0extended=C2=A0via =
CompletionToken technique=C2=A0to any=C2=A0template library that models the=
ir API after the=C2=A0networking library.</div><div><br></div><div>The tran=
sformation that compiler does is specified in=C2=A0=C2=A0<a href=3D"http://=
wg21.link/P0057">http://wg21.link/P0057</a>.</div><div><br></div><div>Cheer=
s,</div><div>Gor</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&quot; 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_30_1347966130.1444239108439--
------=_Part_29_25111370.1444239108439--

.

------=_Part_338_1950419799.1444369784974
Content-Type: multipart/alternative;
 boundary="----=_Part_339_1766442511.1444369784974"

------=_Part_339_1766442511.1444369784974
Content-Type: text/plain; charset=UTF-8



On Thursday, October 8, 2015 at 12:31:48 AM UTC+7, Gor Nishanov wrote:
>
> German:
>
> If you noticed the theme of my answers to your questions was to move you
> away from feature list style comparison and take a look at how it is
> reduced to practice.
>
> Alex Stepanov said many insightful things and one of them was: "I still
> believe in abstraction, but now I know that one ends with abstraction, not
> starts with it. I learned that one has to adapt abstractions to reality and
> not the other way around." (
> http://web.archive.org/web/20071120015600/http://www.research.att.com/~bs/hopl-almost-final.pdf page
> 18).
>

Well, I agree that you accumulated a good deal of experience during the
implementation. Noone can negate that. And evidence shows that, for your
test cases,
the negative overhead seems impressive.


> *On hidden magic:*
>
> Coroutine proposal is similar to a range-base-for. A compiler does the
> syntactic sugar. The magic is an idea of iterable that allows a compiler to
> communicate with the library.
>
> That is nice, because I really thought there was a scheduler embedded in
some way, but this stays on the lib side, right?



> Similarly, with coroutine proposal, the magic that gets you
> zero/negative-overhead is in an idea of awaitable. You do the magic
> yourself. You can find samples of "negative-overhead" awaitable in the
> slides http://wg21.link/N4287. Also http://wg21.link/P0055 shows how
> this magic can be extended via CompletionToken technique to any template
> library that models their API after the networking library.
>
>
The transformation that compiler does is specified in
> http://wg21.link/P0057.
>
>
Given all this, I see your proposal as a nice candidate also, though you
already know my preference and why. Basically:

1. Resumable expressions do not need to be type erased, but can.
2. Resumable expression objects can be held as objects,, (even non-type
erased? I am not sure).

What are the chances that we could capture the coroutines themselves in
variables, and make them copyable and movable?
I tend to see as a standard idiom to have objects that can be
copied/moved/compared, etc. that is the trend lately I think.
I do not mean the rest is not good, but why should we prevent these
semantics in the first place in coroutines?


Also, I see the yield keyword. I am not sure how it works. That is on the
library side in Chris' proposal, represented as an object.
What are the differences?

--

---
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_339_1766442511.1444369784974
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>On Thursday, October 8, 2015 at 12:31:48 AM UTC+7, Gor Nishanov wro=
te:<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>Germa=
n:</div><div><br></div><div>If you noticed the theme of my answers to your =
questions was to move you away from feature list style comparison and take =
a look=C2=A0at=C2=A0how it is reduced to practice.</div><div><br></div><div=
>Alex Stepanov said many insightful things and one of=C2=A0them was: &quot;=
I still believe in abstraction, but now I know that one ends with abstracti=
on, not starts with it. I learned that one has to adapt abstractions to rea=
lity and not the other way around.&quot; (<a href=3D"http://web.archive.org=
/web/20071120015600/http://www.research.att.com/~bs/hopl-almost-final.pdf" =
target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://w=
ww.google.com/url?q\75http%3A%2F%2Fweb.archive.org%2Fweb%2F20071120015600%2=
Fhttp%3A%2F%2Fwww.research.att.com%2F~bs%2Fhopl-almost-final.pdf\46sa\75D\4=
6sntz\0751\46usg\75AFQjCNE600BcHn2uIBKZaQ4HNlNaU94Keg&#39;;return true;" on=
click=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fweb.ar=
chive.org%2Fweb%2F20071120015600%2Fhttp%3A%2F%2Fwww.research.att.com%2F~bs%=
2Fhopl-almost-final.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNE600BcHn2uIBKZaQ=
4HNlNaU94Keg&#39;;return true;">http://web.archive.org/web/<wbr>20071120015=
600/http://www.<wbr>research.att.com/~bs/hopl-<wbr>almost-final.pdf</a>=C2=
=A0page 18).</div></div></blockquote><div><br>Well, I agree that you accumu=
lated a good deal of experience during the implementation. Noone can negate=
 that. And evidence shows that, for your test cases,<br>the negative overhe=
ad seems impressive.<br>=C2=A0</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><b>On hidden magic:</b></div><div><br></div><di=
v>Coroutine proposal is similar to a=C2=A0range-base-for. A compiler does t=
he syntactic sugar. The magic is an idea of iterable that allows a compiler=
 to communicate with the library.</div><div><br></div></div></blockquote><d=
iv>That is nice, because I really thought there was a scheduler embedded in=
 some way, but this stays on the lib side, right?<br><br>=C2=A0<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div=
>Similarly, with coroutine proposal, the magic that gets you zero/negative-=
overhead is in an idea of awaitable. You do the magic yourself. You can fin=
d samples of &quot;negative-overhead&quot; awaitable in=C2=A0the slides <a =
href=3D"http://wg21.link/N4287" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwg21.lin=
k%2FN4287\46sa\75D\46sntz\0751\46usg\75AFQjCNGd5AKPNNo0D2eU5bR9S1oVur6i_Q&#=
39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\7=
5http%3A%2F%2Fwg21.link%2FN4287\46sa\75D\46sntz\0751\46usg\75AFQjCNGd5AKPNN=
o0D2eU5bR9S1oVur6i_Q&#39;;return true;">http://wg21.link/N4287</a>. Also <a=
 href=3D"http://wg21.link/P0055" target=3D"_blank" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwg21.li=
nk%2FP0055\46sa\75D\46sntz\0751\46usg\75AFQjCNGpBejv-GXczYPJHk9I8ZIAruL2Eg&=
#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\=
75http%3A%2F%2Fwg21.link%2FP0055\46sa\75D\46sntz\0751\46usg\75AFQjCNGpBejv-=
GXczYPJHk9I8ZIAruL2Eg&#39;;return true;">http://wg21.link/P0055</a> shows h=
ow this=C2=A0magic can be=C2=A0extended=C2=A0via CompletionToken technique=
=C2=A0to any=C2=A0template library that models their API after the=C2=A0net=
working library.</div><div>=C2=A0</div></div></blockquote><blockquote class=
=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></div><div>The transforma=
tion that compiler does is specified in=C2=A0=C2=A0<a href=3D"http://wg21.l=
ink/P0057" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#=
39;http://www.google.com/url?q\75http%3A%2F%2Fwg21.link%2FP0057\46sa\75D\46=
sntz\0751\46usg\75AFQjCNGKxgvnrBtTSt56zwo9DDI87B2ZdA&#39;;return true;" onc=
lick=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwg21.li=
nk%2FP0057\46sa\75D\46sntz\0751\46usg\75AFQjCNGKxgvnrBtTSt56zwo9DDI87B2ZdA&=
#39;;return true;">http://wg21.link/P0057</a>.</div><div><br></div></div></=
blockquote><div><br>Given all this, I see your proposal as a nice candidate=
 also, though you already know my preference and why. Basically:<br><br>1. =
Resumable expressions do not need to be type erased, but can.<br>2. Resumab=
le expression objects can be held as objects,, (even non-type erased? I am =
not sure).<br><br>What are the chances that we could capture the coroutines=
 themselves in variables, and make them copyable and movable? <br>I tend to=
 see as a standard idiom to have objects that can be copied/moved/compared,=
 etc. that is the trend lately I think.<br>I do not mean the rest is not go=
od, but why should we prevent these semantics in the first place in corouti=
nes?<br><br><br>Also, I see the yield keyword. I am not sure how it works. =
That is on the library side in Chris&#39; proposal, represented as an objec=
t.<br>What are the differences?<br><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&quot; 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_339_1766442511.1444369784974--
------=_Part_338_1950419799.1444369784974--

.

------=_Part_48_1119720974.1444369883250
Content-Type: multipart/alternative;
 boundary="----=_Part_49_1163712282.1444369883250"

------=_Part_49_1163712282.1444369883250
Content-Type: text/plain; charset=UTF-8



> 1. Resumable expressions do not need to be type erased, but can.
> 2. Resumable expression objects can be held as objects,, (even non-type
> erased? I am not sure).
>

Also:

  3. Template code reuse also seems appealing to me.

--

---
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_49_1163712282.1444369883250
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>1. R=
esumable expressions do not need to be type erased, but can.<br>2. Resumabl=
e expression objects can be held as objects,, (even non-type erased? I am n=
ot sure).<br></div></blockquote><div>=C2=A0<br>Also:<br><br></div><div>=C2=
=A0 3. Template code reuse also seems appealing to me. <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&quot; 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_49_1163712282.1444369883250--
------=_Part_48_1119720974.1444369883250--

.

------=_Part_2986_528561916.1444400380815
Content-Type: multipart/alternative;
 boundary="----=_Part_2987_1001172641.1444400380815"

------=_Part_2987_1001172641.1444400380815
Content-Type: text/plain; charset=UTF-8



On Thursday, October 8, 2015 at 10:49:45 PM UTC-7, germa...@gmail.com wrote:
>
>
> Well, I agree that you accumulated a good deal of experience during the
> implementation. Noone can negate that. And evidence shows that, for your
> test cases,
> the negative overhead seems impressive.
>

Perhaps I was too cryptic in my previous response. The point of Stepanov's
quote was that usefulness of an abstraction comes from how it helps to
solve a real problem. You start with the problem, you end with an
abstraction (See N4287 slide 7 for more). Thus, if you believe that a
particular aspect of resumable expressions is awesome. Take a real problem
(possibly reduce it to the size of tcp_reader) and code it up using
resumable expression syntax, than compare how the same problem can be
solved using coroutines. Evaluate it on the three criteria I listed: how
much end-user writes, how much library support required, what is the
abstraction penalty.


>  Also, I see the yield keyword. I am not sure how it works. That is on the
> library side in Chris' proposal, represented as an object.
>

`yield expr' is syntactic sugar for 'await $p.yield_value(expr)' . See
p0057r0/*[expr.yield]*
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0057r0.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_2987_1001172641.1444400380815
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, October 8, 2015 at 10:49:45 PM UTC-7,=
 germa...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 20=
4); border-left-width: 1px; border-left-style: solid;"><br><div>Well, I agr=
ee that you accumulated a good deal of experience during the implementation=
.. Noone can negate that. And evidence shows that, for your test cases,<br>t=
he negative overhead seems impressive.</div></blockquote><div><br></div><di=
v>Perhaps I was too cryptic in my previous response. The point of Stepanov&=
#39;s quote was that usefulness of an abstraction comes=C2=A0from how it he=
lps to solve a real problem. You start with the problem, you end with an ab=
straction (See N4287 slide 7 for more). Thus, if you believe that a particu=
lar aspect of resumable expressions is awesome. Take a real problem (possib=
ly reduce it to the size of tcp_reader) and code it up using resumable expr=
ession syntax, than compare how the same problem can be solved using corout=
ines. Evaluate it on the three criteria I listed: how much end-user writes,=
 how much library support required, what is the abstraction penalty.</div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" 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;"><div>=C2=A0Also, I see the yie=
ld keyword. I am not sure how it works. That is on the library side in Chri=
s&#39; proposal, represented as an object.<br></div></blockquote><div><br><=
/div><div>`yield expr&#39; is syntactic sugar=C2=A0for &#39;await $p.yield_=
value(expr)&#39;=C2=A0. See <a href=3D"http://www.open-std.org/jtc1/sc22/wg=
21/docs/papers/2015/p0057r0.pdf">p0057r0/<b><font face=3D"LMRoman10-Bold" s=
ize=3D"3"><font face=3D"LMRoman10-Bold" size=3D"3">[expr.yield]</font></fon=
t></b></a><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&quot; 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_2987_1001172641.1444400380815--
------=_Part_2986_528561916.1444400380815--

.

------=_Part_263_1513470719.1444404116424
Content-Type: multipart/alternative;
 boundary="----=_Part_264_1755520863.1444404116424"

------=_Part_264_1755520863.1444404116424
Content-Type: text/plain; charset=UTF-8



On Friday, October 9, 2015 at 1:49:45 AM UTC-4, germa...@gmail.com wrote:
>
> What are the chances that we could capture the coroutines themselves in
> variables, and make them copyable and movable?
> I tend to see as a standard idiom to have objects that can be
> copied/moved/compared, etc. that is the trend lately I think.
> I do not mean the rest is not good, but why should we prevent these
> semantics in the first place in coroutines?
>

If you're talking about value semantics, that doesn't make sense for
coroutines. Remember that part of a coroutine's state is the stack. And
stack variables are often references or pointers to other stack variables.
You cannot effectively copy such a construct. And it's silly for the user
to have to define a "copy constructor" for their call stack.

That's why `coroutine_handle` has reference semantics. It just makes more
sense for coroutines. That doesn't prevent you from being able to pass them
(and any containing object) around. You can even have a
`std::vector<generator<int>>` and resume each one in turn.

Or to put it another way, just because you see `await` used to catch the
coroutine promise returned by a coroutine does not mean you *have* to use
it that way.


> Also, I see the yield keyword. I am not sure how it works.
>

It returns a value and suspends the coroutine's execution at that point.

If you're wondering about the details of how the value is passed to the
coroutine promise and all, that's part of the proposal.

--

---
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_264_1755520863.1444404116424
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, October 9, 2015 at 1:49:45 AM UTC-4, ge=
rma...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Wh=
at are the chances that we could capture the coroutines themselves in varia=
bles, and make them copyable and movable? <br>I tend to see as a standard i=
diom to have objects that can be copied/moved/compared, etc. that is the tr=
end lately I think.<br>I do not mean the rest is not good, but why should w=
e prevent these semantics in the first place in coroutines?<br></div></bloc=
kquote><div><br>If you&#39;re talking about value semantics, that doesn&#39=
;t make sense for coroutines. Remember that part of a coroutine&#39;s state=
 is the stack. And stack variables are often references or pointers to othe=
r stack variables. You cannot effectively copy such a construct. And it&#39=
;s silly for the user to have to define a &quot;copy constructor&quot; for =
their call stack.<br><br>That&#39;s why `coroutine_handle` has reference se=
mantics. It just makes more sense for coroutines. That doesn&#39;t prevent =
you from being able to pass them (and any containing object) around. You ca=
n even have a `std::vector&lt;generator&lt;int&gt;&gt;` and resume each one=
 in turn.<br><br>Or to put it another way, just because you see `await` use=
d to catch the coroutine promise returned by a coroutine does not mean you =
<i>have</i> to use it that way.<br>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div>Also, I see the yield keyword. I am not sure how it w=
orks.</div></blockquote><div><br>It returns a value and suspends the corout=
ine&#39;s execution at that point.<br><br>If you&#39;re wondering about the=
 details of how the value is passed to the coroutine promise and all, that&=
#39;s part of the proposal.</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&quot; 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_264_1755520863.1444404116424--
------=_Part_263_1513470719.1444404116424--

.

------=_Part_3823_1953059056.1444451074808
Content-Type: multipart/alternative;
 boundary="----=_Part_3824_1928505359.1444451074808"

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



El viernes, 9 de octubre de 2015, 22:21:56 (UTC+7), Nicol Bolas escribi=C3=
=B3:
>
>
>
> On Friday, October 9, 2015 at 1:49:45 AM UTC-4, germa...@gmail.com wrote:
>>
>> What are the chances that we could capture the coroutines themselves in=
=20
>> variables, and make them copyable and movable?=20
>> I tend to see as a standard idiom to have objects that can be=20
>> copied/moved/compared, etc. that is the trend lately I think.
>> I do not mean the rest is not good, but why should we prevent these=20
>> semantics in the first place in coroutines?
>>
>
> If you're talking about value semantics, that doesn't make sense for=20
> coroutines. Remember that part of a coroutine's state is the stack. And=
=20
> stack variables are often references or pointers to other stack variables=
..=20
> You cannot effectively copy such a construct. And it's silly for the user=
=20
> to have to define a "copy constructor" for their call stack.
>

In some cases it makes sense, in others, it does not make sense. It all=20
depends, I think. Let me look for more seriuos use cases.

=20

>
> That's why `coroutine_handle` has reference semantics. It just makes more=
=20
> sense for coroutines. That doesn't prevent you from being able to pass th=
em=20
> (and any containing object) around. You can even have a=20
> `std::vector<generator<int>>` and resume each one in turn.
>

That you can store them is nice, indeed!=20
=20

> Or to put it another way, just because you see `await` used to catch the=
=20
> coroutine promise returned by a coroutine does not mean you *have* to use=
=20
> it that way.
>

I am not sure about this. I have to take a more serious look to both=20
proposals and do a comparison. I think a good starting point would be to=20
convert Gor's code=20
to resumable expressions, which is what I think is more low-level proposal,=
=20
and see how code looks.

Yesterday I was taking a look and I still have the impression that Gor's=20
proposal is not as minimal as it could be. At least it does not embed any=
=20
scheduler, that is true,
but I see that it "hardcodes" a protocol into the language that is bigger=
=20
than Chris'. But as I said, I need to take a more serious look at this to=
=20
make a really
fair and accurate comparison.
=20

> =20
>
>> Also, I see the yield keyword. I am not sure how it works.
>>
>
> It returns a value and suspends the coroutine's execution at that point.
>

In resumable expressions, that can be done on top of a library abstraction,=
=20
why putting this into the language should be better?
Remember that when you put something into the language, there is no way=20
back. This is my main reasoning for making things
into a library when possible. Resumable expressions are minimal. Still,=20
hold on, I need a more serious look into this.
=20

> If you're wondering about the details of how the value is passed to the=
=20
> coroutine promise and all, that's part of the proposal.
>

Well, at a first impression, you all know which proposal I would favour,=20
but I need to document myself further on this. I hope I can
give a more in-depth comparison. Though, cannot promise, a lot of work. :)

Regards
=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_3824_1928505359.1444451074808
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>El viernes, 9 de octubre de 2015, 22:21:56 (UTC+7), Nicol Bolas  es=
cribi=C3=B3:<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"><=
br><br>On Friday, October 9, 2015 at 1:49:45 AM UTC-4, <a>germa...@gmail.co=
m</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>What are the chanc=
es that we could capture the coroutines themselves in variables, and make t=
hem copyable and movable? <br>I tend to see as a standard idiom to have obj=
ects that can be copied/moved/compared, etc. that is the trend lately I thi=
nk.<br>I do not mean the rest is not good, but why should we prevent these =
semantics in the first place in coroutines?<br></div></blockquote><div><br>=
If you&#39;re talking about value semantics, that doesn&#39;t make sense fo=
r coroutines. Remember that part of a coroutine&#39;s state is the stack. A=
nd stack variables are often references or pointers to other stack variable=
s. You cannot effectively copy such a construct. And it&#39;s silly for the=
 user to have to define a &quot;copy constructor&quot; for their call stack=
..<br></div></div></blockquote><div><br></div><div>In some cases it makes se=
nse, in others, it does not make sense. It all depends, I think. Let me loo=
k for more seriuos use cases.</div><div><br></div><div>=C2=A0</div><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"><div><br>That&#39;s w=
hy `coroutine_handle` has reference semantics. It just makes more sense for=
 coroutines. That doesn&#39;t prevent you from being able to pass them (and=
 any containing object) around. You can even have a `std::vector&lt;generat=
or&lt;int&gt;&gt;` and resume each one in turn.<br></div></div></blockquote=
><div><br></div><div>That you can store them is nice, indeed!=C2=A0</div><d=
iv>=C2=A0</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>Or to put it another way, just because you see `await` used to catch=
 the coroutine promise returned by a coroutine does not mean you <i>have</i=
> to use it that way.<br></div></div></blockquote><div><br></div><div>I am =
not sure about this. I have to take a more serious look to both proposals a=
nd do a comparison. I think a good starting point would be to convert Gor&#=
39;s code=C2=A0</div><div>to resumable expressions, which is what I think i=
s more low-level proposal, and see how code looks.</div><div><br></div><div=
>Yesterday I was taking a look and I still have the impression that Gor&#39=
;s proposal is not as minimal as it could be. At least it does not embed an=
y scheduler, that is true,</div><div>but I see that it &quot;hardcodes&quot=
; a protocol into the language that is bigger than Chris&#39;. But as I sai=
d, I need to take a more serious look at this to make a really</div><div>fa=
ir and accurate comparison.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div>Also, I see the yield keyword. I am not sure how it=
 works.</div></blockquote><div><br>It returns a value and suspends the coro=
utine&#39;s execution at that point.<br></div></div></blockquote><div><br><=
/div><div>In resumable expressions, that can be done on top of a library ab=
straction, why putting this into the language should be better?</div><div>R=
emember that when you put something into the language, there is no way back=
.. This is my main reasoning for making things</div><div>into a library when=
 possible. Resumable expressions are minimal. Still, hold on, I need a more=
 serious look into this.</div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div>If you&#39;re wondering about the de=
tails of how the value is passed to the coroutine promise and all, that&#39=
;s part of the proposal.</div></div></blockquote><div><br></div><div>Well, =
at a first impression, you all know which proposal I would favour, but I ne=
ed to document myself further on this. I hope I can</div><div>give a more i=
n-depth comparison. Though, cannot promise, a lot of work. :)</div><div><br=
></div><div>Regards</div><div>=C2=A0</div>

<p></p>

-- <br />
<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 <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_3824_1928505359.1444451074808--
------=_Part_3823_1953059056.1444451074808--

.

------=_Part_51_1909735446.1444458880175
Content-Type: multipart/alternative;
 boundary="----=_Part_52_1115078794.1444458880175"

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

On Saturday, October 10, 2015 at 12:24:34 AM UTC-4, Germ=C3=A1n Diago wrote=
:
>
> El viernes, 9 de octubre de 2015, 22:21:56 (UTC+7), Nicol Bolas escribi=
=C3=B3:
>
>> Or to put it another way, just because you see `await` used to catch the=
=20
>> coroutine promise returned by a coroutine does not mean you *have* to=20
>> use it that way.
>>
>
> I am not sure about this. I have to take a more serious look to both=20
> proposals and do a comparison. I think a good starting point would be to=
=20
> convert Gor's code=20
> to resumable expressions, which is what I think is more low-level=20
> proposal, and see how code looks.
>

> Yesterday I was taking a look and I still have the impression that Gor's=
=20
> proposal is not as minimal as it could be. At least it does not embed any=
=20
> scheduler, that is true,
> but I see that it "hardcodes" a protocol into the language that is bigger=
=20
> than Chris'. But as I said, I need to take a more serious look at this to=
=20
> make a really
> fair and accurate comparison.
>

I guess my question is this: why does it matter which is "lower level" than=
=20
the other?

A proposal should be as low level as it needs to be, and *no lower*. So,=20
given equal performance in similar situations (and Gor has provided=20
evidence that this is possible in at least some cases), the principle=20
difference maker should be actual functionality, not the level of=20
abstraction.

Indeed, I feel quite the opposite from you. So long as they provide=20
equivalent functionality with equivalent performance, the *higher* level=20
one should be considered better. `int[5]` is unquestionably lower level=20
than `array<int, 5>`, but we tell people to almost always use the latter=20
instead of the former. We do so because, though the latter is higher level,=
=20
it causes no loss of performance, and it improves safety and ease-of-use=20
over the former.

Also, I see the yield keyword. I am not sure how it works.
>>>
>>
>> It returns a value and suspends the coroutine's execution at that point.
>>
>
> In resumable expressions, that can be done on top of a library=20
> abstraction, why putting this into the language should be better?
>

The question could easily be turned around: why is putting it into the=20
library better? Because it's more "low-level", by some measurement? What=20
good does that do me as a user of the language?

After all, with the exception of `break`, there's nothing range-based for=
=20
can do that `for_each` cannot. Yet we thought that was important enough to=
=20
put into the language.

So I do not see why merely allowing a feature to be implemented in the=20
library rather than the language is a point in that version's favor. It's=
=20
interesting and useful to note, but it is not, by itself, an advantage.

Remember that when you put something into the language, there is no way=20
> back.
>

I contest the idea that language features are more immutable than library=
=20
features. The standard library contains a lot of deficient elements, but I=
=20
don't see those being undone. We still have iostreams lying around, despite=
=20
wide-spread conventional wisdom saying not to use them. We still have STL=
=20
containers that don't erase the allocator's type, despite this being an=20
oft-requested feature.

Oh sure, we seem to be getting rid of `auto_ptr` and a couple of other=20
small things. But I don't see any evidence that library functionality is so=
=20
much more malleable than language features.

Mistakes will persist, no matter whether they are language or library=20
mistakes. So we shouldn't be that much more afraid of language screwups=20
than library ones. Indeed, the latter will be far more persistent, since=20
most people aren't going to be directly interfacing with the low-level.

Or to put it another way, however you choose to implement "yield", that is=
=20
what people are going to use. As a common coroutine feature, lots of code=
=20
will be written against it. And once implemented, you will be no more able=
=20
to correct flaws in a library `yield` function than in a language `yield`=
=20
expression.

--=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_52_1115078794.1444458880175
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, October 10, 2015 at 12:24:34 AM UTC-4, Germ=
=C3=A1n Diago wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">El viernes=
, 9 de octubre de 2015, 22:21:56 (UTC+7), Nicol Bolas  escribi=C3=B3:<br><d=
iv></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>Or t=
o put it another way, just because you see `await` used to catch the corout=
ine promise returned by a coroutine does not mean you <i>have</i> to use it=
 that way.<br></div></div></blockquote><div><br></div><div>I am not sure ab=
out this. I have to take a more serious look to both proposals and do a com=
parison. I think a good starting point would be to convert Gor&#39;s code=
=C2=A0</div><div>to resumable expressions, which is what I think is more lo=
w-level proposal, and see how code looks.</div></blockquote><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div><br></div><div>Yesterday I was taking a =
look and I still have the impression that Gor&#39;s proposal is not as mini=
mal as it could be. At least it does not embed any scheduler, that is true,=
</div><div>but I see that it &quot;hardcodes&quot; a protocol into the lang=
uage that is bigger than Chris&#39;. But as I said, I need to take a more s=
erious look at this to make a really</div><div>fair and accurate comparison=
..</div></blockquote><div><br>I guess my question is this: why does it matte=
r which is &quot;lower level&quot; than the other?<br><br>A proposal should=
 be as low level as it needs to be, and <i>no lower</i>. So, given equal pe=
rformance in similar situations (and Gor has provided evidence that this is=
 possible in at least some cases), the principle difference maker should be=
 actual functionality, not the level of abstraction.<br><br>Indeed, I feel =
quite the opposite from you. So long as they provide equivalent functionali=
ty with equivalent performance, the <i>higher</i> level one should be consi=
dered better. `int[5]` is unquestionably lower level than `array&lt;int, 5&=
gt;`, but we tell people to almost always use the latter instead of the for=
mer. We do so because, though the latter is higher level, it causes no loss=
 of performance, and it improves safety and ease-of-use over the former.<br=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div></div><blockqu=
ote 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"><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div>Also, I see the yield keyword. I am not sure how it work=
s.</div></blockquote><div><br>It returns a value and suspends the coroutine=
&#39;s execution at that point.<br></div></div></blockquote><div><br></div>=
<div>In resumable expressions, that can be done on top of a library abstrac=
tion, why putting this into the language should be better?</div></blockquot=
e><div><br>The question could easily be turned around: why is putting it in=
to the library better? Because it&#39;s more &quot;low-level&quot;, by some=
 measurement? What good does that do me as a user of the language?<br><br>A=
fter all, with the exception of `break`, there&#39;s nothing range-based fo=
r can do that `for_each` cannot. Yet we thought that was important enough t=
o put into the language.<br><br>So I do not see why merely allowing a featu=
re to be implemented in the library rather than the language is a point in =
that version&#39;s favor. It&#39;s interesting and useful to note, but it i=
s not, by itself, an advantage.<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div>Remember that when you put something into the language,=
 there is no way back.</div></blockquote><div><br>I contest the idea that l=
anguage features are more immutable than library features. The standard lib=
rary contains a lot of deficient elements, but I don&#39;t see those being =
undone. We still have iostreams lying around, despite wide-spread conventio=
nal wisdom saying not to use them. We still have STL containers that don&#3=
9;t erase the allocator&#39;s type, despite this being an oft-requested fea=
ture.<br><br>Oh sure, we seem to be getting rid of `auto_ptr` and a couple =
of other small things. But I don&#39;t see any evidence that library functi=
onality is so much more malleable than language features.<br><br>Mistakes w=
ill persist, no matter whether they are language or library mistakes. So we=
 shouldn&#39;t be that much more afraid of language screwups than library o=
nes. Indeed, the latter will be far more persistent, since most people aren=
&#39;t going to be directly interfacing with the low-level.<br><br>Or to pu=
t it another way, however you choose to implement &quot;yield&quot;, that i=
s what people are going to use. As a common coroutine feature, lots of code=
 will be written against it. And once implemented, you will be no more able=
 to correct flaws in a library `yield` function than in a language `yield` =
expression.<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&quot; 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_52_1115078794.1444458880175--
------=_Part_51_1909735446.1444458880175--

.

------=_Part_285_1373744832.1444486960346
Content-Type: multipart/alternative;
 boundary="----=_Part_286_1607293672.1444486960346"

------=_Part_286_1607293672.1444486960346
Content-Type: text/plain; charset=UTF-8

On the recent `operator await` syntax in P0057. Is it possible for a user
to call this operator these themselves? And if so, will it work correctly
for types that don't provide one (that is, resolving to the original type
or issuing a compiler error)?

If not, it would probably be useful if the user could invoke it themselves.

--

---
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_286_1607293672.1444486960346
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On the recent `operator await` syntax in P0057. Is it poss=
ible for a user to call this operator these themselves? And if so, will it =
work correctly for types that don&#39;t provide one (that is, resolving to =
the original type or issuing a compiler error)?<br><br>If not, it would pro=
bably be useful if the user could invoke it themselves.<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&quot; 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_286_1607293672.1444486960346--
------=_Part_285_1373744832.1444486960346--

.

------=_Part_4097_1640121953.1444489093194
Content-Type: multipart/alternative;
 boundary="----=_Part_4098_29049363.1444489093204"

------=_Part_4098_29049363.1444489093204
Content-Type: text/plain; charset=UTF-8



On Saturday, October 10, 2015 at 7:22:40 AM UTC-7, Nicol Bolas wrote:
>
> On the recent `operator await` syntax in P0057. Is it possible for a user
> to call this operator these themselves? And if so, will it work correctly
> for types that don't provide one (that is, resolving to the original type
> or issuing a compiler error)?
>
> If not, it would probably be useful if the user could invoke it themselves.
>

Absolutely, observe me doing this in the main of the attached program:

int main() {

   operator await(1ms);

One thing that is somewhat awkward:

   operator await(1ms);

is not the same as

   await 1ms;

The first one, gets me an awaitable from 1ms. Another is await-ing 1ms.
Difference between calling an operator function directly or calling it via
operator notation, is not exactly novel.
The behavior of (x || y) is different from calling operator||(x,y).
I don't like it much. I don't mind operator await to be renamed to
get_awaiter or something, but, I do think that operator await is prettier
and it is easier to think that language synthesizes operator await for some
types rather than synthesizing a function.

Again, I am slightly leaning toward operator await, rather than
get_awaiter, but if Core/Evolution/LWG/LEWG wants something else.
Absolutely.

--

---
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_4098_29049363.1444489093204
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, October 10, 2015 at 7:22:40 AM UTC-7,=
 Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On the rec=
ent `operator await` syntax in P0057. Is it possible for a user to call thi=
s operator these themselves? And if so, will it work correctly for types th=
at don&#39;t provide one (that is, resolving to the original type or issuin=
g a compiler error)?<br><br>If not, it would probably be useful if the user=
 could invoke it themselves.<br></div></blockquote><div><br></div><div>Abso=
lutely, observe me doing this in the main of the attached program:</div><di=
v><br></div><div><p><font color=3D"#0000ff" face=3D"Consolas" size=3D"2"><f=
ont color=3D"#0000ff" face=3D"Consolas" size=3D"2"><font color=3D"#0000ff" =
face=3D"Consolas" size=3D"2">int</font></font></font><font face=3D"Consolas=
" size=3D"2"><font face=3D"Consolas" size=3D"2"> main() {</font></font></p>=
<font face=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=3D"2">

</font></font><p><font face=3D"Consolas" size=3D"2"><font face=3D"Consolas"=
 size=3D"2"> </font></font><font color=3D"#0000ff" face=3D"Consolas" size=
=3D"2"><font color=3D"#0000ff" face=3D"Consolas" size=3D"2"><font color=3D"=
#0000ff" face=3D"Consolas" size=3D"2">=C2=A0=C2=A0 operator</font></font></=
font><font face=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=3D"2">=
 <font color=3D"#0000ff">await</font>(1ms);</font></font></p></div><div><br=
></div><div>One thing that is somewhat awkward:</div><div><br></div><div><f=
ont color=3D"#0000ff" face=3D"Consolas" size=3D"2">=C2=A0=C2=A0 operator</f=
ont><font face=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=3D"2"> =
<font color=3D"#0000ff">await</font>(1ms);</font></font></div><div><font fa=
ce=3D"Consolas" size=3D"2"><br></font></div><div><font face=3D"Consolas" si=
ze=3D"2">is not the same as</font></div><div><font face=3D"Consolas" size=
=3D"2"><br></font></div><div><font face=3D"Consolas" size=3D"2">=C2=A0=C2=
=A0=C2=A0<font face=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=3D=
"2"><font color=3D"#0000ff">await </font>1ms;</font></font></font></div><di=
v><font face=3D"Consolas" size=3D"2"><br></font></div><div><font face=3D"Co=
nsolas" size=3D"2">The first one, gets me an awaitable from 1ms. Another is=
 await-ing=C2=A01ms.</font></div><div><font face=3D"Consolas" size=3D"2">Di=
fference between calling an operator function directly or calling it via op=
erator notation, is not exactly novel. <br>The behavior of (x || y) is diff=
erent from calling operator||(x,y).</font></div><div><font face=3D"Consolas=
" size=3D"2">I don&#39;t like it much. I don&#39;t mind operator await to b=
e renamed to get_awaiter or something, but, I do think that operator await =
is prettier and it is easier to think that language synthesizes operator aw=
ait for some types rather than synthesizing a function.</font></div><div><f=
ont face=3D"Consolas" size=3D"2"><br></font></div><div><font face=3D"Consol=
as" size=3D"2">Again, I am slightly leaning toward operator await, rather t=
han get_awaiter, but if Core/Evolution/LWG/LEWG wants something else. Absol=
utely.</font></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&quot; 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_4098_29049363.1444489093204--
------=_Part_4097_1640121953.1444489093194
Content-Type: text/x-c++src; charset=US-ASCII; name=opawait.cpp
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=opawait.cpp
X-Attachment-Id: 2da6fbc0-f5be-4f2f-bbb0-dd1a7069ddbf
Content-ID: <2da6fbc0-f5be-4f2f-bbb0-dd1a7069ddbf>

#include <windows.h>
#include <stdio.h>
#include <experimental/resumable>
#include <chrono>
#include <Synchapi.h>
#include <threadpoolapiset.h>
#include <thread>

using namespace std::chrono;

class awaiter {
  static void CALLBACK TimerCallback(PTP_CALLBACK_INSTANCE, void *Context, PTP_TIMER) {
    std::experimental::coroutine_handle<>::from_address(Context)();
  }
  PTP_TIMER timer = nullptr;
  std::chrono::system_clock::duration duration;

public:
  explicit awaiter(std::chrono::system_clock::duration d) : duration(d) {}
  bool await_ready() const { return duration.count() <= 0; }
  bool await_suspend(std::experimental::coroutine_handle<> resume_cb) {
    int64_t relative_count = -duration.count();
    timer =
        CreateThreadpoolTimer(TimerCallback, resume_cb.to_address(), nullptr);
    SetThreadpoolTimer(timer, (PFILETIME)&relative_count, 0, 0);
    return timer != 0;
  }
  void await_resume() {}
  ~awaiter() {
    if (timer)
      CloseThreadpoolTimer(timer);
  }
};

auto sleep_for(std::chrono::system_clock::duration duration) {
  return awaiter{duration};
}

auto operator await(std::chrono::system_clock::duration duration) {
  return awaiter{duration};
}

SRWLOCK lock = {SRWLOCK_INIT};

struct coro {
  struct promise_type {
    auto get_return_object() { return coro{}; }
    bool initial_suspend() { return false; }
    bool final_suspend() { return false; }
    void return_void() {}
  };
};

coro test() {
  puts("sleeping...");
  await sleep_for(1ms);
  puts(" woke up ... going to sleep again...");
  await 1ms;
  puts(" ok. you woke me up againt. I am out of here\n");
  ReleaseSRWLockExclusive(&lock);
}

int main() {

 operator await(1ms);

  AcquireSRWLockExclusive(&lock);
  test();
  AcquireSRWLockExclusive(&lock);
}
------=_Part_4097_1640121953.1444489093194--

.

------=_Part_3840_647753127.1444489303713
Content-Type: multipart/alternative;
 boundary="----=_Part_3841_707706196.1444489303714"

------=_Part_3841_707706196.1444489303714
Content-Type: text/plain; charset=UTF-8

Correction. I think you meant: (referring to classes in opawait attached in
the previous response)

operator await(awaiter{ 1ms });


not


operator await(1ms);


Yes, I think the wording is written to make it possible, however, I just
checked, the implementation we ship in VS Update 1 does not do that. I
filed a bug against myself.

--

---
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_3841_707706196.1444489303714
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Correction. I think you meant: (referring to classes =
in opawait attached in the previous response)</div><div><br></div><div><p><=
font face=3D"Consolas" size=3D"2"><font face=3D"Consolas" size=3D"2"> </fon=
t></font><font color=3D"#0000ff" face=3D"Consolas" size=3D"2"><font color=
=3D"#0000ff" face=3D"Consolas" size=3D"2"><font color=3D"#0000ff" face=3D"C=
onsolas" size=3D"2">operator</font></font></font><font face=3D"Consolas" si=
ze=3D"2"><font face=3D"Consolas" size=3D"2"> await(awaiter{ 1ms });</font><=
/font></p><p><font face=3D"Consolas" size=3D"2"><br></font></p><p><font fac=
e=3D"Consolas" size=3D"2">not </font></p><p><font face=3D"Consolas" size=3D=
"2"><br></font></p><font face=3D"Consolas" size=3D"2"><p><font face=3D"Cons=
olas" size=3D"2"><font face=3D"Consolas" size=3D"2"> </font></font><font co=
lor=3D"#0000ff" face=3D"Consolas" size=3D"2"><font color=3D"#0000ff" face=
=3D"Consolas" size=3D"2"><font color=3D"#0000ff" face=3D"Consolas" size=3D"=
2">operator</font></font></font><font face=3D"Consolas" size=3D"2"><font fa=
ce=3D"Consolas" size=3D"2"> await(1ms);</font></font></p><p><br></p><p>Yes,=
 I think the wording is written to make it possible, however, I just checke=
d, the implementation we ship in VS Update 1 does not do that.=C2=A0I filed=
 a bug against myself.</p></font></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&quot; 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_3841_707706196.1444489303714--
------=_Part_3840_647753127.1444489303713--

.

------=_Part_46290_1460605572.1530060846249
Content-Type: multipart/alternative;
 boundary="----=_Part_46291_798944422.1530060846249"

------=_Part_46291_798944422.1530060846249
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


On Saturday, October 3, 2015 at 4:41:18 AM UTC-7, Germ=C3=A1n Diago wrote:
>
> Hello everyone,
>
> I do not mean to start a flame here, but I am still wondering why the=20
> coroutines from
> P0057R0 are still being considered.
>
> For what it is worth, I find the paper from Christopher Kohlhoff very=20
> clarifying, very well
> reasoned, and providing alternatives for all the important use cases from=
=20
> P0057R0 with
> superior implementations.
>

I agree with everything you wrote here, and I would like to see resumable=
=20
expressions revisited.

Thanks
=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/a652c040-0c04-4b32-91c1-8705294ec8be%40isocpp.or=
g.

------=_Part_46291_798944422.1530060846249
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Saturday, October 3, 2015 at 4:41:18 AM UTC-7, Germ=
=C3=A1n Diago wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">Hello everyone,<div><br></div><div>I do not mean to start a flame =
here, but I am still wondering why the coroutines from</div><div>P0057R0 ar=
e still being considered.</div><div><br></div><div>For what it is worth, I =
find the paper from Christopher Kohlhoff very clarifying, very well</div><d=
iv>reasoned, and providing alternatives for all the important use cases fro=
m P0057R0 with</div><div>superior implementations.</div></div></blockquote>=
<div><br></div><div>I agree with everything you wrote here, and I would lik=
e to see resumable expressions revisited.</div><div><br></div><div>Thanks<b=
r>=C2=A0</div></div>

<p></p>

-- <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 <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a652c040-0c04-4b32-91c1-8705294ec8be%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a652c040-0c04-4b32-91c1-8705294ec8be=
%40isocpp.org</a>.<br />

------=_Part_46291_798944422.1530060846249--

------=_Part_46290_1460605572.1530060846249--

.

------=_Part_10389_597984334.1530061696489
Content-Type: multipart/alternative;
 boundary="----=_Part_10390_701415345.1530061696489"

------=_Part_10390_701415345.1530061696489
Content-Type: text/plain; charset="UTF-8"

Why didn't we hear from the author of N4453 (Christopher Kohlhoff) in this
thread?

Thanks

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f51d4b62-0ff5-4d81-841a-bc8e0bdd5b91%40isocpp.org.

------=_Part_10390_701415345.1530061696489
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Why didn&#39;t we hear from the author of N4453 (Christoph=
er Kohlhoff) in this thread?<br><br>Thanks<br><br></div>

<p></p>

-- <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 <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f51d4b62-0ff5-4d81-841a-bc8e0bdd5b91%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f51d4b62-0ff5-4d81-841a-bc8e0bdd5b91=
%40isocpp.org</a>.<br />

------=_Part_10390_701415345.1530061696489--

------=_Part_10389_597984334.1530061696489--

.