Topic: RFC: await, structured binding and std::expected
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 29 May 2016 12:01:06 +0200
Raw View
This is a multi-part message in MIME format.
--------------9913FD5E9988CDFEF359589A
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi,
Using structured binding like syntax to mean await when we don't want to
await
For a lot of people it troubling to use await with std::expected
[P0323R0] as we don't await anything.
auto x = await f_ret_expected();
With structured binding [P0144R2] we will be able to do variable
binding when the type is a product types.
auto [x, y] = f_ret_tuple();
With pattern matching [P0095R1] we could possibly be able to match
PointerLike types using `*v` or maybe using `[v]`.
Wondering if we couldn't extend the structured binding to do something
like the Haskell-do notation based on await [p0057r3].
auto [x] = expected_f();
This will be equivalent to
auto x = await expected_f();
when the type follows the await protocol [p0057r3]
What do you think?
Vicente
https://github.com/viboes/std-make/blob/master/doc/proposal/expected/p0323r0.md#await-adaptation
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0095r0.html
http://davidsankel.com/uncategorized/c-language-support-for-pattern-matching-and-variants/
More complex datatypes
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0057r3.pdf
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a6a9247a-9684-4e12-aaeb-162c638c8bc0%40wanadoo.fr.
--------------9913FD5E9988CDFEF359589A
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<p>Hi,<br>
</p>
<p><br>
</p>
<p>Using structured binding like syntax to mean await when we don't
want to await</p>
<p>For a lot of people it troubling to use await with std::expected
[P0323R0] as we don't await anything.</p>
<p>=C2=A0=C2=A0=C2=A0 auto x =3D await f_ret_expected();</p>
<p>With structured binding [P0144R2]=C2=A0 we will be able to do variab=
le
binding when the type is a product types.<br>
</p>
<p><font size=3D"+1">=C2=A0=C2=A0=C2=A0 auto [x, y] =3D f_ret_tuple();<=
/font></p>
<p><font size=3D"+1">With pattern matching </font>[P0095R1] we could
possibly be able to match PointerLike types using `*v` or maybe
using `[v]`.<br>
</p>
<p><font size=3D"+1">Wondering if we couldn't extend the structured
binding to do something like the Haskell-do notation based on
await [</font><font size=3D"+1">p0057r3].</font></p>
<p>=C2=A0=C2=A0=C2=A0 auto [x] =3D expected_f();</p>
<p>This will be equivalent to <br>
</p>
<p>=C2=A0=C2=A0=C2=A0 auto x =3D await expected_f();</p>
<p>when the type follows the await protocol [p0057r3]<br>
</p>
<p>What do you think?<br>
</p>
<p>Vicente</p>
<p><br>
</p>
<p><a class=3D"moz-txt-link-freetext" href=3D"https://github.com/viboes=
/std-make/blob/master/doc/proposal/expected/p0323r0.md#await-adaptation">ht=
tps://github.com/viboes/std-make/blob/master/doc/proposal/expected/p0323r0.=
md#await-adaptation</a></p>
<p><a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/j=
tc1/sc22/wg21/docs/papers/2015/p0095r0.html">http://www.open-std.org/jtc1/s=
c22/wg21/docs/papers/2015/p0095r0.html</a></p>
<p><a class=3D"moz-txt-link-freetext" href=3D"http://davidsankel.com/un=
categorized/c-language-support-for-pattern-matching-and-variants/">http://d=
avidsankel.com/uncategorized/c-language-support-for-pattern-matching-and-va=
riants/</a>=C2=A0=C2=A0
More complex datatypes</p>
<p><a class=3D"moz-txt-link-freetext" href=3D"http://www.open-std.org/j=
tc1/sc22/wg21/docs/papers/2016/p0057r3.pdf">http://www.open-std.org/jtc1/sc=
22/wg21/docs/papers/2016/p0057r3.pdf</a><br>
</p>
<p><br>
</p>
<p><br>
</p>
<p><br>
</p>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a6a9247a-9684-4e12-aaeb-162c638c8bc0%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a6a9247a-9684-4e12-aaeb-162c638c8bc0=
%40wanadoo.fr</a>.<br />
--------------9913FD5E9988CDFEF359589A--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 29 May 2016 07:57:43 -0700 (PDT)
Raw View
------=_Part_82_924962402.1464533863247
Content-Type: multipart/alternative;
boundary="----=_Part_83_461342636.1464533863247"
------=_Part_83_461342636.1464533863247
Content-Type: text/plain; charset=UTF-8
On Sunday, May 29, 2016 at 6:01:09 AM UTC-4, Vicente J. Botet Escriba wrote:
>
> Hi,
>
>
> Using structured binding like syntax to mean await when we don't want to
> await
>
> For a lot of people it troubling to use await with std::expected [P0323R0]
> as we don't await anything.
>
> auto x = await f_ret_expected();
>
> With structured binding [P0144R2] we will be able to do variable binding
> when the type is a product types.
>
> auto [x, y] = f_ret_tuple();
>
> With pattern matching [P0095R1] we could possibly be able to match
> PointerLike types using `*v` or maybe using `[v]`.
>
> Wondering if we couldn't extend the structured binding to do something
> like the Haskell-do notation based on await [p0057r3].
>
> auto [x] = expected_f();
>
> This will be equivalent to
>
> auto x = await expected_f();
>
> when the type follows the await protocol [p0057r3]
>
> What do you think?
>
It seems like this would be exceedingly confusing and unexpected.
If `auto [x, y]` will mean to use structured binding to extract two values
from a tuple-like type, then `auto [x]` should mean something similar: to
extract one value from a tuple-like type. Having tuple-like types that
contain one value is entirely possible, after all. It would be *very*
surprising for structured binding over one-element tuples to mean something
different from structured binding over two-element tuples.
It *certainly* should not mean `await`, which has an entirely different
semantic meaning and use case.
Remember that `await` isn't free. The use of it in a function transforms
that function into a coroutine, which has its own overhead to it. That's
*not* something that should be able to happen by accident.
And then there's the fact that `await` is at present targeting a TS, not
the standard. Not to mention that some people seem very convinced that it
is a truly bad idea that should never be standardized.
Lastly, what is it with your fascination of getting "do notation" into C++?
Do you really want to turn the language into a crappy version of a
functional language *this badly* that you're hijack whatever syntax you can
get your hands on? If "do notation" is truly important for C++, then you
should have no problem proposing syntax *specifically* for it. Piggybacking
this feature off of *two other features* is just reaching.
--
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/3f3c4d0e-d0b7-4902-96aa-523482f9fefe%40isocpp.org.
------=_Part_83_461342636.1464533863247
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, May 29, 2016 at 6:01:09 AM UTC-4, Vicente J. Bo=
tet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<p>Hi,<br>
</p>
<p><br>
</p>
<p>Using structured binding like syntax to mean await when we don't
want to await</p>
<p>For a lot of people it troubling to use await with std::expected
[P0323R0] as we don't await anything.</p>
<p>=C2=A0=C2=A0=C2=A0 auto x =3D await f_ret_expected();</p>
<p>With structured binding [P0144R2]=C2=A0 we will be able to do variab=
le
binding when the type is a product types.<br>
</p>
<p><font size=3D"+1">=C2=A0=C2=A0=C2=A0 auto [x, y] =3D f_ret_tuple();<=
/font></p>
<p><font size=3D"+1">With pattern matching </font>[P0095R1] we could
possibly be able to match PointerLike types using `*v` or maybe
using `[v]`.<br>
</p>
<p><font size=3D"+1">Wondering if we couldn't extend the structured
binding to do something like the Haskell-do notation based on
await [</font><font size=3D"+1">p0057r3].</font></p>
<p>=C2=A0=C2=A0=C2=A0 auto [x] =3D expected_f();</p>
<p>This will be equivalent to <br>
</p>
<p>=C2=A0=C2=A0=C2=A0 auto x =3D await expected_f();</p>
<p>when the type follows the await protocol [p0057r3]<br>
</p>
<p>What do you think?<br></p></div></blockquote><div><br>It seems like =
this would be exceedingly confusing and unexpected.<br><br>If `auto [x, y]`=
will mean to use structured binding to extract two values from a tuple-lik=
e type, then `auto [x]` should mean something similar: to extract one value=
from a tuple-like type. Having tuple-like types that contain one value is =
entirely possible, after all. It would be <i>very</i> surprising for struct=
ured binding over one-element tuples to mean something different from struc=
tured binding over two-element tuples.<br><br>It <i>certainly</i> should no=
t mean `await`, which has an entirely different semantic meaning and use ca=
se.<br><br>Remember that `await` isn't free. The use of it in a functio=
n transforms that function into a coroutine, which has its own overhead to =
it. That's <i>not</i> something that should be able to happen by accide=
nt.<br><br>And then there's the fact that `await` is at present targeti=
ng a TS, not the standard. Not to mention that some people seem very convin=
ced that it is a truly bad idea that should never be standardized.<br><br>L=
astly, what is it with your fascination of getting "do notation" =
into C++? Do you really want to turn the language into a crappy version of =
a functional language <i>this badly</i> that you're hijack whatever syn=
tax you can get your hands on? If "do notation" is truly importan=
t for C++, then you should have no problem proposing syntax <i>specifically=
</i> for it. Piggybacking this feature off of <i>two other features</i> is =
just reaching.<br></div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3f3c4d0e-d0b7-4902-96aa-523482f9fefe%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3f3c4d0e-d0b7-4902-96aa-523482f9fefe=
%40isocpp.org</a>.<br />
------=_Part_83_461342636.1464533863247--
------=_Part_82_924962402.1464533863247--
.
Author: Gor Nishanov <gornishanov@gmail.com>
Date: Sat, 11 Jun 2016 10:01:14 -0700 (PDT)
Raw View
------=_Part_27_680934273.1465664474849
Content-Type: multipart/alternative;
boundary="----=_Part_28_1654768772.1465664474850"
------=_Part_28_1654768772.1465664474850
Content-Type: text/plain; charset=UTF-8
On Sunday, May 29, 2016 at 3:01:09 AM UTC-7, Vicente J. Botet Escriba wrote:
>
> Hi,
>
>
> Using structured binding like syntax to mean await when we don't want to
> await
>
> For a lot of people it troubling to use await with std::expected [P0323R0]
> as we don't await anything
>
>
>
Just to comment on this point. One suggestion to improve readability of
that use of away was to repurpose 'try' :-) .
So that you code looks:
int i = try foo(bla); // try will unpack expected<int> and propagate the
error if required. Compile time error if used with future-like awaitables.
Just on the readability side, if I had to chose between:
int [i] = foo(bla)
vs
int i = try foo(bla);
I would go with the latter.
--
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/fd851a3a-5e85-48ca-88b4-936bc040e6c3%40isocpp.org.
------=_Part_28_1654768772.1465664474850
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Sunday, May 29, 2016 at 3:01:09 AM UTC-7, Vicen=
te J. Botet Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>Hi,<br>
</p>
<p><br>
</p>
<p>Using structured binding like syntax to mean await when we don't
want to await</p>
<p>For a lot of people it troubling to use await with std::expected
[P0323R0] as we don't await anything</p>
<p><br></p></div></blockquote><div><br></div><div>Just to comment on this p=
oint. One suggestion=C2=A0to improve readability of that use of away was to=
repurpose 'try' :-) .</div><div>So that you code=C2=A0looks:</div>=
<div><br></div><div>=C2=A0=C2=A0 int i =3D try foo(bla); // try will unpack=
expected<int> and propagate the error if required. Compile time erro=
r if used with future-like awaitables. </div><div><br></div><div>Just on th=
e readability side, if I had to chose between:</div><div><br></div><div>=C2=
=A0=C2=A0 int [i] =3D foo(bla) </div><div><br></div><div>vs</div><div><br><=
/div><div>=C2=A0=C2=A0 int=C2=A0i =3D try foo(bla);</div><div><br></div><di=
v>I would go with the latter.=C2=A0</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/fd851a3a-5e85-48ca-88b4-936bc040e6c3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fd851a3a-5e85-48ca-88b4-936bc040e6c3=
%40isocpp.org</a>.<br />
------=_Part_28_1654768772.1465664474850--
------=_Part_27_680934273.1465664474849--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sun, 12 Jun 2016 18:20:57 +0200
Raw View
This is a multi-part message in MIME format.
--------------38101017689E523772C81716
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 11/06/2016 =C3=A0 19:01, Gor Nishanov a =C3=A9crit :
>
>
> On Sunday, May 29, 2016 at 3:01:09 AM UTC-7, Vicente J. Botet Escriba=20
> wrote:
>
> Hi,
>
>
> Using structured binding like syntax to mean await when we don't
> want to await
>
> For a lot of people it troubling to use await with std::expected
> [P0323R0] as we don't await anything
>
>
>
> Just to comment on this point. One suggestion to improve readability=20
> of that use of away was to repurpose 'try' :-) .
> So that you code looks:
>
> int i =3D try foo(bla); // try will unpack expected<int> and=20
> propagate the error if required. Compile time error if used with=20
> future-like awaitables.
>
Beside disabling futures-like awaitable types, What would be the=20
difference between try and await?
> int [i] =3D foo(bla)
>
> vs
>
> int i =3D try foo(bla);
>
> I would go with the latter.
Yes, I find the try expression more appropriated.
Vicente
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/cc7864ac-8365-3d26-1f61-57ddc294ed5e%40wanadoo.f=
r.
--------------38101017689E523772C81716
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">Le 11/06/2016 =C3=A0 19:01, Gor Nishanov=
a
=C3=A9crit=C2=A0:<br>
</div>
<blockquote
cite=3D"mid:fd851a3a-5e85-48ca-88b4-936bc040e6c3@isocpp.org"
type=3D"cite">
<div dir=3D"ltr"><br>
<br>
On Sunday, May 29, 2016 at 3:01:09 AM UTC-7, Vicente J. Botet
Escriba wrote:
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<p>Hi,<br>
</p>
<p><br>
</p>
<p>Using structured binding like syntax to mean await when
we don't want to await</p>
<p>For a lot of people it troubling to use await with
std::expected [P0323R0] as we don't await anything</p>
<p><br>
</p>
</div>
</blockquote>
<div><br>
</div>
<div>Just to comment on this point. One suggestion=C2=A0to improve
readability of that use of away was to repurpose 'try' :-) .</div=
>
<div>So that you code=C2=A0looks:</div>
<div><br>
</div>
<div>=C2=A0=C2=A0 int i =3D try foo(bla); // try will unpack
expected<int> and propagate the error if required.
Compile time error if used with future-like awaitables. </div>
<div><br>
</div>
</div>
</blockquote>
Beside disabling futures-like awaitable types, What would be the
difference between try and await?
<blockquote
cite=3D"mid:fd851a3a-5e85-48ca-88b4-936bc040e6c3@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<div>=C2=A0=C2=A0 int [i] =3D foo(bla) </div>
<div><br>
</div>
<div>vs</div>
<div><br>
</div>
<div>=C2=A0=C2=A0 int=C2=A0i =3D try foo(bla);</div>
<div><br>
</div>
<div>I would go with the latter.=C2=A0</div>
</div>
</blockquote>
Yes, I find the try expression more appropriated.<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cc7864ac-8365-3d26-1f61-57ddc294ed5e%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cc7864ac-8365-3d26-1f61-57ddc294ed5e=
%40wanadoo.fr</a>.<br />
--------------38101017689E523772C81716--
.
Author: Gor Nishanov <gornishanov@gmail.com>
Date: Sun, 12 Jun 2016 10:22:32 -0700
Raw View
I did not spend any time thinking about it.
Probably it would be better to have something other than awaitable
with a simpler semantics. try_xxx equivalent of await_xxx.
It is possible that someone can come up with a cool generalization of
the "syntactic sugar" that coroutines do that is not tied to
coroutines (as in functions that can suspend their execution and
return control back to the caller to be resumed or destroyed at a
later point as desired).
If that works out, that would be great.
On Sun, Jun 12, 2016 at 9:20 AM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> Le 11/06/2016 =C3=A0 19:01, Gor Nishanov a =C3=A9crit :
>
>
>
> On Sunday, May 29, 2016 at 3:01:09 AM UTC-7, Vicente J. Botet Escriba wro=
te:
>>
>> Hi,
>>
>>
>> Using structured binding like syntax to mean await when we don't want to
>> await
>>
>> For a lot of people it troubling to use await with std::expected [P0323R=
0]
>> as we don't await anything
>>
>>
>
> Just to comment on this point. One suggestion to improve readability of t=
hat
> use of away was to repurpose 'try' :-) .
> So that you code looks:
>
> int i =3D try foo(bla); // try will unpack expected<int> and propagate=
the
> error if required. Compile time error if used with future-like awaitables=
..
>
> Beside disabling futures-like awaitable types, What would be the differen=
ce
> between try and await?
>
> int [i] =3D foo(bla)
>
> vs
>
> int i =3D try foo(bla);
>
> I would go with the latter.
>
> Yes, I find the try expression more appropriated.
>
> Vicente
>
> --
> 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/NkykzTGqH7Q/=
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.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc7864ac-836=
5-3d26-1f61-57ddc294ed5e%40wanadoo.fr.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAJ4VuxsF56gcafA15-a6eiN3%2BvsHdEOf8NTqg7w6-S0b9=
fTCpQ%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 12 Jun 2016 12:57:02 -0700 (PDT)
Raw View
------=_Part_4970_1525010888.1465761422458
Content-Type: multipart/alternative;
boundary="----=_Part_4971_17505074.1465761422458"
------=_Part_4971_17505074.1465761422458
Content-Type: text/plain; charset=UTF-8
On Sunday, June 12, 2016 at 1:22:34 PM UTC-4, Gor Nishanov wrote:
>
> I did not spend any time thinking about it.
>
> Probably it would be better to have something other than awaitable
> with a simpler semantics. try_xxx equivalent of await_xxx.
>
> It is possible that someone can come up with a cool generalization of
> the "syntactic sugar" that coroutines do that is not tied to
> coroutines (as in functions that can suspend their execution and
> return control back to the caller to be resumed or destroyed at a
> later point as desired).
>
> If that works out, that would be great.
>
This particular use case doesn't require any form of coroutine sugar. It's
simply using `await` to provoke a *return*.
Thus, what you want is for `try <expr>` to be effectively:
auto &&__var = <expr>;
if(!<TEST>(__var))
return <ERROR>(__var);
else
<VALUE>(std::forward<decltype(__var)>(__var));
Where `<TEST>`, `<ERROR>`, and <VALUE> would be the configurable entry
points. I'd suggest ADL-functions like `try_test`, `try_error`, and
`try_value`.
Thus, a `try <expr>` tests the expression, and will either exit the
function by retruning the extracted value, or result in extracting some
value from the expression.
Of course, temporary lifetime issues can be a problem here.
--
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/3f375337-b570-4759-9a11-b35a249b2bbc%40isocpp.org.
------=_Part_4971_17505074.1465761422458
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, June 12, 2016 at 1:22:34 PM UTC-4, Gor Nishanov=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I did not spend any tim=
e thinking about it.
<br>
<br>Probably it would be better to have something other than awaitable
<br>with a simpler semantics. try_xxx equivalent of await_xxx.
<br>
<br>It is possible that someone can come up with a cool generalization of
<br>the "syntactic sugar" that coroutines do that is not tied to
<br>coroutines (as in functions that can suspend their execution and
<br>return control back to the caller to be resumed or destroyed at a
<br>later point as desired).
<br>
<br>If that works out, that would be great.<br></blockquote><div><br>This p=
articular use case doesn't require any form of coroutine sugar. It'=
s simply using `await` to provoke a <i>return</i>.<br><br>Thus, what you wa=
nt is for `try <expr>` to be effectively:<br><br><div class=3D"pretty=
print" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187=
, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;=
"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"=
color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&&</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">__var </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-pr=
ettify"><expr></span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(!<</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">TEST</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">>(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">__var</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">))</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">ERROR</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">>(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">__var</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">else</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">VALUE</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">>(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">forward</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">decltype</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">__var</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">_=
_var</span><span style=3D"color: #660;" class=3D"styled-by-prettify">));</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></=
div></code></div><br>Where `<TEST>`, `<ERROR>`, and <VALUE&g=
t; would be the configurable entry points. I'd suggest ADL-functions li=
ke `try_test`, `try_error`, and `try_value`.</div><br>Thus, a `try <expr=
>` tests the expression, and will either exit the function by retruning =
the extracted value, or result in extracting some value from the expression=
..<br><br>Of course, temporary lifetime issues can be a problem here.<br></d=
iv>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3f375337-b570-4759-9a11-b35a249b2bbc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3f375337-b570-4759-9a11-b35a249b2bbc=
%40isocpp.org</a>.<br />
------=_Part_4971_17505074.1465761422458--
------=_Part_4970_1525010888.1465761422458--
.