------=_Part_5061_1231739072.1413353198113
Content-Type: text/plain; charset=UTF-8

Hello everyone,

I see the coroutines proposal with language integration and it looks great.

This paper talks about an extension.


While in previous papers resumable functions were annoted with resumable,
it is not the case anymore.
The function will be resumable if there is "yield" or "await" inside it.

Why would lambdas need the "resumable" annotation then, and don't follow
what the coroutines proposal does?



--

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

<div dir=3D"ltr">Hello everyone,<div><br></div><div>I see the coroutines pr=
oposal with language integration and it looks great.</div><div><br></div><d=
iv>This paper talks about an extension.</div><div><br></div><div><br></div>=
<div>While in previous papers resumable functions were annoted with resumab=
le, it is not the case anymore.</div><div>The function will be resumable if=
 there is "yield" or "await" inside it.</div><div><br></div><div>Why would =
lambdas need the "resumable" annotation then, and don't follow what the cor=
outines proposal does?</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_5061_1231739072.1413353198113--

.

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



On Wednesday, October 15, 2014 7:06:38 AM UTC+1, Germ=C3=A1n Diago wrote:
>
> Hello everyone,
>
> I see the coroutines proposal with language integration and it looks grea=
t.
>
> This paper talks about an extension.
>
>
> While in previous papers resumable functions were annoted with resumable,=
=20
> it is not the case anymore.
> The function will be resumable if there is "yield" or "await" inside it.
>
> Why would lambdas need the "resumable" annotation then, and don't follow=
=20
> what the coroutines proposal does?
>
>
a vote for N4244 from me as well: another great paper from Christopher=20
Kohlhoff.=20

I never liked resumable functions as described in N3977, the runtime=20
overhead required to implement that spec is completely superfluous. Also=20
using futures for coroutine results seems wrong: futures are for=20
asynchronous operations, coroutines/generators themselves are inherently=20
synchronous (although a common use case is to bring order to async ops).

Regarding N4244 itself, just a couple of comments:

* as you already pointed out, the resumable annotation seems superfluous as=
=20
the 'resumableness' can be inferred by the presence of yield in the body.
* Drop the yield(type) expression support, and simply allow plain yield (or=
=20
yield() ) as an expression: the input type should be static the same way=20
the output is: if "yield  1; yield "foo"; " is not legal, neither should be=
=20
"auto x =3D yield(int); auto y =3D  yield(char *);". As far as I can tell,=
=20
yield(type) requires runtime type checking which not only seems an=20
unecessary overhead but can lead to runtime failures. Polymoprhism in the=
=20
input/output type should be explicit by yielding/receiving the equivalent=
=20
of a boost::variant, boost::any.
* I'm not a big fan of the "f.wanted() =3D x" syntax to pass parameters to=
=20
the coroutine, I would have preferred the plain "f(x)", but I understand=20
that causes other problems.

Otherwise, a really great proposal!

-- gpd


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

<div dir=3D"ltr"><br><br>On Wednesday, October 15, 2014 7:06:38 AM UTC+1, 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">Hello everyone,<div><br></div><div>I see the coroutines proposal =
with language integration and it looks great.</div><div><br></div><div>This=
 paper talks about an extension.</div><div><br></div><div><br></div><div>Wh=
ile in previous papers resumable functions were annoted with resumable, it =
is not the case anymore.</div><div>The function will be resumable if there =
is "yield" or "await" inside it.</div><div><br></div><div>Why would lambdas=
 need the "resumable" annotation then, and don't follow what the coroutines=
 proposal does?</div><div><br></div></div></blockquote><div><br>a vote for =
N4244 from me as well: another great paper from Christopher Kohlhoff. <br><=
br>I never liked resumable functions as described in N3977, the runtime ove=
rhead required to implement that spec is completely superfluous. Also using=
 futures for coroutine results seems wrong: futures are for asynchronous op=
erations, coroutines/generators themselves are inherently synchronous (alth=
ough a common use case is to bring order to async ops).<br><br>Regarding N4=
244 itself, just a couple of comments:<br><br>* as you already pointed out,=
 the resumable annotation seems superfluous as the 'resumableness' can be i=
nferred by the presence of yield in the body.<br>* Drop the yield(type) exp=
ression support, and simply allow plain yield (or yield() ) as an expressio=
n: the input type should be static the same way the output is: if "yield&nb=
sp; 1; yield "foo"; " is not legal, neither should be "auto x =3D yield(int=
); auto y =3D&nbsp; yield(char *);". As far as I can tell, yield(type) requ=
ires runtime type checking which not only seems an unecessary overhead but =
can lead to runtime failures. Polymoprhism in the input/output type should =
be explicit by yielding/receiving the equivalent of a boost::variant, boost=
::any.<br>* I'm not a big fan of the "f.wanted() =3D x" syntax to pass para=
meters to the coroutine, I would have preferred the plain "f(x)", but I und=
erstand that causes other problems.<br><br>Otherwise, a really great propos=
al!<br><br>-- gpd<br><br><br>&nbsp;</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_6466_464665638.1413447149867--

.

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



On Thursday, October 16, 2014 7:12:29 PM UTC+11, Giovanni Piero Deretta=20
wrote:
>
>
>
> On Wednesday, October 15, 2014 7:06:38 AM UTC+1, Germ=C3=A1n Diago wrote:
>>
>> Hello everyone,
>>
>> I see the coroutines proposal with language integration and it looks=20
>> great.
>>
>> This paper talks about an extension.
>>
>>
>> While in previous papers resumable functions were annoted with resumable=
,=20
>> it is not the case anymore.
>> The function will be resumable if there is "yield" or "await" inside it.
>>
>> Why would lambdas need the "resumable" annotation then, and don't follow=
=20
>> what the coroutines proposal does?
>>
>>
> a vote for N4244 from me as well: another great paper from Christopher=20
> Kohlhoff.
>

Thanks!=20

I never liked resumable functions as described in N3977, the runtime=20
> overhead required to implement that spec is completely superfluous. Also=
=20
> using futures for coroutine results seems wrong: futures are for=20
> asynchronous operations, coroutines/generators themselves are inherently=
=20
> synchronous (although a common use case is to bring order to async ops).
>
> Regarding N4244 itself, just a couple of comments:
>
> * as you already pointed out, the resumable annotation seems superfluous=
=20
> as the 'resumableness' can be inferred by the presence of yield in the bo=
dy.
>

Technically I agree, however there were a few reasons why I chose to keep=
=20
it in.

- The name "yield" is already being used as a function and variable name=20
(including in the standard library). Not being a compiler writer, I'm not=
=20
sure how much effort it is to make the keyword context sensitive, so I=20
chose to be conservative.

- We already have mutable lambdas denoted by a keyword, and a resumable=20
lambda must be mutable too. It felt more consistent and readable to keep a=
=20
keyword in that position, as not having a keyword currently means that the=
=20
lambda is const.

- I had code generators in the back of my mind, such as a tool that=20
simulates reflection and automatically generates serialisation support for=
=20
data structures. In this case the inconsistency in the behaviour of an=20
empty lambda bothered me. With the presence of yield determining whether a=
=20
lambda is resumable, an empty one is just a plain function object and thus=
=20
repeatedly callable. Any side effects in the body will be applied=20
repeatedly. With the proposal as written, an empty lambda still meets the=
=20
generator requirements, and will reach the terminal state after the first=
=20
call, i.e. side effects in the body can only occur once.

However, I am perfectly happy for it to be automatic, but I kept it in so=
=20
others have to explicitly choose to remove it after considering these=20
issues.
=20

> * Drop the yield(type) expression support, and simply allow plain yield=
=20
> (or yield() ) as an expression: the input type should be static the same=
=20
> way the output is: if "yield  1; yield "foo"; " is not legal, neither=20
> should be "auto x =3D yield(int); auto y =3D  yield(char *);". As far as =
I can=20
> tell, yield(type) requires runtime type checking which not only seems an=
=20
> unecessary overhead but can lead to runtime failures. Polymoprhism in the=
=20
> input/output type should be explicit by yielding/receiving the equivalent=
=20
> of a boost::variant, boost::any.
> * I'm not a big fan of the "f.wanted() =3D x" syntax to pass parameters t=
o=20
> the coroutine, I would have preferred the plain "f(x)", but I understand=
=20
> that causes other problems.
>

These two points are kind of related so I'll address them as one, but=20
working backwards.

First, "f(x)" actually works already because the lambda is still a function=
=20
object. The example at the end of section 7 uses this approach.

The "wanted" function on the other hand is needed to support composition of=
=20
sub-generators that return different types (i'm thinking async operations=
=20
here). For example:

  []() resumable
  {
    std::size_t n =3D yield from async_op_returning_a_size();
    std::string s =3D yield from async_op_returning_a_string();
  }

In python the async I/O framework effectively send()s the result of an=20
operation to the generator and it passes it onwards to the innermost=20
sub-generator, but python is also dynamically typed and lets us mix the=20
different generators without further thought. We need some form of dynamic=
=20
typing to do the same in C++, and as this is a core use case of the=20
facility i don't think it would be good to defer the polymorphism to a=20
library type.

In the snippet above, the async_op_returning_a_size() function already=20
"knows" that it wants a size_t result, so there's actually no possibility=
=20
to get the types wrong at runtime. The runtime check is not actually used=
=20
or required in this case. There is also no extra runtime overhead in this=
=20
case because the wanted() of the outer generator already has to forward the=
=20
call to the wanted() of the currently active sub-generator.

However, what I realised after submitting the paper is that the "x =3D yiel=
d=20
(int)" syntax is technically superfluous. You could instead replace it with=
=20
a library type which is itself a generator, e.g. "x =3D yield from=20
want<int>()". The generator returned by want<int>() would look similar to=
=20
the async_read_generator in section 11.

Cheers,
Chris

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

<div dir=3D"ltr"><br><br>On Thursday, October 16, 2014 7:12:29 PM UTC+11, G=
iovanni Piero Deretta wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><br><br>On Wednesday, October 15, 2014 7:06:38 AM UTC+1, Ger=
m=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"lt=
r">Hello everyone,<div><br></div><div>I see the coroutines proposal with la=
nguage integration and it looks great.</div><div><br></div><div>This paper =
talks about an extension.</div><div><br></div><div><br></div><div>While in =
previous papers resumable functions were annoted with resumable, it is not =
the case anymore.</div><div>The function will be resumable if there is "yie=
ld" or "await" inside it.</div><div><br></div><div>Why would lambdas need t=
he "resumable" annotation then, and don't follow what the coroutines propos=
al does?</div><div><br></div></div></blockquote><div><br>a vote for N4244 f=
rom me as well: another great paper from Christopher Kohlhoff.<br></div></d=
iv></blockquote><div><br></div><div>Thanks!&nbsp;</div><div><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 dir=3D"ltr"><div>I never liked=
 resumable functions as described in N3977, the runtime overhead required t=
o implement that spec is completely superfluous. Also using futures for cor=
outine results seems wrong: futures are for asynchronous operations, corout=
ines/generators themselves are inherently synchronous (although a common us=
e case is to bring order to async ops).<br><br>Regarding N4244 itself, just=
 a couple of comments:<br><br>* as you already pointed out, the resumable a=
nnotation seems superfluous as the 'resumableness' can be inferred by the p=
resence of yield in the body.<br></div></div></blockquote><div><br></div><d=
iv>Technically I agree, however there were a few reasons why I chose to kee=
p it in.</div><div><br></div><div>- The name "yield" is already being used =
as a function and variable name (including in the standard library). Not be=
ing a compiler writer, I'm not sure how much effort it is to make the keywo=
rd context sensitive, so I chose to be conservative.</div><div><br></div><d=
iv>- We already have mutable lambdas denoted by a keyword, and a resumable =
lambda must be mutable too. It felt more consistent and readable to keep a =
keyword in that position, as not having a keyword currently means that the =
lambda is const.</div><div><br></div><div>- I had code generators in the ba=
ck of my mind, such as a tool that simulates reflection and automatically g=
enerates serialisation support for data structures. In this case the incons=
istency in the behaviour of an empty lambda bothered me. With the presence =
of yield determining whether a lambda is resumable, an empty one is just a =
plain function object and thus repeatedly callable. Any side effects in the=
 body will be applied repeatedly. With the proposal as written, an empty la=
mbda still meets the generator requirements, and will reach the terminal st=
ate after the first call, i.e. side effects in the body can only occur once=
..</div><div><br></div><div>However, I am perfectly happy for it to be autom=
atic, but I kept it in so others have to explicitly choose to remove it aft=
er considering these issues.</div><div>&nbsp;</div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div>* Drop the yield(type) expressio=
n support, and simply allow plain yield (or yield() ) as an expression: the=
 input type should be static the same way the output is: if "yield&nbsp; 1;=
 yield "foo"; " is not legal, neither should be "auto x =3D yield(int); aut=
o y =3D&nbsp; yield(char *);". As far as I can tell, yield(type) requires r=
untime type checking which not only seems an unecessary overhead but can le=
ad to runtime failures. Polymoprhism in the input/output type should be exp=
licit by yielding/receiving the equivalent of a boost::variant, boost::any.=
<br>* I'm not a big fan of the "f.wanted() =3D x" syntax to pass parameters=
 to the coroutine, I would have preferred the plain "f(x)", but I understan=
d that causes other problems.<br></div></div></blockquote><div><br></div><d=
iv>These two points are kind of related so I'll address them as one, but wo=
rking backwards.</div><div><br></div><div>First, "f(x)" actually works alre=
ady because the lambda is still a function object. The example at the end o=
f section 7 uses this approach.</div><div><br></div><div>The "wanted" funct=
ion on the other hand is needed to support composition of sub-generators th=
at return different types (i'm thinking async operations here). For example=
:</div><div><br></div><div>&nbsp; []() resumable</div><div>&nbsp; {</div><d=
iv>&nbsp; &nbsp; std::size_t n =3D yield from async_op_returning_a_size();<=
/div><div>&nbsp; &nbsp; std::string s =3D yield from async_op_returning_a_s=
tring();</div><div>&nbsp; }</div><div><br></div><div>In python the async I/=
O framework effectively send()s the result of an operation to the generator=
 and it passes it onwards to the innermost sub-generator, but python is als=
o dynamically typed and lets us mix the different generators without furthe=
r thought. We need some form of dynamic typing to do the same in C++, and a=
s this is a core use case of the facility i don't think it would be good to=
 defer the polymorphism to a library type.</div><div><br></div><div>In the =
snippet above, the async_op_returning_a_size() function already "knows" tha=
t it wants a size_t result, so there's actually no possibility to get the t=
ypes wrong at runtime. The runtime check is not actually used or required i=
n this case. There is also no extra runtime overhead in this case because t=
he wanted() of the outer generator already has to forward the call to the w=
anted() of the currently active sub-generator.</div><div><br></div><div>How=
ever, what I realised after submitting the paper is that the "x =3D yield (=
int)" syntax is technically superfluous. You could instead replace it with =
a library type which is itself a generator, e.g. "x =3D yield from want&lt;=
int&gt;()". The generator returned by want&lt;int&gt;() would look similar =
to the async_read_generator in section 11.</div><div><br></div><div>Cheers,=
</div><div>Chris</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_6312_344266244.1413458290222--

.

On 16 October 2014 14:18,  <chris.kohlhoff@gmail.com> wrote:
>> a vote for N4244 from me as well: another great paper from Christopher
>> Kohlhoff.
> Thanks!


My 0.02 as well - I have been bugging the resumable function crowd to try and
come up with something more generic than a facility so closely tied to
std::future.
As far as I've seen, they have failed to do so. Your paper seems to achieve
that goal, so I consider it a godsend. Hopefully it will at least provide useful
input to the discussion so that we don't end up painting ourselves in a
non-extensible corner.

--

---
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_565_476559201.1413530504112
Content-Type: text/plain; charset=UTF-8

On Thursday, October 16, 2014 4:46:33 AM UTC-7, Ville Voutilainen wrote:
>
> My 0.02 as well - I have been bugging the resumable function crowd to try
> and
> come up with something more generic than a facility so closely tied to
> std::future.
>

Thoughts on n4134? It appears to be even more generic to me.

In particular, N4134 doesn't rely on exceptions for termination (it leaves
that behavior to the library author) while N4244 does. Mandatory exceptions
make this whole feature unusable for a number of important C++ user bases
that either choose or are required to operate with -fno-exceptions or
equivalent.

--

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

<div dir=3D"ltr">On Thursday, October 16, 2014 4:46:33 AM UTC-7, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">My 0.02 as well =
- I have been bugging the resumable function crowd to try and
<br>come up with something more generic than a facility so closely tied to
<br>std::future.&nbsp;<br></blockquote><div>&nbsp;</div><div>Thoughts on n4=
134? It appears to be even more generic to me.</div><div><br></div><div>In =
particular, N4134 doesn't rely on exceptions for termination (it leaves tha=
t behavior to the library author) while N4244 does. Mandatory exceptions ma=
ke this whole feature unusable for a number of important C++ user bases tha=
t either choose or are required to operate with -fno-exceptions or equivale=
nt.</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_565_476559201.1413530504112--

.

------=_Part_707_605507880.1413536922232
Content-Type: text/plain; charset=UTF-8



On Friday, October 17, 2014 6:21:44 PM UTC+11, Sean Middleditch wrote:
>
> In particular, N4134 doesn't rely on exceptions for termination (it leaves
> that behavior to the library author) while N4244 does. Mandatory exceptions
> make this whole feature unusable for a number of important C++ user bases
> that either choose or are required to operate with -fno-exceptions or
> equivalent.
>

The proposal does not "rely" on exceptions for termination. The
alternatives are discussed in section 4. If you don't want the exception
then:

- don't let your resumable lambda fall off the end
- don't invoke a terminal state resumable lambda

However, if people would prefer not to have the exception at all then we
simply have to state that you aren't allowed to fall off the end, and that
invoking a terminal state lambda is UB (just like dereferencing an end
iterator). That design is fine by me too, maybe even preferred since then
resumable lambdas as a language feature don't need any library support. It
does not change the proposal in any fundamental way.

Cheers,
Chris

--

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

<div dir=3D"ltr"><br><br>On Friday, October 17, 2014 6:21:44 PM UTC+11, Sea=
n Middleditch 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"><div>In particular, N4134 doesn't rely on exceptions for terminati=
on (it leaves that behavior to the library author) while N4244 does. Mandat=
ory exceptions make this whole feature unusable for a number of important C=
++ user bases that either choose or are required to operate with -fno-excep=
tions or equivalent.</div></div></blockquote><div><br></div><div>The propos=
al does not "rely" on exceptions for termination. The alternatives are disc=
ussed in section 4. If you don't want the exception then:</div><div><br></d=
iv><div>- don't let your resumable lambda fall off the end</div><div>- don'=
t invoke a terminal state resumable lambda&nbsp;</div><div><br></div><div>H=
owever, if people would prefer not to have the exception at all then we sim=
ply have to state that you aren't allowed to fall off the end, and that inv=
oking a terminal state lambda is UB (just like dereferencing an end iterato=
r). That design is fine by me too, maybe even preferred since then resumabl=
e lambdas as a language feature don't need any library support. It does not=
 change the proposal in any fundamental way.</div><div><br></div><div>Cheer=
s,</div><div>Chris</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_707_605507880.1413536922232--

.

On 17 October 2014 10:21, Sean Middleditch <sean.middleditch@gmail.com> wrote:
> On Thursday, October 16, 2014 4:46:33 AM UTC-7, Ville Voutilainen wrote:
>>
>> My 0.02 as well - I have been bugging the resumable function crowd to try
>> and
>> come up with something more generic than a facility so closely tied to
>> std::future.
>
>
> Thoughts on n4134? It appears to be even more generic to me.

Well, not to me - it still seems to require a shared-semantics return type,
which, while more generic than just using a future, is still not as
non-intrusive
as coroutines in Nat Goodspeed's proposal are or as the resumable
lambdas in Chris's proposal are. If I understand the proposals correctly, that
is - I have read the latest ones for resumable functions rather superficially.

--

---
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_482_175771334.1413540214096
Content-Type: text/plain; charset=UTF-8



On Friday, October 17, 2014 10:25:12 AM UTC+1, Ville Voutilainen wrote:
>
> On 17 October 2014 10:21, Sean Middleditch <sean.mid...@gmail.com
> <javascript:>> wrote:
> > On Thursday, October 16, 2014 4:46:33 AM UTC-7, Ville Voutilainen wrote:
> >>
> >> My 0.02 as well - I have been bugging the resumable function crowd to
> try
> >> and
> >> come up with something more generic than a facility so closely tied to
> >> std::future.
> >
> >
> > Thoughts on n4134? It appears to be even more generic to me.
>
> Well, not to me - it still seems to require a shared-semantics return
> type,
> which, while more generic than just using a future, is still not as
> non-intrusive
> as coroutines in Nat Goodspeed's proposal are or as the resumable
> lambdas in Chris's proposal are. If I understand the proposals correctly,
> that
> is - I have read the latest ones for resumable functions rather
> superficially.
>


additonally, if I'm reading the spec correctly, n4134 coroutines are
type-erased and their frame is heap allocated. Finally the way that async
functions are handled seems more straight forward in Chris' proposal (whose
async protocol is completely orthogonal and general).

-- gpd

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Friday, October 17, 2014 10:25:12 AM UTC+1, Vil=
le Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 17 Oct=
ober 2014 10:21, Sean Middleditch &lt;<a href=3D"javascript:" target=3D"_bl=
ank" gdf-obfuscated-mailto=3D"FWiLpEci-jwJ" onmousedown=3D"this.href=3D'jav=
ascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;">=
sean.mid...@gmail.com</a>&gt; wrote:
<br>&gt; On Thursday, October 16, 2014 4:46:33 AM UTC-7, Ville Voutilainen =
wrote:
<br>&gt;&gt;
<br>&gt;&gt; My 0.02 as well - I have been bugging the resumable function c=
rowd to try
<br>&gt;&gt; and
<br>&gt;&gt; come up with something more generic than a facility so closely=
 tied to
<br>&gt;&gt; std::future.
<br>&gt;
<br>&gt;
<br>&gt; Thoughts on n4134? It appears to be even more generic to me.
<br>
<br>Well, not to me - it still seems to require a shared-semantics return t=
ype,
<br>which, while more generic than just using a future, is still not as
<br>non-intrusive
<br>as coroutines in Nat Goodspeed's proposal are or as the resumable
<br>lambdas in Chris's proposal are. If I understand the proposals correctl=
y, that
<br>is - I have read the latest ones for resumable functions rather superfi=
cially.
<br></blockquote><div><br><br>additonally, if I'm reading the spec correctl=
y, n4134 coroutines are type-erased and their frame is heap allocated. Fina=
lly the way that async functions are handled seems more straight forward in=
 Chris' proposal (whose async protocol is completely orthogonal and general=
).<br><br>-- gpd<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_482_175771334.1413540214096--

.

On Fri, Oct 17, 2014 at 2:08 AM,  <chris.kohlhoff@gmail.com> wrote:
> The proposal does not "rely" on exceptions for termination. The alternatives
> are discussed in section 4. If you don't want the exception then:

Ah, sincere apologies; I had only skimmed the proposal and didn't see
the discussion on alternatives. I'll look into it more deeply today.

>
> - don't let your resumable lambda fall off the end
> - don't invoke a terminal state resumable lambda

What does the user lose if they can't do this? Nothing of value?

> However, if people would prefer not to have the exception at all then we
> simply have to state that you aren't allowed to fall off the end, and that
> invoking a terminal state lambda is UB (just like dereferencing an end
> iterator). That design is fine by me too, maybe even preferred since then
> resumable lambdas as a language feature don't need any library support. It
> does not change the proposal in any fundamental way.

I'm all for anything that keeps turning exceptions off "safe" to do,
in so far as it's safe today at least (that is, everything in the core
language still works without degradation of functionality).

>
> Cheers,
> Chris
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/y24v-O-BQEw/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.



--
Sean Middleditch
http://seanmiddleditch.com

--

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

.

The alternatives to exceptions seem fine after reading them. So long as a r=
esumable lambda can be defined as noexcept and still work for all interesti=
ng use cases, I think it'll be fine.

Looking over the proposal in more detail, section 9 is also standing out. I=
t's a new language-level dependency on RTTI.

A lot of projects disable and replace RTTI. One big reason is speed, which =
should be of concern to a language facility like this.

The alternative here is of course requiring that yield expressions are all =
of uniform type so static type checking can replace the dynamic type checki=
ng. This is not a significant reduction of functionality as anyone needing =
to accept multiple input types to resumed functions can use a library varia=
nt type (and get all the usual benefits of variants vs dynamic_cast).=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/.

.

On 17 October 2014 22:41, Sean Middleditch <sean.middleditch@gmail.com> wrote:
> Looking over the proposal in more detail, section 9 is also standing out. It's a new language-level dependency on RTTI.

No - _parts_ of section 9 use RTTI. You do not have to use the
wanted_type getter at
all, if you're ok with programming at the risk of getting UB. The
yield(type) itself does
not require RTTI, nor does foo.wanted<type>.

--

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

.

On Fri, Oct 17, 2014 at 12:47 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 17 October 2014 22:41, Sean Middleditch <sean.middleditch@gmail.com> wrote:
>> Looking over the proposal in more detail, section 9 is also standing out. It's a new language-level dependency on RTTI.
>
> No - _parts_ of section 9 use RTTI. You do not have to use the
> wanted_type getter at
> all, if you're ok with programming at the risk of getting UB. The
> yield(type) itself does
> not require RTTI, nor does foo.wanted<type>.

So you're saying the suggested alternative is to be type unsafe? Why
would you want to accept that instead of the solution I suggested?

--
Sean Middleditch
http://seanmiddleditch.com

--

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

.

On 18 October 2014 00:40, Sean Middleditch <sean@middleditch.us> wrote:
> So you're saying the suggested alternative is to be type unsafe? Why
> would you want to accept that instead of the solution I suggested?

Just because the yields would be uniform will not give type safety
between the caller
of the lambda type and the lambda definition, since those can be in different
translation units. You would additionally need the type to be encoded in the
value-passing mechanism of the resumable lambda. That has ABI consequences.

That is, of course technically doable. Whether it's better than what
the proposal suggests is
another matter, and I think it's too early to say.

--

---
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_1307_1764134996.1413584302992
Content-Type: text/plain; charset=UTF-8



On Saturday, October 18, 2014 6:41:51 AM UTC+11, Sean Middleditch wrote:
>
> The alternatives to exceptions seem fine after reading them. So long as a
> resumable lambda can be defined as noexcept and still work for all
> interesting use cases, I think it'll be fine.
>
> Looking over the proposal in more detail, section 9 is also standing out.
> It's a new language-level dependency on RTTI.
>
> A lot of projects disable and replace RTTI. One big reason is speed, which
> should be of concern to a language facility like this.
>
> The alternative here is of course requiring that yield expressions are all
> of uniform type so static type checking can replace the dynamic type
> checking. This is not a significant reduction of functionality as anyone
> needing to accept multiple input types to resumed functions can use a
> library variant type (and get all the usual benefits of variants vs
> dynamic_cast).
>
I mentioned this in my earlier reply to Giovanni, but if you want a uniform
input you can still use the function call operator. The
wanted()/wanted_type() stuff is there to support composition of sub
generators that deal in dissimilar inputs. Using a library variant type
would be an unnecessary overhead in cases where these sub generators are
async operations, since the sub generator is using wanted() to communicate
with its future self, i.e. it knows the wanted type at both ends and no
runtime type checks are required.

Cheers,
Chris

--

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

<div dir=3D"ltr"><br><br>On Saturday, October 18, 2014 6:41:51 AM UTC+11, S=
ean Middleditch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The alte=
rnatives to exceptions seem fine after reading them. So long as a resumable=
 lambda can be defined as noexcept and still work for all interesting use c=
ases, I think it'll be fine.<p>Looking over the proposal in more detail, se=
ction 9 is also standing out. It's a new language-level dependency on RTTI.=
</p><p>A lot of projects disable and replace RTTI. One big reason is speed,=
 which should be of concern to a language facility like this.</p><p>The alt=
ernative here is of course requiring that yield expressions are all of unif=
orm type so static type checking can replace the dynamic type checking. Thi=
s is not a significant reduction of functionality as anyone needing to acce=
pt multiple input types to resumed functions can use a library variant type=
 (and get all the usual benefits of variants vs dynamic_cast).</p></blockqu=
ote><div>I mentioned this in my earlier reply to Giovanni, but if you want =
a uniform input you can still use the function call operator. The wanted()/=
wanted_type() stuff is there to support composition of sub generators that =
deal in dissimilar inputs. Using a library variant type would be an unneces=
sary overhead in cases where these sub generators are async operations, sin=
ce the sub generator is using wanted() to communicate with its future self,=
 i.e. it knows the wanted type at both ends and no runtime type checks are =
required.<br></div><div><br></div><div>Cheers,</div><div>Chris</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_1307_1764134996.1413584302992--

.

Hmm, alright, I must just be missing something in my understanding. It will probably help when there's a version I can get my hands on and try to use to solve less example-y problems.

Again, so long as the core language stays fully functional with all the recurring restrictions found in game dev in place, I'm happy. :)

--

---
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_13_2026314405.1413634999269
Content-Type: text/plain; charset=UTF-8

Ville,

Have you seen N4134? Fully open. Not tied to the future or any particular
abstraction.
Can handle reactive style streams, future like things, generators,
asynchronous generators, kernel i/o request packets.
Essentially, library writer's paradise. Compiler gives you efficient
suspend and resume. You provide the rest.

Here are some examples from N4134:

     squares = (x*x for x in S) // python

*auto* squares = [&]{ *for*(x:S) *yield* x*x;} ; // C++

async_generator<int> Ticks()
{
       for(int tick = 0;; ++tick)

{
             yield tick;

await sleep_for(1ms);

}

}


goroutine pusher(channel<int>& left, channel<int>& right) {

       for (;;) {

              auto val = await left.pull();

              await right.push(val + 1);

       }

}






On Thursday, October 16, 2014 4:46:33 AM UTC-7, Ville Voutilainen wrote:

> On 16 October 2014 14:18,  <chris.k...@gmail.com <javascript:>> wrote:
> >> a vote for N4244 from me as well: another great paper from Christopher
> >> Kohlhoff.
> > Thanks!
>
>
> My 0.02 as well - I have been bugging the resumable function crowd to try
> and
> come up with something more generic than a facility so closely tied to
> std::future.
> As far as I've seen, they have failed to do so. Your paper seems to
> achieve
> that goal, so I consider it a godsend. Hopefully it will at least provide
> useful
> input to the discussion so that we don't end up painting ourselves in a
> non-extensible corner.
>

--

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

<div dir=3D"ltr"><div>Ville, </div><div><br></div><div>Have you seen N4134?=
 Fully open. Not tied to the future or any particular abstraction. </div><d=
iv>Can handle reactive style streams, future like things, generators, async=
hronous generators, kernel i/o request packets. </div><div>Essentially, lib=
rary writer's paradise. Compiler gives you efficient suspend and resume. Yo=
u provide the rest.</div><div><br></div><div>Here&nbsp;are&nbsp;some exampl=
es from N4134:</div><div><br></div><div><font color=3D"#000000" face=3D"Tim=
es New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 8pt; text-indent: 0.5in;"><span style=3D=
"line-height: 107%; font-family: Courier; font-size: 10pt;"><font color=3D"=
#000000">&nbsp;&nbsp;&nbsp;&nbsp; squares =3D (x*x
for x in S) // python</font></span></p><font color=3D"#000000" face=3D"Time=
s New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 8pt; text-indent: 0.5in;"><font color=3D=
"#000000"><b><span style=3D"line-height: 107%; font-family: Courier; font-s=
ize: 10pt;">auto</span></b><span style=3D"line-height: 107%; font-family: C=
ourier; font-size: 10pt;"> squares =3D [&amp;]{ <b>for</b>(x:S)
<b>yield</b> x*x;} ;</span><font face=3D"Calibri" size=3D"3"> </font><span =
style=3D"line-height: 107%; font-family: Courier; font-size: 10pt;">// C++<=
/span></font></p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3=
">

</font><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: rgb(33, 111, 133); mso-highlight: white;"><font face=3D"Consol=
as" size=3D"2">async_generator</font></span><span style=3D"background: whit=
e; mso-highlight: white;"><font size=3D"2"><font face=3D"Consolas"><font co=
lor=3D"#000000">&lt;</font><span style=3D"color: blue;">int</span><font col=
or=3D"#000000">&gt; </font><span style=3D"color: rgb(136, 0, 0);">Ticks</sp=
an></font></font><font size=3D"2"><font face=3D"Consolas"><font color=3D"#0=
00000">() <br>
{<br>
<span style=3D"mso-tab-count: 1;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </sp=
an></font><span style=3D"color: blue;">for</span><font color=3D"#000000">(<=
/font><span style=3D"color: blue;">int</span><font color=3D"#000000"> tick =
=3D 0</font><span style=3D"color: navy;">;; ++tick</span><font color=3D"#00=
0000">)
</font></font></font></span></p><font color=3D"#000000" face=3D"Times New R=
oman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in; text-indent: 0.5in;"><span st=
yle=3D"background: white; mso-highlight: white;"><font size=3D"2"><font fac=
e=3D"Consolas"><font color=3D"#000000">{<br>
<span style=3D"mso-tab-count: 1;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;</span><span style=3D"mso-tab-count: 1;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;</span></font><span style=3D"color: blue;">yield </span><font color=3D"#=
000000">tick;</font></font></font></span></p><font color=3D"#000000" face=
=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 1in; text-indent: 0.5in;"><font size=
=3D"2"><font face=3D"Consolas"><span style=3D"background: white; color: blu=
e; mso-highlight: white;">await </span><span style=3D"background: white; ms=
o-highlight: white;"><font color=3D"#000000">sleep_for(1ms);<span style=3D"=
mso-tab-count: 1;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font></span></fo=
nt></font></p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in; text-indent: 0.5in;"><span st=
yle=3D"background: white; mso-highlight: white;"><font color=3D"#000000" fa=
ce=3D"Consolas" size=3D"2">}</font></span></p><font color=3D"#000000" face=
=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; mso-highlight: white;"><font color=3D"#000000" face=3D"Consolas" size=
=3D"2">}</font></span></p><p style=3D"margin: 0in 0in 0pt 0.5in;"><span sty=
le=3D"background: white; mso-highlight: white;"><br></span></p><span style=
=3D"background: white; mso-highlight: white;"><font color=3D"#000000" face=
=3D"Consolas" size=3D"2"><p style=3D"margin: 0in 0in 0pt 0.5in;"><span styl=
e=3D"background: white; mso-highlight: white;"><font size=3D"2">goroutine p=
usher(channel&lt;<span style=3D"color: blue;">int</span>&gt;&amp;
left, channel&lt;<span style=3D"color: blue;">int</span>&gt;&amp; right) </=
font></span><span style=3D"background: white; mso-highlight: white;"><font =
size=3D"2">{</font></span></p><p style=3D"margin: 0in 0in 0pt 0.5in;"><font=
 face=3D"Times New Roman" size=3D"3">

</font><span style=3D"background: white; mso-highlight: white;"><font size=
=3D"2"><span style=3D"mso-tab-count: 1;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span><span style=3D"color: blue;">for</span> (;;) {</font></span></p><=
p style=3D"margin: 0in 0in 0pt 0.5in;"><font face=3D"Times New Roman" size=
=3D"3">

</font><span style=3D"background: white; mso-highlight: white;"><font size=
=3D"2"><span style=3D"mso-tab-count: 2;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style=3D"color: b=
lue;">auto</span> val =3D <span style=3D"color: blue;">await</span>
left.pull();</font></span></p><p style=3D"margin: 0in 0in 0pt 0.5in;"><font=
 face=3D"Times New Roman" size=3D"3">

</font><span style=3D"background: white; mso-highlight: white;"><font size=
=3D"2"><span style=3D"mso-tab-count: 2;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style=3D"color: b=
lue;">await</span> right.push(val + 1);</font></span></p><p style=3D"margin=
: 0in 0in 0pt 0.5in;"><font face=3D"Times New Roman" size=3D"3">
</font><span style=3D"background: white; mso-highlight: white;"><font size=
=3D"2"><span style=3D"mso-tab-count: 1;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; </span>}</font></span></p><p style=3D"margin: 0in 0in 0pt 0.5in;"><font =
face=3D"Times New Roman" size=3D"3">

</font><span style=3D"background: white; mso-highlight: white;"><font size=
=3D"2">}</font></span></p><p style=3D"margin: 0in 0in 0pt 0.5in;"><font fac=
e=3D"Times New Roman" size=3D"3">

<br></font></p></font><p style=3D"margin: 0in 0in 0pt 0.5in;"><br></p></spa=
n><p style=3D"margin: 0in 0in 0pt 0.5in;"><br></p><font color=3D"#000000" f=
ace=3D"Times New Roman" size=3D"3">

</font><br><br>On Thursday, October 16, 2014 4:46:33 AM UTC-7, Ville Voutil=
ainen wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;">On 16 October 2014 14:18, &n=
bsp;&lt;<a onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"y5jUdMRSVHAJ">chris.k...@gmail.com</a>&gt;=
 wrote:
<br>&gt;&gt; a vote for N4244 from me as well: another great paper from Chr=
istopher
<br>&gt;&gt; Kohlhoff.
<br>&gt; Thanks!
<br>
<br>
<br>My 0.02 as well - I have been bugging the resumable function crowd to t=
ry and
<br>come up with something more generic than a facility so closely tied to
<br>std::future.
<br>As far as I've seen, they have failed to do so. Your paper seems to ach=
ieve
<br>that goal, so I consider it a godsend. Hopefully it will at least provi=
de useful
<br>input to the discussion so that we don't end up painting ourselves in a
<br>non-extensible corner.
<br></blockquote></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_13_2026314405.1413634999269--

.

------=_Part_136_750746810.1413635494008
Content-Type: text/plain; charset=UTF-8

Nat's and Oliver proposal is about stackful coroutines where unit of
suspension is a user-mode thread / fiber rather than a particular function.
Fibers are more powerful than coroutines, but they carry higher cost both
in memory footprint and the cost of the context switch.

N4244 and N4134 are in the stackless coroutine space.
N4134 has a lambda* (lambda with its state including not only capture but
also automatic variables of operator()()), but it is hidden behind the ramp
function that does allocation to have a stationary coroutine frame. That
design decision removes restrictions on what you can or cannot write in the
body of the coroutine while allowing optimizer to get rid of heap
allocations where lifetime of the coroutine is fully contained in the
calling function.

On Friday, October 17, 2014 2:25:12 AM UTC-7, Ville Voutilainen wrote:

> On 17 October 2014 10:21, Sean Middleditch <sean.mid...@gmail.com
> <javascript:>> wrote:
> > On Thursday, October 16, 2014 4:46:33 AM UTC-7, Ville Voutilainen wrote:
> >>
> >> My 0.02 as well - I have been bugging the resumable function crowd to
> try
> >> and
> >> come up with something more generic than a facility so closely tied to
> >> std::future.
> >
> >
> > Thoughts on n4134? It appears to be even more generic to me.
>
> Well, not to me - it still seems to require a shared-semantics return
> type,
> which, while more generic than just using a future, is still not as
> non-intrusive
> as coroutines in Nat Goodspeed's proposal are or as the resumable
> lambdas in Chris's proposal are. If I understand the proposals correctly,
> that
> is - I have read the latest ones for resumable functions rather
> superficially.
>

--

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

<div dir=3D"ltr"><div>Nat's and Oliver proposal is about stackful coroutine=
s where unit of suspension is a user-mode thread / fiber rather than a part=
icular function.</div><div>Fibers are more powerful than coroutines, but th=
ey carry higher cost both in memory footprint and the cost of the context s=
witch.</div><div><br></div><div>N4244 and N4134 are in the stackless corout=
ine space.</div><div>N4134 has a lambda* (lambda with its state including n=
ot only capture but also automatic variables of operator()()), but&nbsp;it =
is hidden behind the ramp function that does allocation to have a stationar=
y coroutine frame. That design decision removes restrictions on what you ca=
n or cannot write in the body of the coroutine while allowing optimizer to =
get rid of heap allocations where lifetime of the coroutine is fully contai=
ned in the calling function.<br><br>On Friday, October 17, 2014 2:25:12 AM =
UTC-7, Ville Voutilainen wrote:</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(2=
04, 204, 204); border-left-width: 1px; border-left-style: solid;">On 17 Oct=
ober 2014 10:21, Sean Middleditch &lt;<a onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';return true;" hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"FWiLpEci-jwJ">=
sean.mid...@gmail.com</a>&gt; wrote:
<br>&gt; On Thursday, October 16, 2014 4:46:33 AM UTC-7, Ville Voutilainen =
wrote:
<br>&gt;&gt;
<br>&gt;&gt; My 0.02 as well - I have been bugging the resumable function c=
rowd to try
<br>&gt;&gt; and
<br>&gt;&gt; come up with something more generic than a facility so closely=
 tied to
<br>&gt;&gt; std::future.
<br>&gt;
<br>&gt;
<br>&gt; Thoughts on n4134? It appears to be even more generic to me.
<br>
<br>Well, not to me - it still seems to require a shared-semantics return t=
ype,
<br>which, while more generic than just using a future, is still not as
<br>non-intrusive
<br>as coroutines in Nat Goodspeed's proposal are or as the resumable
<br>lambdas in Chris's proposal are. If I understand the proposals correctl=
y, that
<br>is - I have read the latest ones for resumable functions rather superfi=
cially.
<br></blockquote></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_136_750746810.1413635494008--

.

On 18 October 2014 15:23,  <gornishanov@gmail.com> wrote:
> Ville,
>
> Have you seen N4134? Fully open. Not tied to the future or any particular
> abstraction.

As far as I understood it, the generators/futures/whichever-things the resumable
function of N4134 returns must be shared-semantics types that share
state with the
resumable function itself. Chris's proposal seems to be so that the state
is completely within the lambda, and thus the lambda itself can just return
an int if it so wants to.

Then again, I don't quite see how to return a future<T> with N4244 - I would
expect I need to return a future<T>& and have the future as a capture.

--

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

.

On 18 October 2014 15:31,  <gornishanov@gmail.com> wrote:
> Nat's and Oliver proposal is about stackful coroutines where unit of
> suspension is a user-mode thread / fiber rather than a particular function.
> Fibers are more powerful than coroutines, but they carry higher cost both in
> memory footprint and the cost of the context switch.
>
> N4244 and N4134 are in the stackless coroutine space.
> N4134 has a lambda* (lambda with its state including not only capture but
> also automatic variables of operator()()), but it is hidden behind the ramp
> function that does allocation to have a stationary coroutine frame. That
> design decision removes restrictions on what you can or cannot write in the
> body of the coroutine while allowing optimizer to get rid of heap
> allocations where lifetime of the coroutine is fully contained in the
> calling function.


As far as I understand, N4244 requires no heap allocation. The implementation
can see what is stored in the resumable lambda and can allocate enough space
for it.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_272_269290886.1413638020325
Content-Type: text/plain; charset=UTF-8

On Saturday, October 18, 2014 5:41:55 AM UTC-7, Ville Voutilainen wrote:

>
> resumable function itself. Chris's proposal seems to be so that the state
> is completely within the lambda, and thus the lambda itself can just
> return
> an int if it so wants to. .


I started the design of N4134 with an attempt to have a generalized
lambda*, but, felt that allowing lambda state to be copyable / movable
after it started running brings undue restrictions on what you can do in
the body of the lambda*. Thus my desire to give a coroutine frame a stable
location. One way to think of N4134 is that it is a small ramp around a
resumable lambda that allocates it and gives out a handle of some sort. It
also allows the library to select what kind of "coroutine return object" to
use to tie to the resumable lambda and what kind of allocator to use.

Allocation can be elided when the lifetime of the coroutine is fully
contained with the lifetime of the caller. (Frequently in generator style
coroutines).

I view the coroutine as a generalization of subroutine (call / return) that
gets two extra operations (suspend / resume). Call and return in the N4134
make it indistinguishable from any other function / lambda with the same
signature. The fact that it is implemented as a coroutine is an
implementation detail. When generalizing a subroutine, "return = give
result at completion", need to be treated with care, as in asymmetric
coroutines, suspend results in giving back control to the caller (just like
with regular routines), thus there have to be another mechanism to learn
about coroutine completion and getting an eventual value.

In that sense, N4134 can return int, as 4244, but it would not be very
interesting. So, the intention is that library designer will implement a
reasonable high-level abstraction, such as generator, or lighweigh_task,
etc. It is also possible to apply N4134 to existing types such as
boost::future.

For example, generator<T> exposes an abstraction of iterable<T> and thus
can be used anywhere where input iteratable is allowed.
Lifetime of the coroutine is bound to the lifetime of the generator<T>.

future<T> and boost::future<T> have a concept of eventual value and are
thus, suitable coroutine return objects, though they are not very good for
managing lifetime of the coroutine.


On Saturday, October 18, 2014 5:41:55 AM UTC-7, Ville Voutilainen wrote:

>
> resumable function itself. Chris's proposal seems to be so that the state
> is completely within the lambda, and thus the lambda itself can just
> return
> an int if it so wants to.
> .


>

--

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

<div dir=3D"ltr"><div><div><div>On Saturday, October 18, 2014 5:41:55 AM UT=
C-7, Ville Voutilainen wrote:</div><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;"><br>resuma=
ble function itself. Chris's proposal seems to be so that the state <br>is =
completely within the lambda, and thus the lambda itself can just return <b=
r>an int if it so wants to. .</blockquote></div><div><br></div><div>I start=
ed the design of N4134 with an attempt to have a generalized lambda*, but, =
felt that allowing lambda state&nbsp;to be copyable / movable after it star=
ted running brings undue restrictions on what you can do in the body of the=
 lambda*. Thus my desire to give a coroutine frame a stable location. One w=
ay to think of N4134 is that it is a small ramp around a resumable lambda t=
hat allocates it and gives out a handle of some sort. It also allows the li=
brary to select what kind of "coroutine return object" to use to tie to the=
 resumable lambda and what kind of allocator to use.</div></div><div><br></=
div><div>Allocation can be elided when the lifetime of the coroutine is ful=
ly contained with the lifetime of the caller. (Frequently in generator styl=
e coroutines).</div><div><br></div><div>I view the coroutine as a generaliz=
ation of subroutine (call / return) that gets two extra operations (suspend=
&nbsp;/ resume). Call and return in the N4134 make it indistinguishable fro=
m any other function / lambda with the same signature. The fact that it is =
implemented as a coroutine is an implementation detail. When generalizing a=
 subroutine, "return =3D give result at completion", need to be treated wit=
h care, as in asymmetric coroutines, suspend results in giving back control=
 to the caller (just like with regular routines), thus there have to be ano=
ther mechanism to learn about coroutine completion and getting an eventual =
value.</div><div><br></div><div>In that sense, N4134 can return int, as 424=
4, but it would not be very interesting. So, the intention is that library =
designer will implement a reasonable high-level abstraction, such as genera=
tor, or lighweigh_task, etc. It is also possible to apply N4134 to existing=
 types such as boost::future.</div><div><br></div><div>For example, generat=
or&lt;T&gt; exposes an abstraction of iterable&lt;T&gt; and thus can be use=
d anywhere where input iteratable is allowed.</div><div>Lifetime of the cor=
outine is bound to the lifetime of the generator&lt;T&gt;. </div><div><br><=
/div><div>future&lt;T&gt; and boost::future&lt;T&gt; have a concept of even=
tual value and are thus, suitable coroutine return objects, though they are=
 not very good for managing lifetime of the coroutine.</div><div><br><br>On=
 Saturday, October 18, 2014 5:41:55 AM UTC-7, Ville Voutilainen wrote:</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;"><br>resumable function itself. Chris's propos=
al seems to be so that the state
<br>is completely within the lambda, and thus the lambda itself can just re=
turn
<br>an int if it so wants to.
<br>
..</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-l=
eft-width: 1px; border-left-style: solid;">
<br></blockquote><br><blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;"></blockquote></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_272_269290886.1413638020325--

.

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

On Saturday, October 18, 2014 5:44:11 AM UTC-7, Ville Voutilainen wrote:
>
> As far as I understand, N4244 requires no heap allocation. The=20
> implementation=20
> can see what is stored in the resumable lambda and can allocate enough=20
> space=20
> for it.


Correct. Ignoring stylistic differences. For me, N4244 and N4134 differ on=
=20
one design point.=20

How important is to have a stationary coroutine frame once it start running=
?

N4134: Very important, thus allocation of the coroutine by default, but=20
optimizable in scenarios where lifetime of the coroutine is fully contained=
=20
in the lifetime of its caller. Has some syntactix sugar around lambda*
N4244: value semantics. Copying/moving sometimes unsafe (depending on what=
=20
coroutine body is doing). Just lambda*

(I am using lambda* instead of N4244 resumable lambdas, since N4134 applies=
=20
to all functions (including the operator()() of the lambda, thus allowing=
=20
resumable lambdas as well).

Here are side by side example of N4244 lambdas and N4134 lambdas (in both=
=20
cases there is no heap allocation as the lifetime of the coroutine is fully=
=20
within the lifetime of the caller function)

*Section 4. Writing Simple Generators*

=20

*N4244:*

auto g =3D [n =3D int(10)]() resumable {

    std::cout << "Counting down from" << n << "\n";

    while (n > 0) {

        yield n;

        n -=C2=AD=3D 1;

    }

};

while (!g.is_terminal()) std::cout << g() << "\n";

=20

*N4134:*

auto g =3D [n =3D int(10)] {

    std::cout << "Counting down from" << n << "\n";

    while (n > 0) {

        yield n;

        n -=C2=AD=3D 1;

    }

};

for (x : g()) std::cout << x << "\n";

=20

or

auto g =3D [](int n) {

    std::cout << "Counting down from" << n << "\n";

    while (n > 0) {

        yield n;

        n -=C2=AD=3D 1;

    }

};

for (x : g(10)) std::cout << x << "\n";

=20

or

generator<int> g(int n) {

    std::cout << "Counting down from" << n << "\n";

    while (n > 0) {

        yield n;

        n -=C2=AD=3D 1;

    }

};

for (x : g(10)) std::cout << x << "\n";

=20

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

<div dir=3D"ltr"><div>On Saturday, October 18, 2014 5:44:11 AM UTC-7, Ville=
 Voutilainen 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;">As far as I understand, N42=
44 requires no heap allocation. The implementation <br>can see what is stor=
ed in the resumable lambda and can allocate enough space <br>for it.</block=
quote></div><div><br></div><div>Correct. Ignoring&nbsp;stylistic difference=
s.&nbsp;For me, N4244 and N4134 differ on one design point. </div><div><br>=
</div><div>How important is to have a&nbsp;stationary coroutine&nbsp;frame =
once it start running?</div><div><br></div><div>N4134: Very important, thus=
 allocation of the coroutine by default, but optimizable in scenarios where=
 lifetime of the coroutine is fully contained in the lifetime of its caller=
.. Has some syntactix sugar around lambda*</div><div>N4244: value semantics.=
 Copying/moving sometimes unsafe (depending on what coroutine body is doing=
). Just lambda*</div><div><br></div><div>(I am using lambda* instead of N42=
44 resumable lambdas, since N4134 applies to all functions (including the o=
perator()() of the lambda, thus allowing resumable lambdas as well).</div><=
div><br></div><div>Here are side by side example of N4244 lambdas and N4134=
 lambdas (in both cases there is no heap allocation as the lifetime of the =
coroutine is fully within the lifetime of the caller function)</div><div><b=
r></div><div><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt;"><u><font color=3D"#000000" face=3D=
"Calibri" size=3D"3">Section 4. Writing Simple Generators</font></u></p><fo=
nt color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt;"><font color=3D"#000000" face=3D"Ca=
libri" size=3D"3">&nbsp;</font></p><font color=3D"#000000" face=3D"Times Ne=
w Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt;"><u><font color=3D"#000000" face=3D=
"Calibri" size=3D"3">N4244:</font></u></p><font color=3D"#000000" face=3D"T=
imes New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: blue; font-family: Consolas; font-size: 9.5pt; mso-highlight: =
white;">auto</span><span style=3D"background: white; color: black; font-fam=
ily: Consolas; font-size: 9.5pt; mso-highlight: white;"> g =3D [n =3D </spa=
n><span style=3D"background: white; color: blue; font-family: Consolas; fon=
t-size: 9.5pt; mso-highlight: white;">int</span><span style=3D"background: =
white; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight=
: white;">(10)]() resumable {</span></p><font color=3D"#000000" face=3D"Tim=
es New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp; std::cout &lt;&lt; </span><span style=3D"backgr=
ound: white; color: rgb(163, 21, 21); font-family: Consolas; font-size: 9.5=
pt; mso-highlight: white;">"Counting down from"</span><span style=3D"backgr=
ound: white; color: black; font-family: Consolas; font-size: 9.5pt; mso-hig=
hlight: white;"> &lt;&lt; n &lt;&lt; </span><span style=3D"background: whit=
e; color: rgb(163, 21, 21); font-family: Consolas; font-size: 9.5pt; mso-hi=
ghlight: white;">"\n"</span><span style=3D"background: white; color: black;=
 font-family: Consolas; font-size: 9.5pt; mso-highlight: white;">;</span></=
p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp; </span><span style=3D"background: white; color:=
 blue; font-family: Consolas; font-size: 9.5pt; mso-highlight: white;">whil=
e</span><span style=3D"background: white; color: black; font-family: Consol=
as; font-size: 9.5pt; mso-highlight: white;"> (n &gt; 0) {</span></p><font =
color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style=3D"b=
ackground: white; color: blue; font-family: Consolas; font-size: 9.5pt; mso=
-highlight: white;">yield</span><span style=3D"background: white; color: bl=
ack; font-family: Consolas; font-size: 9.5pt; mso-highlight: white;"> n;</s=
pan></p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; n -&shy;=3D 1;</span></=
p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp; }</span></p><font color=3D"#000000" face=3D"Tim=
es New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">};</span></p><font color=3D"#000000" face=3D"Times New Roman" size=
=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: blue; font-family: Consolas; font-size: 9.5pt; mso-highlight: =
white;">while</span><span style=3D"background: white; color: black; font-fa=
mily: Consolas; font-size: 9.5pt; mso-highlight: white;"> (!g.is_terminal()=
) std::cout
&lt;&lt; g() &lt;&lt; </span><span style=3D"background: white; color: rgb(1=
63, 21, 21); font-family: Consolas; font-size: 9.5pt; mso-highlight: white;=
">"\n"</span><span style=3D"background: white; color: black; font-family: C=
onsolas; font-size: 9.5pt; mso-highlight: white;">;</span></p><font color=
=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt;"><span style=3D"background: white; =
color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight: white=
;">&nbsp;</span></p><font color=3D"#000000" face=3D"Times New Roman" size=
=3D"3">

</font><p style=3D"margin: 0in 0in 0pt;"><u><span style=3D"background: whit=
e; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight: wh=
ite;">N4134:</span></u></p><font color=3D"#000000" face=3D"Times New Roman"=
 size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: blue; font-family: Consolas; font-size: 9.5pt; mso-highlight: =
white;">auto</span><span style=3D"background: white; color: black; font-fam=
ily: Consolas; font-size: 9.5pt; mso-highlight: white;"> g =3D [n =3D </spa=
n><span style=3D"background: white; color: blue; font-family: Consolas; fon=
t-size: 9.5pt; mso-highlight: white;">int</span><span style=3D"background: =
white; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight=
: white;">(10)] {</span></p><font color=3D"#000000" face=3D"Times New Roman=
" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp; std::cout &lt;&lt; </span><span style=3D"backgr=
ound: white; color: rgb(163, 21, 21); font-family: Consolas; font-size: 9.5=
pt; mso-highlight: white;">"Counting down from"</span><span style=3D"backgr=
ound: white; color: black; font-family: Consolas; font-size: 9.5pt; mso-hig=
hlight: white;"> &lt;&lt; n &lt;&lt; </span><span style=3D"background: whit=
e; color: rgb(163, 21, 21); font-family: Consolas; font-size: 9.5pt; mso-hi=
ghlight: white;">"\n"</span><span style=3D"background: white; color: black;=
 font-family: Consolas; font-size: 9.5pt; mso-highlight: white;">;</span></=
p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp; </span><span style=3D"background: white; color:=
 blue; font-family: Consolas; font-size: 9.5pt; mso-highlight: white;">whil=
e</span><span style=3D"background: white; color: black; font-family: Consol=
as; font-size: 9.5pt; mso-highlight: white;"> (n &gt; 0) {</span></p><font =
color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style=3D"b=
ackground: white; color: blue; font-family: Consolas; font-size: 9.5pt; mso=
-highlight: white;">yield</span><span style=3D"background: white; color: bl=
ack; font-family: Consolas; font-size: 9.5pt; mso-highlight: white;"> n;</s=
pan></p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; n -&shy;=3D 1;</span></=
p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp; }</span></p><font color=3D"#000000" face=3D"Tim=
es New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">};</span></p><font color=3D"#000000" face=3D"Times New Roman" size=
=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: blue; font-family: Consolas; font-size: 9.5pt; mso-highlight: =
white;">for</span><span style=3D"background: white; color: black; font-fami=
ly: Consolas; font-size: 9.5pt; mso-highlight: white;"> (x : g()) std::cout=
 &lt;&lt;
x &lt;&lt; </span><span style=3D"background: white; color: rgb(163, 21, 21)=
; font-family: Consolas; font-size: 9.5pt; mso-highlight: white;">"\n"</spa=
n><span style=3D"background: white; color: black; font-family: Consolas; fo=
nt-size: 9.5pt; mso-highlight: white;">;</span></p><font color=3D"#000000" =
face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt;"><font color=3D"#000000" face=3D"Ca=
libri" size=3D"3">&nbsp;</font></p><font color=3D"#000000" face=3D"Times Ne=
w Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt;"><font color=3D"#000000" face=3D"Ca=
libri" size=3D"3">or</font></p><font color=3D"#000000" face=3D"Times New Ro=
man" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: blue; font-family: Consolas; font-size: 9.5pt; mso-highlight: =
white;">auto</span><span style=3D"background: white; color: black; font-fam=
ily: Consolas; font-size: 9.5pt; mso-highlight: white;"> g =3D [](</span><s=
pan style=3D"background: white; color: blue; font-family: Consolas; font-si=
ze: 9.5pt; mso-highlight: white;">int</span><span style=3D"background: whit=
e; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight: wh=
ite;"> n) {</span></p><font color=3D"#000000" face=3D"Times New Roman" size=
=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp; std::cout &lt;&lt; </span><span style=3D"backgr=
ound: white; color: rgb(163, 21, 21); font-family: Consolas; font-size: 9.5=
pt; mso-highlight: white;">"Counting down from"</span><span style=3D"backgr=
ound: white; color: black; font-family: Consolas; font-size: 9.5pt; mso-hig=
hlight: white;"> &lt;&lt; n &lt;&lt; </span><span style=3D"background: whit=
e; color: rgb(163, 21, 21); font-family: Consolas; font-size: 9.5pt; mso-hi=
ghlight: white;">"\n"</span><span style=3D"background: white; color: black;=
 font-family: Consolas; font-size: 9.5pt; mso-highlight: white;">;</span></=
p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp; </span><span style=3D"background: white; color:=
 blue; font-family: Consolas; font-size: 9.5pt; mso-highlight: white;">whil=
e</span><span style=3D"background: white; color: black; font-family: Consol=
as; font-size: 9.5pt; mso-highlight: white;"> (n &gt; 0) {</span></p><font =
color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style=3D"b=
ackground: white; color: blue; font-family: Consolas; font-size: 9.5pt; mso=
-highlight: white;">yield</span><span style=3D"background: white; color: bl=
ack; font-family: Consolas; font-size: 9.5pt; mso-highlight: white;"> n;</s=
pan></p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; n -&shy;=3D 1;</span></=
p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp; }</span></p><font color=3D"#000000" face=3D"Tim=
es New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">};</span></p><font color=3D"#000000" face=3D"Times New Roman" size=
=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: blue; font-family: Consolas; font-size: 9.5pt; mso-highlight: =
white;">for</span><span style=3D"background: white; color: black; font-fami=
ly: Consolas; font-size: 9.5pt; mso-highlight: white;"> (x : g(10)) std::co=
ut
&lt;&lt; x &lt;&lt; </span><span style=3D"background: white; color: rgb(163=
, 21, 21); font-family: Consolas; font-size: 9.5pt; mso-highlight: white;">=
"\n"</span><span style=3D"background: white; color: black; font-family: Con=
solas; font-size: 9.5pt; mso-highlight: white;">;</span></p><font color=3D"=
#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt;"><font color=3D"#000000" face=3D"Ca=
libri" size=3D"3">&nbsp;</font></p><font color=3D"#000000" face=3D"Times Ne=
w Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt;"><font color=3D"#000000" face=3D"Ca=
libri" size=3D"3">or</font></p><font color=3D"#000000" face=3D"Times New Ro=
man" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">generator&lt;</span><span style=3D"background: white; color: blue;=
 font-family: Consolas; font-size: 9.5pt; mso-highlight: white;">int&gt; </=
span><span style=3D"background: white; color: black; font-family: Consolas;=
 font-size: 9.5pt; mso-highlight: white;">g(</span><span style=3D"backgroun=
d: white; color: blue; font-family: Consolas; font-size: 9.5pt; mso-highlig=
ht: white;">int</span><span style=3D"background: white; color: black; font-=
family: Consolas; font-size: 9.5pt; mso-highlight: white;"> n) {</span></p>=
<font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp; std::cout &lt;&lt; </span><span style=3D"backgr=
ound: white; color: rgb(163, 21, 21); font-family: Consolas; font-size: 9.5=
pt; mso-highlight: white;">"Counting down from"</span><span style=3D"backgr=
ound: white; color: black; font-family: Consolas; font-size: 9.5pt; mso-hig=
hlight: white;"> &lt;&lt; n &lt;&lt; </span><span style=3D"background: whit=
e; color: rgb(163, 21, 21); font-family: Consolas; font-size: 9.5pt; mso-hi=
ghlight: white;">"\n"</span><span style=3D"background: white; color: black;=
 font-family: Consolas; font-size: 9.5pt; mso-highlight: white;">;</span></=
p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp; </span><span style=3D"background: white; color:=
 blue; font-family: Consolas; font-size: 9.5pt; mso-highlight: white;">whil=
e</span><span style=3D"background: white; color: black; font-family: Consol=
as; font-size: 9.5pt; mso-highlight: white;"> (n &gt; 0) {</span></p><font =
color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span><span style=3D"b=
ackground: white; color: blue; font-family: Consolas; font-size: 9.5pt; mso=
-highlight: white;">yield</span><span style=3D"background: white; color: bl=
ack; font-family: Consolas; font-size: 9.5pt; mso-highlight: white;"> n;</s=
pan></p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; n -&shy;=3D 1;</span></=
p><font color=3D"#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">&nbsp;&nbsp;&nbsp; }</span></p><font color=3D"#000000" face=3D"Tim=
es New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: black; font-family: Consolas; font-size: 9.5pt; mso-highlight:=
 white;">};</span></p><font color=3D"#000000" face=3D"Times New Roman" size=
=3D"3">

</font><p style=3D"margin: 0in 0in 0pt 0.5in;"><span style=3D"background: w=
hite; color: blue; font-family: Consolas; font-size: 9.5pt; mso-highlight: =
white;">for</span><span style=3D"background: white; color: black; font-fami=
ly: Consolas; font-size: 9.5pt; mso-highlight: white;"> (x : g(10)) std::co=
ut
&lt;&lt; x &lt;&lt; </span><span style=3D"background: white; color: rgb(163=
, 21, 21); font-family: Consolas; font-size: 9.5pt; mso-highlight: white;">=
"\n"</span><span style=3D"background: white; color: black; font-family: Con=
solas; font-size: 9.5pt; mso-highlight: white;">;</span></p><font color=3D"=
#000000" face=3D"Times New Roman" size=3D"3">

</font><p style=3D"margin: 0in 0in 0pt;"><font color=3D"#000000" face=3D"Ca=
libri" size=3D"3">&nbsp;</font></p><font color=3D"#000000" face=3D"Times Ne=
w Roman" size=3D"3">

</font></div><div><br></div><div>&nbsp;</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_1679625196.1413639347077--

.

First of all, I would like to point out that N4134 seems quite a step forward
from the previous resumable function proposals. It's massively better in the
sense that it's more general, so good job on that front!

On 18 October 2014 16:13,  <gornishanov@gmail.com> wrote:
> I started the design of N4134 with an attempt to have a generalized lambda*,
> but, felt that allowing lambda state to be copyable / movable after it
> started running brings undue restrictions on what you can do in the body of
> the lambda*. Thus my desire to give a coroutine frame a stable location. One
> way to think of N4134 is that it is a small ramp around a resumable lambda
> that allocates it and gives out a handle of some sort. It also allows the
> library to select what kind of "coroutine return object" to use to tie to
> the resumable lambda and what kind of allocator to use.

That's all good.

> I view the coroutine as a generalization of subroutine (call / return) that
> gets two extra operations (suspend / resume). Call and return in the N4134
> make it indistinguishable from any other function / lambda with the same
> signature. The fact that it is implemented as a coroutine is an
> implementation detail. When generalizing a subroutine, "return = give result
> at completion", need to be treated with care, as in asymmetric coroutines,
> suspend results in giving back control to the caller (just like with regular
> routines), thus there have to be another mechanism to learn about coroutine
> completion and getting an eventual value.

Agreed.

> In that sense, N4134 can return int, as 4244, but it would not be very
> interesting. So, the intention is that library designer will implement a
> reasonable high-level abstraction, such as generator, or lighweigh_task,
> etc. It is also possible to apply N4134 to existing types such as
> boost::future.

Well, returning ints, while not terribly interesting, is just an example of
a generator returning (well, generating) value-semantic types. There are
fair amounts of use cases for such generators, and they are not necessarily
asynchronous in any way.

> For example, generator<T> exposes an abstraction of iterable<T> and thus can
> be used anywhere where input iteratable is allowed.
> Lifetime of the coroutine is bound to the lifetime of the generator<T>.
> future<T> and boost::future<T> have a concept of eventual value and are
> thus, suitable coroutine return objects, though they are not very good for
> managing lifetime of the coroutine.

Oh, I wouldn't think of them as mechanisms for managing the lifetime of
the coroutine - I would use them when the generator returns a wait handle
for an asynchronous operation and I want to wait on it. ;) The lifetime
of the coroutine itself seems separate from that.

--

---
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_274_1214968910.1413640726474
Content-Type: text/plain; charset=UTF-8

Hi Gor,

It's quite late here so I will not address the other points in this thread
until tomorrow, but I would like to correct this misunderstanding.

On Sunday, October 19, 2014 12:35:47 AM UTC+11, gorni...@gmail.com wrote:
>
> On Saturday, October 18, 2014 5:44:11 AM UTC-7, Ville Voutilainen wrote:
>>
>> As far as I understand, N4244 requires no heap allocation. The
>> implementation
>> can see what is stored in the resumable lambda and can allocate enough
>> space
>> for it.
>
>
> Correct. Ignoring stylistic differences. For me, N4244 and N4134 differ on
> one design point.
>
How important is to have a stationary coroutine frame once it start running?
>

You're right that this is the area in which the two proposals differ, but
you have this backwards.

N4134 *enforces* a stationary frame. As a user of N4134, we don't get a
choice. It also, as a consequence, allocates that frame and hides it from
the user, such as when you said earlier:

Lifetime of the coroutine is bound to the lifetime of the generator<T>.


N4244 *supports* a stationary frame, but does not require it. It also
supports copyable, movable, value-based objects, but it does not require
that either. If you do want to use a stationary frame, you get to choose
exactly where to put it, including embedding it as a data member of another
class.

Earlier you said:

One way to think of N4134 is that it is a small ramp around a resumable
> lambda that allocates it and gives out a handle of some sort.


Which is exactly right. We can implement N4134 semantics on top of N4244,
but we can't do it the other way around because you can't give back what is
already taken away.

Cheers,
Chris

--

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

<div dir=3D"ltr">Hi Gor,<div><br></div><div>It's quite late here so I will =
not address the other points in this thread until tomorrow, but I would lik=
e to correct this misunderstanding.</div><div><br>On Sunday, October 19, 20=
14 12:35:47 AM UTC+11, gorni...@gmail.com wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div>On Saturday, October 18, 2014 5:44:=
11 AM UTC-7, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,20=
4,204);border-left-width:1px;border-left-style:solid">As far as I understan=
d, N4244 requires no heap allocation. The implementation <br>can see what i=
s stored in the resumable lambda and can allocate enough space <br>for it.<=
/blockquote></div><div><br></div><div>Correct. Ignoring&nbsp;stylistic diff=
erences.&nbsp;For me, N4244 and N4134 differ on one design point.</div></di=
v></blockquote><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>How important is to have a&nbsp;stationary coroutine&nbsp;frame once=
 it start running?</div></div></blockquote><div><br></div><div>You're right=
 that this is the area in which the two proposals differ, but you have this=
 backwards.</div><div><br></div><div>N4134 *enforces* a stationary frame. A=
s a user of N4134, we don't get a choice. It also, as a consequence, alloca=
tes that frame and hides it from the user, such as when you said earlier:</=
div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204)=
; border-left-style: solid; padding-left: 1ex;">Lifetime of the coroutine i=
s bound to the lifetime of the generator&lt;T&gt;.</blockquote><div><br></d=
iv><div>N4244 *supports* a stationary frame, but does not require it. It al=
so supports copyable, movable, value-based objects, but it does not require=
 that either. If you do want to use a stationary frame, you get to choose e=
xactly where to put it, including embedding it as a data member of another =
class.</div><div><br></div><div>Earlier you said:</div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-lef=
t-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: sol=
id; padding-left: 1ex;">One way to think of N4134 is that it is a small ram=
p around a resumable lambda that allocates it and gives out a handle of som=
e sort.</blockquote><div><br></div><div>Which is exactly right. We can impl=
ement N4134 semantics on top of N4244, but we can't do it the other way aro=
und because you can't give back what is already taken away.</div><div><br><=
/div><div>Cheers,</div><div>Chris</div><div><br></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_274_1214968910.1413640726474--

.

------=_Part_1678_944462192.1413641354681
Content-Type: text/plain; charset=UTF-8

On Saturday, October 18, 2014 6:49:59 AM UTC-7, Ville Voutilainen wrote:
>
> Well, returning ints, while not terribly interesting, is just an example
> of
> a generator returning (well, generating) value-semantic types. There are
> fair amounts of use cases for such generators, and they are not
> necessarily
> asynchronous in any way.
>

Oh yeah. Let's table asynchrony for a moment. I believe that coroutine as
generators will be used more widely then any of their async variants (more
yields, fewer awaits).
In a generator coroutines, we have many different kind of "returns" :-) .

In N4134
1. generator<int> - movable value semantics. control the lifetime of the
underlying coroutine, (destruction of a generator leads to cancellation of
the coroutine), can be used to get access to iterator of coroutine produce
values.
2. yielded value - (can have 0 or more: that is what yield expr statement
is doing)
3. eventual value - (usually void for generators, this what "return expr"
statement is doing)

--

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

<div dir=3D"ltr"><div>On Saturday, October 18, 2014 6:49:59 AM UTC-7, Ville=
 Voutilainen 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;">Well, returning ints, while=
 not terribly interesting, is just an example of <br>a generator returning =
(well, generating) value-semantic types. There are <br>fair amounts of use =
cases for such generators, and they are not necessarily <br>asynchronous in=
 any way. <br></blockquote></div><div><br></div><div>Oh yeah. Let's table a=
synchrony for&nbsp;a moment. I believe that coroutine as generators will be=
 used more widely then any of their async variants (more yields, fewer awai=
ts).</div><div>In a generator coroutines, we have many different kind of "r=
eturns" :-) .</div><div><br></div><div>In N4134</div><div>1. generator&lt;i=
nt&gt; - movable value semantics. control the lifetime of the underlying co=
routine, (destruction of a generator leads to cancellation of the coroutine=
), can be used to get access to iterator of coroutine produce values.</div>=
<div>2. yielded value - (can have 0 or more: that is what yield expr statem=
ent is doing)</div><div>3. eventual value - (usually void for generators, t=
his what "return expr" statement is doing)</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_1678_944462192.1413641354681--

.

------=_Part_1700_463526857.1413643016805
Content-Type: text/plain; charset=UTF-8

Hi Chris:

*waves* :-)

On Saturday, October 18, 2014 6:58:46 AM UTC-7, chris.k...@gmail.com wrote:
>
> You're right that this is the area in which the two proposals differ, but
> you have this backwards.
>
> N4134 *enforces* a stationary frame. As a user of N4134, we don't get a
> choice. It also, as a consequence, allocates that frame and hides it from
> the user:
>

It highly encourages stationary frames :-). Forces you to work hard to get
to the coroutine frame, you can full around with stateful allocators, but,
yeah. The intention was to make stationary frames very strong default.

One way to think of N4134 is that it is a small ramp around a resumable
> lambda that allocates it and gives out a handle of some sort.
>
> Which is exactly right. We can implement N4134 semantics on top of N4244,
> but we can't do it the other way around because you can't give back what is
> already taken away.
>

I am not sure about the "give back what is already taken away".

N4134 provides syntactic sugar and library hookup for many different
scenarios (generators, reactive streams, async generators, awaitables).
Implementation of N4134 is logically a wrapper around some unspecified
"lambda*" giving various optimization options open.
When I was working on design on N4134 I was not aware about your proposal,
but thought it would be cool (in a geeky way) to be able at some point to
see if we can extract lambda* and make it a language construct at some
point in the future (was not my priority as stationary frames was the
design point).

N4244 specifies what a potential lambda* could be.

Even if there were no N4244, we could have come up with something like this
later on. N4134 simply leaves lambda* unspecified focusing on the higher
level coroutine interface, so it does not "taketh anything away" :-)

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

<div dir=3D"ltr"><div>Hi Chris:</div><div><br></div><div>*waves* :-)<br></d=
iv><div><br></div><div>On Saturday, October 18, 2014 6:58:46 AM UTC-7, chri=
s.k...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 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"><div><=
div>You're right that this is the area in which the two proposals differ, b=
ut you have this backwards.</div><div><br></div><div>N4134 *enforces* a sta=
tionary frame. As a user of N4134, we don't get a choice. It also, as a con=
sequence, allocates that frame and hides it from the user:</div></div></div=
></blockquote></div><div><br></div><div>It highly encourages stationary fra=
mes :-). Forces you to work hard to get to the coroutine frame, you can ful=
l around with stateful allocators, but, yeah. The intention was to make sta=
tionary frames very strong default.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div dir=3D"ltr"><div><div>One way to think of N4134 is that it=
 is a small ramp around a resumable lambda that allocates it and gives out =
a handle of some sort.</div><div><br></div><div>Which is exactly right. We =
can implement N4134 semantics on top of N4244, but we can't do it the other=
 way around because you can't give back what is already taken away.<br></di=
v></div></div></blockquote><div><div><br></div><div>I am not sure about the=
 "give back what is already taken away".</div><div><br></div><div>N4134 pro=
vides syntactic sugar and library hookup for many different scenarios (gene=
rators, reactive streams, async generators, awaitables).</div><div>Implemen=
tation of N4134 is logically a wrapper around some unspecified "lambda*" gi=
ving various optimization options open. </div><div>When I was working on de=
sign on N4134 I was not aware about your proposal, but thought it would be =
cool (in a geeky way) to be able at some&nbsp;point to see if we can extrac=
t lambda* and make it a language construct at some point in the future (was=
 not my priority as stationary frames was the design point).</div><div><br>=
</div><div>N4244 specifies what a potential lambda* could be. </div><div><b=
r></div><div>Even if there were no N4244, we could have come up with someth=
ing like this later on. N4134 simply leaves lambda* unspecified focusing on=
 the higher level coroutine interface, so it does not "taketh anything away=
" :-)</div><div><br></div><div>Cheers,</div><div>Gor</div><div><br></div><d=
iv><br></div>&nbsp;</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_1700_463526857.1413643016805--

.

------=_Part_69_534237030.1413671777121
Content-Type: text/plain; charset=UTF-8

Hi Ville,

On Saturday, October 18, 2014 11:41:55 PM UTC+11, Ville Voutilainen wrote:
>
> On 18 October 2014 15:23,  <gorni...@gmail.com <javascript:>> wrote:
> > Ville,
> >
> > Have you seen N4134? Fully open. Not tied to the future or any
> particular
> > abstraction.
>
> As far as I understood it, the generators/futures/whichever-things the
> resumable
> function of N4134 returns must be shared-semantics types that share
> state with the
> resumable function itself. Chris's proposal seems to be so that the state
> is completely within the lambda, and thus the lambda itself can just
> return
> an int if it so wants to.
>
> Then again, I don't quite see how to return a future<T> with N4244 - I
> would
> expect I need to return a future<T>& and have the future as a capture.
>

It's a similar principle to when you write "async(f)". The function f
doesn't return the future; instead std::async wraps it in the necessary
machinery to run f and make the result available as a future. So, we could
have:

  std::future<int> result = run_resumable([]() resumable { ...; return 42;
});

If you want to write this as a function to enable separate compilation,
then it's:

  std::future<int> my_resumable_function()
  {
    return run_resumable([]() resumable { ...; return 42; });
  }

You could possibly even do:

  auto f = []() resumable { ...; return 42; };
  std::future<int> result = run_resumable(std::ref(f));

to produce a future from a resumable lambda stored at a location of your
choosing.

Cheers,
Chris

--

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

<div dir=3D"ltr">Hi Ville,<br><br>On Saturday, October 18, 2014 11:41:55 PM=
 UTC+11, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">On 18 October 2014 15:23, &nbsp;&lt;<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"iRa5FJxw7DMJ" onmousedown=3D"this.href=3D'ja=
vascript:';return true;" onclick=3D"this.href=3D'javascript:';return true;"=
>gorni...@gmail.com</a>&gt; wrote:
<br>&gt; Ville,
<br>&gt;
<br>&gt; Have you seen N4134? Fully open. Not tied to the future or any par=
ticular
<br>&gt; abstraction.
<br>
<br>As far as I understood it, the generators/futures/whichever-<wbr>things=
 the resumable
<br>function of N4134 returns must be shared-semantics types that share
<br>state with the
<br>resumable function itself. Chris's proposal seems to be so that the sta=
te
<br>is completely within the lambda, and thus the lambda itself can just re=
turn
<br>an int if it so wants to.
<br>
<br>Then again, I don't quite see how to return a future&lt;T&gt; with N424=
4 - I would
<br>expect I need to return a future&lt;T&gt;&amp; and have the future as a=
 capture.
<br></blockquote><div><br></div><div>It's a similar principle to when you w=
rite "async(f)". The function f doesn't return the future; instead std::asy=
nc wraps it in the necessary machinery to run f and make the result availab=
le as a future. So, we could have:</div><div><br></div><div>&nbsp; std::fut=
ure&lt;int&gt; result =3D run_resumable([]() resumable { ...; return 42; })=
;</div><div><br></div><div>If you want to write this as a function to enabl=
e separate compilation, then it's:</div><div><br></div><div>&nbsp; std::fut=
ure&lt;int&gt; my_resumable_function()</div><div>&nbsp; {</div><div>&nbsp; =
&nbsp; return run_resumable([]() resumable { ...; return 42; });</div><div>=
&nbsp; }</div><div><br></div><div>You could possibly even do:</div><div><br=
></div><div>&nbsp; auto f =3D []() resumable { ...; return 42; };</div><div=
>&nbsp; std::future&lt;int&gt; result =3D run_resumable(std::ref(f));</div>=
<div><br></div><div>to produce a future from a resumable lambda stored at a=
 location of your choosing.</div><div><br></div><div>Cheers,</div><div>Chri=
s</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_69_534237030.1413671777121--

.

------=_Part_1997_192275330.1413682661298
Content-Type: text/plain; charset=UTF-8



On Saturday, October 18, 2014 11:31:34 PM UTC+11, Gor Nishanov wrote:
>
> Nat's and Oliver proposal is about stackful coroutines where unit of
> suspension is a user-mode thread / fiber rather than a particular function.
> Fibers are more powerful than coroutines, but they carry higher cost both
> in memory footprint and the cost of the context switch.
>
> N4244 and N4134 are in the stackless coroutine space.
>

For the benefit of others (Gor already knows my view on the matter :-) I
don't consider N4134 to be in the stackless coroutine space. In my view
being stackless means being able to copy your coroutine state. For example:

One of the main features of Stackless is its ability to pickle and unpickle
> tasklets. That means that a running program inside a tasklet can be
> persistently stored to a file or string. Later, it can be restored again
> and can continue to run at the point where it was previously halted. This
> need not be on the same machine!


From: http://www.stackless.com/wiki/Pickling

In this sense N3985 coroutines / fibers are not strictly "more powerful".
They have different capabilities and a different set of tradeoffs.

However, the terms stackless and stackful do seem to have been muddied
somewhat (I am also guilty of this) and are not necessarily mutually
exclusive. It is probably best if we stick to talking about the
capabilities of the proposals rather than using these terms.

Cheers,
Chris

--

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

<div dir=3D"ltr"><br><br>On Saturday, October 18, 2014 11:31:34 PM UTC+11, =
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"><div>Nat's and Oliver proposal is about stackful coroutines where uni=
t of suspension is a user-mode thread / fiber rather than a particular func=
tion.</div><div>Fibers are more powerful than coroutines, but they carry hi=
gher cost both in memory footprint and the cost of the context switch.</div=
><div><br></div><div>N4244 and N4134 are in the stackless coroutine space.<=
/div></div></blockquote><div><br></div><div>For the benefit of others (Gor =
already knows my view on the matter :-) I don't consider N4134 to be in the=
 stackless coroutine space. In my view being stackless means being able to =
copy your coroutine state. For example:</div><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1=
px; border-left-color: rgb(204, 204, 204); border-left-style: solid; paddin=
g-left: 1ex;"><span style=3D"color: rgb(0, 0, 0); font-family: -apple-syste=
m-font; font-size: 12px; line-height: 16px;">One of the main features of St=
ackless is its ability to pickle and unpickle tasklets. That means that a r=
unning program inside a tasklet can be persistently stored to a file or str=
ing. Later, it can be restored again and can continue to run at the point w=
here it was previously halted. This need not be on the same machine!</span>=
</blockquote><div><br></div><div>From: http://www.stackless.com/wiki/Pickli=
ng<br></div><div><br></div><div>In this sense N3985 coroutines / fibers are=
 not strictly "more powerful". They have different capabilities and a diffe=
rent set of tradeoffs.</div><div><br></div><div>However, the terms stackles=
s and stackful do seem to have been muddied somewhat (I am also guilty of t=
his) and are not necessarily mutually exclusive. It is probably best if we =
stick to talking about the capabilities of the proposals rather than using =
these terms.</div><div><br></div><div>Cheers,</div><div>Chris</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_1997_192275330.1413682661298--

.

------=_Part_2092_1317402481.1413690843289
Content-Type: text/plain; charset=UTF-8

Yeah, we probably need to find replacement for stackless and stackful.
:-), Let's check with Nat and Oliver, since they also use definitions
from same paper as I do.

By definitions from "Revisiting Coroutines" paper
http://www.inf.puc-rio.br/~roberto/docs/MCC15-04.pdf, [1]
Python stackless is actually "stackful", (Because they suspend entire call
stack, not just the coroutine), therefore Python implements user-mode
threads, micro-threads, fibers. (Not on the OS level, but functionally).

Python stackless used the word "stackless" to mean absence of C stack, but
provided [my guess, did not see the implementation] their own
chained-stacks that have lighter memory footprint than threads.

I do like [1] terminology as it allows for a nice breakdown of concepts:

1. Thread: Kernel Mode thread + User mode stack (OS scheduler runs it) -
unit of suspension entire thread (kernel + user)
2. Fiber (stackful coroutine / user mode thread) - runs on top of some
kernel thread, unit of suspension fiber, (kernel thread is not suspended)
3. Coroutine (stackless coroutine) - runs on top of some thread or fiber,
when suspended simply returns to the caller. unit of suspension is
a coroutine.

On Saturday, October 18, 2014 6:37:41 PM UTC-7, chris.k...@gmail.com wrote:

>
>
> On Saturday, October 18, 2014 11:31:34 PM UTC+11, Gor Nishanov wrote:
>>
>> Nat's and Oliver proposal is about stackful coroutines where unit of
>> suspension is a user-mode thread / fiber rather than a particular function.
>> Fibers are more powerful than coroutines, but they carry higher cost both
>> in memory footprint and the cost of the context switch.
>>
>> N4244 and N4134 are in the stackless coroutine space.
>>
>
> For the benefit of others (Gor already knows my view on the matter :-) I
> don't consider N4134 to be in the stackless coroutine space. In my view
> being stackless means being able to copy your coroutine state. For example:
>
> One of the main features of Stackless is its ability to pickle and
>> unpickle tasklets. That means that a running program inside a tasklet can
>> be persistently stored to a file or string. Later, it can be restored again
>> and can continue to run at the point where it was previously halted. This
>> need not be on the same machine!
>
>
> From: http://www.stackless.com/wiki/Pickling
>
> In this sense N3985 coroutines / fibers are not strictly "more powerful".
> They have different capabilities and a different set of tradeoffs.
>
> However, the terms stackless and stackful do seem to have been muddied
> somewhat (I am also guilty of this) and are not necessarily mutually
> exclusive. It is probably best if we stick to talking about the
> capabilities of the proposals rather than using these terms.
>
> Cheers,
> Chris
>

--

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

<div dir=3D"ltr"><div>Yeah, we probably need to find replacement for stackl=
ess and stackful. :-),&nbsp;Let's check with Nat and Oliver, since&nbsp;the=
y also use definitions from&nbsp;same paper as I do.</div><div><br></div><d=
iv>By definitions from "Revisiting Coroutines" paper <a href=3D"http://www.=
inf.puc-rio.br/~roberto/docs/MCC15-04.pdf">http://www.inf.puc-rio.br/~rober=
to/docs/MCC15-04.pdf</a>, [1]</div><div>Python stackless is actually "stack=
ful", (Because they&nbsp;suspend entire call stack, not just the coroutine)=
, therefore Python implements user-mode threads, micro-threads, fibers. (No=
t on the OS level, but functionally). </div><div><br></div><div>Python stac=
kless used the word "stackless" to mean absence of C stack, but provided [m=
y guess, did not see the implementation] their own chained-stacks that have=
 lighter memory footprint than threads.</div><div><br></div><div>I do like =
[1] terminology as it allows for a nice breakdown of concepts:</div><div><b=
r></div><div>1. Thread: Kernel Mode thread + User mode stack (OS scheduler =
runs it) - unit of suspension entire thread (kernel + user)</div><div>2. Fi=
ber&nbsp;(stackful coroutine / user mode thread) - runs on top of some kern=
el thread, unit of suspension fiber, (kernel thread is not suspended)</div>=
<div>3. Coroutine (stackless coroutine) - runs on top of some thread or fib=
er, when suspended simply returns to the caller. unit of suspension is a&nb=
sp;coroutine.</div><div><br></div><div>On Saturday, October 18, 2014 6:37:4=
1 PM UTC-7, chris.k...@gmail.com wrote:</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-colo=
r: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><=
div dir=3D"ltr"><br><br>On Saturday, October 18, 2014 11:31:34 PM UTC+11, G=
or Nishanov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>Nat's =
and Oliver proposal is about stackful coroutines where unit of suspension i=
s a user-mode thread / fiber rather than a particular function.</div><div>F=
ibers are more powerful than coroutines, but they carry higher cost both in=
 memory footprint and the cost of the context switch.</div><div><br></div><=
div>N4244 and N4134 are in the stackless coroutine space.</div></div></bloc=
kquote><div><br></div><div>For the benefit of others (Gor already knows my =
view on the matter :-) I don't consider N4134 to be in the stackless corout=
ine space. In my view being stackless means being able to copy your corouti=
ne state. For example:</div><div><br></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;"><sp=
an style=3D"color: rgb(0, 0, 0); line-height: 16px; font-family: -apple-sys=
tem-font; font-size: 12px;">One of the main features of Stackless is its ab=
ility to pickle and unpickle tasklets. That means that a running program in=
side a tasklet can be persistently stored to a file or string. Later, it ca=
n be restored again and can continue to run at the point where it was previ=
ously halted. This need not be on the same machine!</span></blockquote><div=
><br></div><div>From: <a onmousedown=3D"this.href=3D'http://www.google.com/=
url?q\75http%3A%2F%2Fwww.stackless.com%2Fwiki%2FPickling\46sa\75D\46sntz\07=
51\46usg\75AFQjCNE5YbVL67S4M053xX-9oVWs9d3TJg';return true;" onclick=3D"thi=
s.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.stackless.com%2Fwi=
ki%2FPickling\46sa\75D\46sntz\0751\46usg\75AFQjCNE5YbVL67S4M053xX-9oVWs9d3T=
Jg';return true;" href=3D"http://www.stackless.com/wiki/Pickling" target=3D=
"_blank">http://www.stackless.com/wiki/<wbr>Pickling</a><br></div><div><br>=
</div><div>In this sense N3985 coroutines / fibers are not strictly "more p=
owerful". They have different capabilities and a different set of tradeoffs=
..</div><div><br></div><div>However, the terms stackless and stackful do see=
m to have been muddied somewhat (I am also guilty of this) and are not nece=
ssarily mutually exclusive. It is probably best if we stick to talking abou=
t the capabilities of the proposals rather than using these terms.</div><di=
v><br></div><div>Cheers,</div><div>Chris</div></div></blockquote></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_2092_1317402481.1413690843289--

.

On 19 October 2014 01:36,  <chris.kohlhoff@gmail.com> wrote:
>> Then again, I don't quite see how to return a future<T> with N4244 - I
>> would
>> expect I need to return a future<T>& and have the future as a capture.
> It's a similar principle to when you write "async(f)". The function f
> doesn't return the future; instead std::async wraps it in the necessary
> machinery to run f and make the result available as a future. So, we could

Blargh, I was confused for a moment. The gist of the matter is sharing the
state, and the lifetime of it. From the state of a resumable lambda, the
lambda can quite easily generate futures that are not necessarily associated
with the state of the lambda. The lifetime of the state itself
is bound to the lambda, and sharing the state itself via the return type
is not really important, although it could theoretically be done. Neither
resumable lambdas nor resumable functions can move the state itself
out of themselves(*). The return type of a resumable function takes care
of the lifetime of the state, whereas in a resumable lambda, the lambda
itself takes care of it.

Correct?

(*) Well, they can, but then they would have to cope with the moved-from state.

--

---
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_403_1565842355.1413751801166
Content-Type: text/plain; charset=UTF-8



On Monday, October 20, 2014 4:35:16 AM UTC+11, Ville Voutilainen wrote:
>
> On 19 October 2014 01:36,  <chris.k...@gmail.com <javascript:>> wrote:
> >> Then again, I don't quite see how to return a future<T> with N4244 - I
> >> would
> >> expect I need to return a future<T>& and have the future as a capture.
> > It's a similar principle to when you write "async(f)". The function f
> > doesn't return the future; instead std::async wraps it in the necessary
> > machinery to run f and make the result available as a future. So, we
> could
>
> Blargh, I was confused for a moment. The gist of the matter is sharing the
> state, and the lifetime of it. From the state of a resumable lambda, the
> lambda can quite easily generate futures that are not necessarily
> associated
> with the state of the lambda. The lifetime of the state itself
> is bound to the lambda, and sharing the state itself via the return type
> is not really important, although it could theoretically be done. Neither
> resumable lambdas nor resumable functions can move the state itself
> out of themselves(*).


Experience with the macro-based equivalent of resumable lambdas shows that
they can. For example:

  []() resumable
  {
    ...
    yield async_something(std::move(*[]this));
    ...
  }

is roughly equivalent to:

  __state = __LINE__; \
  async_something(std::move(*this)); \
  return; \
  case __LINE__:

Any state is moved along into the operation and the only thing the
moved-from lambda does is exit following the yield.

This works very nicely as a truly lightweight way to chain async operations.

The return type of a resumable function takes care
> of the lifetime of the state, whereas in a resumable lambda, the lambda
> itself takes care of it.
>

I prefer to think that the resumable lambda itself is the state, but yes.

Cheers,
Chris

--

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

<div dir=3D"ltr"><br><br>On Monday, October 20, 2014 4:35:16 AM UTC+11, Vil=
le Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 19 Oct=
ober 2014 01:36, &nbsp;&lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"kmRiJ4EmNA4J" onmousedown=3D"this.href=3D'javascript:';r=
eturn true;" onclick=3D"this.href=3D'javascript:';return true;">chris.k...@=
gmail.com</a>&gt; wrote:
<br>&gt;&gt; Then again, I don't quite see how to return a future&lt;T&gt; =
with N4244 - I
<br>&gt;&gt; would
<br>&gt;&gt; expect I need to return a future&lt;T&gt;&amp; and have the fu=
ture as a capture.
<br>&gt; It's a similar principle to when you write "async(f)". The functio=
n f
<br>&gt; doesn't return the future; instead std::async wraps it in the nece=
ssary
<br>&gt; machinery to run f and make the result available as a future. So, =
we could
<br>
<br>Blargh, I was confused for a moment. The gist of the matter is sharing =
the
<br>state, and the lifetime of it. From the state of a resumable lambda, th=
e
<br>lambda can quite easily generate futures that are not necessarily assoc=
iated
<br>with the state of the lambda. The lifetime of the state itself
<br>is bound to the lambda, and sharing the state itself via the return typ=
e
<br>is not really important, although it could theoretically be done. Neith=
er
<br>resumable lambdas nor resumable functions can move the state itself
<br>out of themselves(*).</blockquote><div><br></div><div>Experience with t=
he macro-based equivalent of resumable lambdas shows that they can. For exa=
mple:</div><div><br></div><div>&nbsp; []() resumable</div><div>&nbsp; {</di=
v><div>&nbsp; &nbsp; ...</div><div>&nbsp; &nbsp; yield async_something(std:=
:move(*[]this));</div><div>&nbsp; &nbsp; ...</div><div>&nbsp; }</div><div><=
br></div><div>is roughly equivalent to:</div><div><br></div><div>&nbsp; __s=
tate =3D __LINE__; \</div><div>&nbsp; async_something(std::move(*this)); \<=
/div><div>&nbsp; return; \</div><div>&nbsp; case __LINE__:</div><div><br></=
div><div>Any state is moved along into the operation and the only thing the=
 moved-from lambda does is exit following the yield.</div><div><br></div><d=
iv>This works very nicely as a truly lightweight way to chain async operati=
ons.</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;">The r=
eturn type of a resumable function takes care
<br>of the lifetime of the state, whereas in a resumable lambda, the lambda
<br>itself takes care of it.<br></blockquote><div><br></div><div>I prefer t=
o think that the resumable lambda itself is the state, but yes.</div><div><=
br></div><div>Cheers,</div><div>Chris</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_403_1565842355.1413751801166--

.

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

Hi Gor,

On Sunday, October 19, 2014 2:54:03 PM UTC+11, Gor Nishanov wrote:
>
> Yeah, we probably need to find replacement for stackless and stackful.=20
> :-), Let's check with Nat and Oliver, since they also use definitions=20
> from same paper as I do.
>
> By definitions from "Revisiting Coroutines" paper=20
> http://www.inf.puc-rio.br/~roberto/docs/MCC15-04.pdf, [1]
> Python stackless is actually "stackful", (Because they suspend entire cal=
l=20
> stack, not just the coroutine), therefore Python implements user-mode=20
> threads, micro-threads, fibers. (Not on the OS level, but functionally).=
=20
>
> Python stackless used the word "stackless" to mean absence of C stack, bu=
t=20
> provided [my guess, did not see the implementation] their own=20
> chained-stacks that have lighter memory footprint than threads.
>
> I do like [1] terminology as it allows for a nice breakdown of concepts:
>
> 1. Thread: Kernel Mode thread + User mode stack (OS scheduler runs it) -=
=20
> unit of suspension entire thread (kernel + user)
> 2. Fiber (stackful coroutine / user mode thread) - runs on top of some=20
> kernel thread, unit of suspension fiber, (kernel thread is not suspended)
> 3. Coroutine (stackless coroutine) - runs on top of some thread or fiber,=
=20
> when suspended simply returns to the caller. unit of suspension is=20
> a coroutine.
>

I think you missed my point. What I'm saying is let's not try to attach=20
labels like these, as they confuse rather than clarify. Switching to=20
another set of labels doesn't help.

Let us instead focus on the *capabilities* of the proposals and use those=
=20
to determine how each proposal addresses the design space. As a starting=20
point for discussion, here is a short list of capabilities I put together.

- Supports value-based types
- Supports persistent stack frames
- Supports stacking
- Supports stacking with normal functions
- Minimises =E2=80=9Cstack=E2=80=9D memory

(N.B. no one proposal covers all five.)

Cheers,
Chris

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

<div dir=3D"ltr">Hi Gor,<br><br>On Sunday, October 19, 2014 2:54:03 PM UTC+=
11, 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 di=
r=3D"ltr"><div>Yeah, we probably need to find replacement for stackless and=
 stackful. :-),&nbsp;Let's check with Nat and Oliver, since&nbsp;they also =
use definitions from&nbsp;same paper as I do.</div><div><br></div><div>By d=
efinitions from "Revisiting Coroutines" paper <a href=3D"http://www.inf.puc=
-rio.br/~roberto/docs/MCC15-04.pdf" target=3D"_blank" onmousedown=3D"this.h=
ref=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.inf.puc-rio.br%2F~rob=
erto%2Fdocs%2FMCC15-04.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNE3eblVYLu_wih=
Col_D_wH9eylmnA';return true;" onclick=3D"this.href=3D'http://www.google.co=
m/url?q\75http%3A%2F%2Fwww.inf.puc-rio.br%2F~roberto%2Fdocs%2FMCC15-04.pdf\=
46sa\75D\46sntz\0751\46usg\75AFQjCNE3eblVYLu_wihCol_D_wH9eylmnA';return tru=
e;">http://www.inf.puc-rio.br/~<wbr>roberto/docs/MCC15-04.pdf</a>, [1]</div=
><div>Python stackless is actually "stackful", (Because they&nbsp;suspend e=
ntire call stack, not just the coroutine), therefore Python implements user=
-mode threads, micro-threads, fibers. (Not on the OS level, but functionall=
y). </div><div><br></div><div>Python stackless used the word "stackless" to=
 mean absence of C stack, but provided [my guess, did not see the implement=
ation] their own chained-stacks that have lighter memory footprint than thr=
eads.</div><div><br></div><div>I do like [1] terminology as it allows for a=
 nice breakdown of concepts:</div><div><br></div><div>1. Thread: Kernel Mod=
e thread + User mode stack (OS scheduler runs it) - unit of suspension enti=
re thread (kernel + user)</div><div>2. Fiber&nbsp;(stackful coroutine / use=
r mode thread) - runs on top of some kernel thread, unit of suspension fibe=
r, (kernel thread is not suspended)</div><div>3. Coroutine (stackless corou=
tine) - runs on top of some thread or fiber, when suspended simply returns =
to the caller. unit of suspension is a&nbsp;coroutine.</div></div></blockqu=
ote><div><br></div><div>I think you missed my point. What I'm saying is let=
's not try to attach labels like these, as they confuse rather than clarify=
.. Switching to another set of labels doesn't help.</div><div><br></div><div=
>Let us instead focus on the *capabilities* of the proposals and use those =
to determine how each proposal addresses the design space. As a starting po=
int for discussion, here is a short list of capabilities I put together.</d=
iv><div><br></div><div><div style=3D"color: rgb(0, 0, 0); font-family: -app=
le-system-font; font-size: 12px; line-height: 16px; direction: ltr;">-&nbsp=
;Supports value-based types</div><div style=3D"color: rgb(0, 0, 0); font-fa=
mily: -apple-system-font; font-size: 12px; line-height: 16px; direction: lt=
r;">-&nbsp;Supports persistent stack frames</div><div style=3D"color: rgb(0=
, 0, 0); font-family: -apple-system-font; font-size: 12px; line-height: 16p=
x; direction: ltr;">-&nbsp;Supports stacking</div><div style=3D"color: rgb(=
0, 0, 0); font-family: -apple-system-font; font-size: 12px; line-height: 16=
px; direction: ltr;">-&nbsp;Supports stacking with normal functions</div><d=
iv style=3D"color: rgb(0, 0, 0); font-family: -apple-system-font; font-size=
: 12px; line-height: 16px; direction: ltr;">-&nbsp;Minimises&nbsp;=E2=80=9C=
stack=E2=80=9D memory</div></div><div style=3D"color: rgb(0, 0, 0); font-fa=
mily: -apple-system-font; font-size: 12px; line-height: 16px; direction: lt=
r;"><br></div><div style=3D"color: rgb(0, 0, 0); font-family: -apple-system=
-font; font-size: 12px; line-height: 16px; direction: ltr;">(N.B. no one pr=
oposal covers all five.)</div><div style=3D"color: rgb(0, 0, 0); font-famil=
y: -apple-system-font; font-size: 12px; line-height: 16px; direction: ltr;"=
><br></div><div style=3D"color: rgb(0, 0, 0); font-family: -apple-system-fo=
nt; font-size: 12px; line-height: 16px; direction: ltr;">Cheers,</div><div =
style=3D"color: rgb(0, 0, 0); font-family: -apple-system-font; font-size: 1=
2px; line-height: 16px; direction: ltr;">Chris</div><div style=3D"color: rg=
b(0, 0, 0); font-family: -apple-system-font; font-size: 12px; line-height: =
16px; direction: ltr;"><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_2288_402316876.1413752911175--

.

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

Excuse my ignorance regarding co-routines, but can a function/member=20
function/lambda that isn=E2=80=99t inlined that has been called from a co-r=
outine,=20
yield a result?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">Excuse my ignorance regarding co-routines, but can a funct=
ion/member function/lambda that isn=E2=80=99t inlined that has been called =
from a co-routine, yield a result?</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_113_1203907485.1414410274411--

.

On 27 October 2014 13:44, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> Excuse my ignorance regarding co-routines, but can a function/member
> function/lambda that isn=E2=80=99t inlined that has been called from a co=
-routine,
> yield a result?

As far as I can see, yes it can, and depending on whether your N4134 functi=
on
does or does not contain a yield or an await, you get a different ABI. An N=
4244
lambda doesn't change its ABI when you change the lambda body.

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

.

On 27 October 2014 13:49, Ville Voutilainen <ville.voutilainen@gmail.com> w=
rote:
> On 27 October 2014 13:44, Douglas Boffey <douglas.boffey@gmail.com> wrote=
:
>> Excuse my ignorance regarding co-routines, but can a function/member
>> function/lambda that isn=E2=80=99t inlined that has been called from a c=
o-routine,
>> yield a result?
>
> As far as I can see, yes it can, and depending on whether your N4134 func=
tion
> does or does not contain a yield or an await, you get a different ABI. An=
 N4244

Now that I think of it, I don't think the presence of a yield or await
in the body
of a N4134 function changes anything abi-wise since the state is in the ret=
urn
type and the return type doesn't change.

--=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_3474_1089026107.1414457449736
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Correct.

Presence of yield or wait does not alter the signature or a calling=20
convention.
Coroutine is an implementation detail.

Let's say you had a library where in v1 you used to return std::future<int>=
..
In v2 you can switch implementation to coroutine and nobody will notice.


On Monday, October 27, 2014 9:38:08 AM UTC-7, Ville Voutilainen wrote:

> On 27 October 2014 13:49, Ville Voutilainen <ville.vo...@gmail.com=20
> <javascript:>> wrote:=20
> > On 27 October 2014 13:44, Douglas Boffey <douglas...@gmail.com=20
> <javascript:>> wrote:=20
> >> Excuse my ignorance regarding co-routines, but can a function/member=
=20
> >> function/lambda that isn=E2=80=99t inlined that has been called from a=
=20
> co-routine,=20
> >> yield a result?=20
> >=20
> > As far as I can see, yes it can, and depending on whether your N4134=20
> function=20
> > does or does not contain a yield or an await, you get a different ABI.=
=20
> An N4244=20
>
> Now that I think of it, I don't think the presence of a yield or await=20
> in the body=20
> of a N4134 function changes anything abi-wise since the state is in the=
=20
> return=20
> type and the return type doesn't change.=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_3474_1089026107.1414457449736
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Correct.</div><div><br></div><div>Presence of yield o=
r wait does not alter the signature or a calling convention.</div><div>Coro=
utine is an implementation detail.</div><div><br></div><div>Let's say you h=
ad a library where in v1 you used to return std::future&lt;int&gt;.</div><d=
iv>In v2 you can switch implementation to coroutine and nobody will notice.=
</div><div><br><br>On Monday, October 27, 2014 9:38:08 AM UTC-7, Ville Vout=
ilainen wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bo=
rder-left-width: 1px; border-left-style: solid;">On 27 October 2014 13:49, =
Ville Voutilainen &lt;<a onmousedown=3D"this.href=3D'javascript:';return tr=
ue;" onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"26n3R3akUbEJ">ville.vo...@gmai=
l.com</a>&gt; wrote:
<br>&gt; On 27 October 2014 13:44, Douglas Boffey &lt;<a onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';r=
eturn true;" href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"26n3R3akUbEJ">douglas...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; Excuse my ignorance regarding co-routines, but can a function/=
member
<br>&gt;&gt; function/lambda that isn=E2=80=99t inlined that has been calle=
d from a co-routine,
<br>&gt;&gt; yield a result?
<br>&gt;
<br>&gt; As far as I can see, yes it can, and depending on whether your N41=
34 function
<br>&gt; does or does not contain a yield or an await, you get a different =
ABI. An N4244
<br>
<br>Now that I think of it, I don't think the presence of a yield or await
<br>in the body
<br>of a N4134 function changes anything abi-wise since the state is in the=
 return
<br>type and the return type doesn't change.
<br></blockquote></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_3474_1089026107.1414457449736--

.

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



El martes, 28 de octubre de 2014 07:50:49 UTC+7, Gor Nishanov escribi=C3=B3=
:
>
> Correct.
>
> Presence of yield or wait does not alter the signature or a calling=20
> convention.
> Coroutine is an implementation detail.
>

=20

> Let's say you had a library where in v1 you used to return=20
> std::future<int>.
> In v2 you can switch implementation to coroutine and nobody will notice.
>

But at the cost of hiding some state "somewhere" when you change it to be a=
=20
a coroutine.
This is the evil part of your proposal IMHO :(=20
You can implement that on top of n4244 and hide the coroutine object at=20
your choice anywhere
you choose, giving a nice interface as well.=20
My feeling is that you are making a=20
design decision in charge of the user, and if she wants to control memory=
=20
allocation, she will
need to write hooks. I strongly think that your proposal should be a=20
framework on top of something
more lightweight like n4244.
Did you consider this possibility?

=20

> On Monday, October 27, 2014 9:38:08 AM UTC-7, Ville Voutilainen wrote:
>
>> On 27 October 2014 13:49, Ville Voutilainen <ville.vo...@gmail.com>=20
>> wrote:=20
>> > On 27 October 2014 13:44, Douglas Boffey <douglas...@gmail.com> wrote:=
=20
>> >> Excuse my ignorance regarding co-routines, but can a function/member=
=20
>> >> function/lambda that isn=E2=80=99t inlined that has been called from =
a=20
>> co-routine,=20
>> >> yield a result?=20
>> >=20
>> > As far as I can see, yes it can, and depending on whether your N4134=
=20
>> function=20
>> > does or does not contain a yield or an await, you get a different ABI.=
=20
>> An N4244=20
>>
>> Now that I think of it, I don't think the presence of a yield or await=
=20
>> in the body=20
>> of a N4134 function changes anything abi-wise since the state is in the=
=20
>> return=20
>> type and the return type doesn't change.=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_28_528317540.1414483999389
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>El martes, 28 de octubre de 2014 07:50:49 UTC+7, G=
or Nishanov  escribi=C3=B3:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div>Correct.</div><div><br></div><div>Presence of yield or w=
ait does not alter the signature or a calling convention.</div><div>Corouti=
ne is an implementation detail.</div></div></blockquote><div><br></div><div=
>&nbsp;<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>Let's say you had a library where in v1 you used to return std::fu=
ture&lt;int&gt;.</div><div>In v2 you can switch implementation to coroutine=
 and nobody will notice.</div></div></blockquote><div><br></div><div>But at=
 the cost of hiding some state "somewhere" when you change it to be a a cor=
outine.</div><div>This is the evil part of your proposal IMHO :(&nbsp;</div=
><div>You can implement that on top of n4244 and hide the coroutine object =
at your choice anywhere</div><div>you choose, giving a nice interface as we=
ll.&nbsp;</div><div>My feeling is that you are making a&nbsp;</div><div>des=
ign decision in charge of the user, and if she wants to control memory allo=
cation, she will</div><div>need to write hooks. I strongly think that your =
proposal should be a framework on top of something</div><div>more lightweig=
ht like n4244.</div><div>Did you consider this possibility?</div><div><br><=
/div><div>&nbsp;<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>On Monday, October 27, 2014 9:38:08 AM UTC-7, Ville Vouti=
lainen wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left=
-width:1px;border-left-style:solid">On 27 October 2014 13:49, Ville Voutila=
inen &lt;<a>ville.vo...@gmail.com</a>&gt; wrote:
<br>&gt; On 27 October 2014 13:44, Douglas Boffey &lt;<a>douglas...@gmail.c=
om</a>&gt; wrote:
<br>&gt;&gt; Excuse my ignorance regarding co-routines, but can a function/=
member
<br>&gt;&gt; function/lambda that isn=E2=80=99t inlined that has been calle=
d from a co-routine,
<br>&gt;&gt; yield a result?
<br>&gt;
<br>&gt; As far as I can see, yes it can, and depending on whether your N41=
34 function
<br>&gt; does or does not contain a yield or an await, you get a different =
ABI. An N4244
<br>
<br>Now that I think of it, I don't think the presence of a yield or await
<br>in the body
<br>of a N4134 function changes anything abi-wise since the state is in the=
 return
<br>type and the return type doesn't change.
<br></blockquote></div></blockquote></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_28_528317540.1414483999389--

.

------=_Part_3271_69446216.1505232909261
Content-Type: multipart/alternative;
 boundary="----=_Part_3272_1491565684.1505232909261"

------=_Part_3272_1491565684.1505232909261
Content-Type: text/plain; charset="UTF-8"

Good day to my viewers out there.. please just read this, some times we
just need to give a try of herbal Medicine to see for our self. I am very
happy today that i do not listen to what people say if not i would have
been a dead man by now. I was infected with HERPES SIMPLEX VIRUS in 2014, i
went to many hospitals for cure but there was no solution, so I was
thinking how can I get a solution out so that my body can be okay. One day
I was in the river side thinking where I can go to get solution. so at that
moment i was doing some research about remedy for herpes on my cell phone,
so i came across an articles about a lady testifying on how she get cured
by the help of a doctor called Odoma, so i have to write down the email
contact of the doctor that she recommended which is (
odomaspelltemple@outlook.com ) on a very good day i decide to write to this
doctor and explain how this virus is killing me slowing, after introducing
myself to this doctor after some time i got a reply back from him, and he
told me the important of his herbal medicine also how he has cure HERPES
SIMPLEX VIRUS and all kinds of virus, He told me all the things I need to
do and also give me instructions to take, which I followed properly. Before
I knew what gradually my body was getting recovery and i was feeling so
different than ever after two weeks the HERPES SIMPLEX VIRUS that was in my
body got vanished. so if you are also heart broken and also need a help,
you can also contact him Via Email (odomaspelltemple@outlook.com) and give
a try i promise if you can stay in touch with Him through his contact email
address stated here correctly you wont miss out okay here is the Email once
again ( odomaspelltemple@outlook.com ) and you will give a testimony too
wish you Good luck guys...

--
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/f41928e1-13c5-4097-a26a-861eacc6c707%40isocpp.org.

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

<div dir=3D"ltr">Good day to my viewers out there.. please just read this, =
some times we just need to give a try of herbal Medicine to see for our sel=
f. I am very happy today that i do not listen to what people say if not i w=
ould have been a dead man by now. I was infected with HERPES SIMPLEX VIRUS =
in 2014, i went to many hospitals for cure but there was no solution, so I =
was thinking how can I get a solution out so that my body can be okay. One =
day I was in the river side thinking where I can go to get solution. so at =
that moment i was doing some research about remedy for herpes on my cell ph=
one, so i came across an articles about a lady testifying on how she get cu=
red by the help of a doctor called Odoma, so i have to write down the email=
 contact of the doctor that she recommended which is ( odomaspelltemple@out=
look.com ) on a very good day i decide to write to this doctor and explain =
how this virus is killing me slowing, after introducing myself to this doct=
or after some time i got a reply back from him, and he told me the importan=
t of his herbal medicine also how he has cure HERPES SIMPLEX VIRUS and all =
kinds of virus, He told me all the things I need to do and also give me ins=
tructions to take, which I followed properly. Before I knew what gradually =
my body was getting recovery and i was feeling so different than ever after=
 two weeks the HERPES SIMPLEX VIRUS that was in my body got vanished. so if=
 you are also heart broken and also need a help, you can also contact him V=
ia Email (odomaspelltemple@outlook.com) and give a try i promise if you can=
 stay in touch with Him through his contact email address stated here corre=
ctly you wont miss out okay here is the Email once again ( odomaspelltemple=
@outlook.com ) and you will give a testimony too wish you Good luck guys...=
<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/f41928e1-13c5-4097-a26a-861eacc6c707%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f41928e1-13c5-4097-a26a-861eacc6c707=
%40isocpp.org</a>.<br />

------=_Part_3272_1491565684.1505232909261--

------=_Part_3271_69446216.1505232909261--

.