Topic: Statement expressions proposal
Author: szollosi.lorand@gmail.com
Date: Mon, 6 Feb 2017 17:57:56 -0800 (PST)
Raw View
------=_Part_1583_29781482.1486432676281
Content-Type: multipart/alternative;
boundary="----=_Part_1584_735286980.1486432676281"
------=_Part_1584_735286980.1486432676281
Content-Type: text/plain; charset=UTF-8
Hi,
Please find below the initial draft for a statement expression proposal.
Any ideas, hints, suggestions are welcome. I understand that it's my first
proposal and it might take several iterations if ever to make if fly, so
I'd be very glad about points where I could make it better (one of them is
formatting, which I'm going to fix); whether to add more detail or less;
whether to change examples.
Link to the proposal's initial draft:
http://lorro.hu/cplusplus/statement_expressions.html
Thanks in advance,
-lorro
--
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/1df2e5b0-bbf8-4f5f-9eff-5e339516b99e%40isocpp.org.
------=_Part_1584_735286980.1486432676281
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>Please find below the initial draft for a state=
ment expression proposal. Any ideas, hints, suggestions are welcome. I unde=
rstand that it's my first proposal and it might take several iterations=
if ever to make if fly, so I'd be very glad about points where I could=
make it better (one of them is formatting, which I'm going to fix); wh=
ether to add more detail or less; whether to change examples.<br><br>Link t=
o the proposal's initial draft:<br>http://lorro.hu/cplusplus/statement_=
expressions.html<br><br>Thanks in advance,<br>-lorro<br></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/1df2e5b0-bbf8-4f5f-9eff-5e339516b99e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1df2e5b0-bbf8-4f5f-9eff-5e339516b99e=
%40isocpp.org</a>.<br />
------=_Part_1584_735286980.1486432676281--
------=_Part_1583_29781482.1486432676281--
.
Author: gmisocpp@gmail.com
Date: Mon, 6 Feb 2017 18:39:17 -0800 (PST)
Raw View
------=_Part_2486_756433064.1486435158143
Content-Type: multipart/alternative;
boundary="----=_Part_2487_738627271.1486435158143"
------=_Part_2487_738627271.1486435158143
Content-Type: text/plain; charset=UTF-8
I haven't yet fully grasped this proposal yet, but one thing that
immediately stands out as undesirable to me is the sort of floating
expression
at the end. e.g. this from your example:
int product = ({
int j = 1;
for (auto i : v)
j *= i;
j;
});
I very much would prefer at a minimum, this:
int product = ({
int j = 1;
for (auto i : v)
j *= i;
produce j;
});
More generally I wonder if extending inline functions with something might
be a nicer route:
inline int getProductOrReturn() // or maybe inline statement keyword some
introduction is needed.
{
if (somethingOutlandish())
inline return; // No really return from wherever this code gets
inlined.
int j = 1;
for (auto i : v)
j *= i;
return j;
};
But I haven't thought too hard about this later idea. What you are
proposing may be preferable to that, I haven't digested your proposal yet.
On Tuesday, February 7, 2017 at 2:57:56 PM UTC+13, szollos...@gmail.com
wrote:
> Hi,
>
> Please find below the initial draft for a statement expression proposal.
> Any ideas, hints, suggestions are welcome. I understand that it's my first
> proposal and it might take several iterations if ever to make if fly, so
> I'd be very glad about points where I could make it better (one of them is
> formatting, which I'm going to fix); whether to add more detail or less;
> whether to change examples.
>
> Link to the proposal's initial draft:
> http://lorro.hu/cplusplus/statement_expressions.html
>
> Thanks in advance,
> -lorro
>
--
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/97a294fa-dde9-4742-b887-c2b3744b0146%40isocpp.org.
------=_Part_2487_738627271.1486435158143
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I haven't yet fully grasped this proposal yet, bu=
t one thing=C2=A0that immediately stands out as undesirable to me is the so=
rt of floating expression</div><div>at the end. e.g. this from your example=
:</div><div><br></div><div>int product =3D ({<br>=C2=A0=C2=A0=C2=A0 int j =
=3D 1;<br>=C2=A0=C2=A0=C2=A0 for (auto i : v)<br>=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 j *=3D i;<br>=C2=A0=C2=A0=C2=A0 j;<br>});</div><div><br>=
</div><div>I very much would prefer at a minimum, this:</div><div><br></div=
><div><div>int product =3D ({<br>=C2=A0=C2=A0=C2=A0 int j =3D 1;<br>=C2=A0=
=C2=A0=C2=A0 for (auto i : v)<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
j *=3D i;<br>=C2=A0=C2=A0=C2=A0 produce j;<br>});</div><div><br></div><div=
>More generally I wonder if extending inline functions with something might=
be a nicer route:</div><div><br></div><div><div>inline int=C2=A0getProduct=
OrReturn() // or maybe inline statement keyword=C2=A0some introduction is n=
eeded.</div><div>{</div><div>=C2=A0=C2=A0=C2=A0 if (somethingOutlandish())<=
/div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inline return; // No r=
eally return from wherever this code gets inlined.<br>=C2=A0=C2=A0=C2=A0 in=
t j =3D 1;<br>=C2=A0=C2=A0=C2=A0 for (auto i : v)<br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 j *=3D i;<br>=C2=A0=C2=A0=C2=A0=C2=A0return j;<br>};<=
/div></div><div><br></div><div>But I haven't thought too hard about thi=
s later idea. What you are proposing may be preferable to that, I haven'=
;t digested=C2=A0your proposal yet.</div></div><div><br><br>On Tuesday, Feb=
ruary 7, 2017 at 2:57:56 PM UTC+13, szollos...@gmail.com wrote:</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-lef=
t: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bord=
er-left-style: solid;"><div dir=3D"ltr">Hi,<br><br>Please find below the in=
itial draft for a statement expression proposal. Any ideas, hints, suggesti=
ons are welcome. I understand that it's my first proposal and it might =
take several iterations if ever to make if fly, so I'd be very glad abo=
ut points where I could make it better (one of them is formatting, which I&=
#39;m going to fix); whether to add more detail or less; whether to change =
examples.<br><br>Link to the proposal's initial draft:<br><a onmousedow=
n=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Florro.hu%=
2Fcplusplus%2Fstatement_expressions.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3d=
AFQjCNHLZIb6auYtRyI2yunCdZC9m0_UdA';return true;" onclick=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Florro.hu%2Fcplusplus%2F=
statement_expressions.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHLZIb6au=
YtRyI2yunCdZC9m0_UdA';return true;" href=3D"http://lorro.hu/cplusplus/s=
tatement_expressions.html" target=3D"_blank" rel=3D"nofollow">http://lorro.=
hu/cplusplus/<wbr>statement_expressions.html</a><br><br>Thanks in advance,<=
br>-lorro<br></div></blockquote></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/97a294fa-dde9-4742-b887-c2b3744b0146%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/97a294fa-dde9-4742-b887-c2b3744b0146=
%40isocpp.org</a>.<br />
------=_Part_2487_738627271.1486435158143--
------=_Part_2486_756433064.1486435158143--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 7 Feb 2017 11:01:57 +0800
Raw View
--Apple-Mail=_61999793-17D4-48D4-8EB0-18D2C14B057A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
There was a recent discussion on this list, =E2=80=9Ccapturing monads in la=
mbda,=E2=80=9D about continuation capture in lambda expressions, i.e. [retu=
rn]{ return 23; }.
That proposal suggested that the continuation could be passed into, for ins=
tance, functions from <algorithm> and it would implement dynamic unwinding =
like throw. You seem to be not proposing that, but it=E2=80=99s unclear wha=
t mechanism prohibits it from happening. What happens when a reference or p=
ointer is taken to a named statement expression? Is the name a new kind of =
entity?
> The entire SE has the evaluation type of the last expression, but special=
care must be taken as control might be transferred before reaching the las=
t expression.
A better solution is needed. GCC statement expressions are a precedent and =
they=E2=80=99re widely implemented, but usability is a more important facto=
r.
--=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/CE93D21A-1D68-41F4-9727-7918E9BC6271%40gmail.com=
..
--Apple-Mail=_61999793-17D4-48D4-8EB0-18D2C14B057A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D"">There was a recent=
discussion on this list, =E2=80=9C<font face=3D"Helvetica Neue" class=3D""=
><i class=3D"">capturing monads in lambda</i>,=E2=80=9D</font> about c=
ontinuation capture in lambda expressions, i.e. <font face=3D"Courier" clas=
s=3D"">[return]{ return 23; }</font>.<div class=3D""><br class=3D""></div><=
div class=3D"">That proposal suggested that the continuation could be passe=
d into, for instance, functions from <font face=3D"Courier" class=3D""><=
algorithm></font> and it would implement dynamic unwinding like <fo=
nt face=3D"Courier" class=3D"">throw</font>. You seem to be not proposing t=
hat, but it=E2=80=99s unclear what mechanism prohibits it from happening. W=
hat happens when a reference or pointer is taken to a named statement expre=
ssion? Is the name a new kind of entity?</div><div class=3D""><br class=3D"=
"></div><div class=3D""><blockquote type=3D"cite" class=3D"">The entire SE =
has the evaluation type of the last expression, but special care must be ta=
ken as control might be transferred before reaching the last expressio=
n.<br class=3D""></blockquote><div class=3D""><br class=3D""></div><div cla=
ss=3D"">A better solution is needed. GCC statement expressions are a preced=
ent and they=E2=80=99re widely implemented, but usability is a more importa=
nt factor.</div></div><div class=3D""><br class=3D""></div></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/CE93D21A-1D68-41F4-9727-7918E9BC6271%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CE93D21A-1D68-41F4-9727-7918E9BC6271%=
40gmail.com</a>.<br />
--Apple-Mail=_61999793-17D4-48D4-8EB0-18D2C14B057A--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 06 Feb 2017 22:45:59 -0500
Raw View
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
255, 255); line-height: initial;"> =
<div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">I highly recommend, for almost any proposal, to include "before=
and after tables" (I think the committee has a some nick name for these), =
showing what you would currently need to write using C++17 on the left, and=
how it could be rewritten in C++20 using your proposal on the right. </div=
><div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slat=
e Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initia=
l; background-color: rgb(255, 255, 255);"><br></div><div style=3D"width: 10=
0%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans=
-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb=
(255, 255, 255);">The table thus shows both motivation and syntax in a comp=
act form. <span style=3D"font-size: initial; line-height: initial; tex=
t-align: initial;"></span></div> =
=
<div style=3D"width: 100%; font-size: initial; font-family: =
Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text=
-align: initial; background-color: rgb(255, 255, 255);"><br style=3D"displa=
y:initial"></div> =
=
<div style=3D=
"font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-se=
rif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(25=
5, 255, 255);">Sent from my BlackBerry portable Ba=
bbage Device</div> =
=
<table width=3D"100%" st=
yle=3D"background-color:white;border-spacing:0px;"> <tbody><tr><td colspan=
=3D"2" style=3D"font-size: initial; text-align: initial; background-color: =
rgb(255, 255, 255);"> <div style=3D"border-style:=
solid none none; border-top-color: rgb(181, 196, 223); border-top-width: 1=
pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'=
; font-size: 10pt;"> <div><b>From: </b>szollosi.lorand@gmail.com</div><div=
><b>Sent: </b>Monday, February 6, 2017 8:57 PM</div><div><b>To: </b>ISO C++=
Standard - Future Proposals</div><div><b>Reply To: </b>std-proposals@isocp=
p.org</div><div><b>Subject: </b>[std-proposals] Statement expressions propo=
sal</div></div></td></tr></tbody></table><div style=3D"border-style: solid =
none none; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; fon=
t-size: initial; text-align: initial; background-color: rgb(255, 255, 255);=
"></div><br><div id=3D"_originalContent" style=3D""><div dir=3D"ltr">Hi,<br=
><br>Please find below the initial draft for a statement expression proposa=
l. Any ideas, hints, suggestions are welcome. I understand that it's my fir=
st proposal and it might take several iterations if ever to make if fly, so=
I'd be very glad about points where I could make it better (one of them is=
formatting, which I'm going to fix); whether to add more detail or less; w=
hether to change examples.<br><br>Link to the proposal's initial draft:<br>=
http://lorro.hu/cplusplus/statement_expressions.html<br><br>Thanks in advan=
ce,<br>-lorro<br></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "=
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/1df2e5b0-bbf8-4f5f-9eff-5e339516b99e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/1df2e5b0-bbf8-4f5f-9eff-5e339516=
b99e%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></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/20170207034559.4894799.31919.24401%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20170207034559.4894799.31919.24401%40gm=
ail.com</a>.<br />
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Tue, 7 Feb 2017 11:18:57 +0100
Raw View
--f403045ec90e7992e70547ee13cf
Content-Type: text/plain; charset=UTF-8
I may be misunderstanding something, but how is the proposed ({ statements;
expr; }) different from [&]{ statements; return expr; }()? Is there more to
it?
The parametric part looks even more like a regular lambda definition. What
is the benefit of all this?
Cheers,
V.
--
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/CAA7YVg1FT89qEtthFXGaLPZcUTcms2cQ2PzNuRGs_QXztkF2%2Bw%40mail.gmail.com.
--f403045ec90e7992e70547ee13cf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">I ma=
y be misunderstanding something, but how is the proposed ({ statements; exp=
r; }) different from [&]{ statements; return expr; }()? Is there more t=
o it?</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">=
The parametric part looks even more like a regular lambda definition. What =
is the benefit of all this?</div><div class=3D"gmail_quote"><br></div><div =
class=3D"gmail_quote">Cheers,</div><div class=3D"gmail_quote">V.</div></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/CAA7YVg1FT89qEtthFXGaLPZcUTcms2cQ2PzN=
uRGs_QXztkF2%2Bw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1FT89qEt=
thFXGaLPZcUTcms2cQ2PzNuRGs_QXztkF2%2Bw%40mail.gmail.com</a>.<br />
--f403045ec90e7992e70547ee13cf--
.
Author: TONGARI J <tongari95@gmail.com>
Date: Tue, 7 Feb 2017 22:20:41 +0800
Raw View
--001a11351e2cf7c5230547f17391
Content-Type: text/plain; charset=UTF-8
2017-02-07 18:18 GMT+08:00 Viacheslav Usov <via.usov@gmail.com>:
> I may be misunderstanding something, but how is the proposed ({
> statements; expr; }) different from [&]{ statements; return expr; }()? Is
> there more to it?
>
The control flow. You can use 'return', 'break', etc inside the block that
can get you to the outer block, which is what lambda expression can't do.
--
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/CANCwVhdOrmH2kBv8c1735-HV64p7gv%3DdQ3mLpKyxqmuSnv3fGg%40mail.gmail.com.
--001a11351e2cf7c5230547f17391
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-02-07 18:18 GMT+08:00 Viacheslav Usov <span dir=3D"ltr"><<a href=3D"mai=
lto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>></span>=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_ex=
tra"><div class=3D"gmail_quote">I may be misunderstanding something, but ho=
w is the proposed ({ statements; expr; }) different from [&]{ statement=
s; return expr; }()? Is there more to it?</div></div></div></blockquote><di=
v><br></div><div>The control flow. You can use 'return', 'break=
', etc inside the block that can get you to the outer block, which is w=
hat lambda expression can't do.</div></div></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/CANCwVhdOrmH2kBv8c1735-HV64p7gv%3DdQ3=
mLpKyxqmuSnv3fGg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANCwVhdOrmH2kB=
v8c1735-HV64p7gv%3DdQ3mLpKyxqmuSnv3fGg%40mail.gmail.com</a>.<br />
--001a11351e2cf7c5230547f17391--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 7 Feb 2017 06:50:08 -0800 (PST)
Raw View
------=_Part_1789_1715987576.1486479008158
Content-Type: multipart/alternative;
boundary="----=_Part_1790_1978540577.1486479008158"
------=_Part_1790_1978540577.1486479008158
Content-Type: text/plain; charset=UTF-8
On Monday, February 6, 2017 at 9:39:18 PM UTC-5, gmis...@gmail.com wrote:
>
> I haven't yet fully grasped this proposal yet, but one thing that
> immediately stands out as undesirable to me is the sort of floating
> expression
> at the end. e.g. this from your example:
>
> int product = ({
> int j = 1;
> for (auto i : v)
> j *= i;
> j;
> });
>
> I very much would prefer at a minimum, this:
>
> int product = ({
> int j = 1;
> for (auto i : v)
> j *= i;
> produce j;
> });
>
This would also be important if you have any significant control flow going
on. Like `if(...) produce j; else produce k;` Obviously, you could ?: that,
but there are more complex situations where that becomes impractical.
To bikeshed for a moment, we already have `co_return` in P0057. So
different forms of `return` statements are now at least semi-standard.
Having a new form of "return" that returns a value as the expression of the
innermost expression statement would be valid. Perhaps `in_return`.
More generally I wonder if extending inline functions with something might
> be a nicer route:
>
The point of a statement expression is that it's *part of* the current
function. It's not doing a separate call; it's just a block of code that
produces a value. That way, you can still do things like access local
variables and parameters, use `break` and `return` as if you were in the
function (which you are) etc.
Calling a function, even an `inline` function, is not helpful for this
purpose.
--
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/fce86783-9b7d-40ab-8670-8870fa13db82%40isocpp.org.
------=_Part_1790_1978540577.1486479008158
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, February 6, 2017 at 9:39:18 PM UTC-5, gmis...@g=
mail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div>I haven't yet fully grasped this proposal yet, but one thing=C2=
=A0that immediately stands out as undesirable to me is the sort of floating=
expression</div><div>at the end. e.g. this from your example:</div><div><b=
r></div><div>int product =3D ({<br>=C2=A0=C2=A0=C2=A0 int j =3D 1;<br>=C2=
=A0=C2=A0=C2=A0 for (auto i : v)<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 j *=3D i;<br>=C2=A0=C2=A0=C2=A0 j;<br>});</div><div><br></div><div>I ve=
ry much would prefer at a minimum, this:</div><div><br></div><div><div>int =
product =3D ({<br>=C2=A0=C2=A0=C2=A0 int j =3D 1;<br>=C2=A0=C2=A0=C2=A0 for=
(auto i : v)<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 j *=3D i;<br>=
=C2=A0=C2=A0=C2=A0 produce j;<br>});</div></div></div></blockquote><div><br=
>This would also be important if you have any significant control flow goin=
g on. Like `if(...) produce j; else produce k;` Obviously, you could ?: tha=
t, but there are more complex situations where that becomes impractical.<br=
><br>To bikeshed for a moment, we already have `co_return` in P0057. So dif=
ferent forms of `return` statements are now at least semi-standard. Having =
a new form of "return" that returns a value as the expression of =
the innermost expression statement would be valid. Perhaps `in_return`.<br>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v><div></div><div>More generally I wonder if extending inline functions wit=
h something might be a nicer route:</div></div></div></blockquote><div><br>=
The point of a statement expression is that it's <i>part of</i> the cur=
rent function. It's not doing a separate call; it's just a block of=
code that produces a value. That way, you can still do things like access =
local variables and parameters, use `break` and `return` as if you were in =
the function (which you are) etc.<br><br>Calling a function, even an `inlin=
e` function, is not helpful for this purpose.</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/fce86783-9b7d-40ab-8670-8870fa13db82%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fce86783-9b7d-40ab-8670-8870fa13db82=
%40isocpp.org</a>.<br />
------=_Part_1790_1978540577.1486479008158--
------=_Part_1789_1715987576.1486479008158--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 7 Feb 2017 16:52:35 +0200
Raw View
On 7 February 2017 at 16:50, Nicol Bolas <jmckesson@gmail.com> wrote:
>> More generally I wonder if extending inline functions with something might
>> be a nicer route:
>
>
> The point of a statement expression is that it's part of the current
> function. It's not doing a separate call; it's just a block of code that
> produces a value. That way, you can still do things like access local
> variables and parameters, use `break` and `return` as if you were in the
> function (which you are) etc.
Here's a question: how do I get from this proposal to a
statement-expression template?
I want to write generic code blocks that I can glue into other places,
passing template
arguments that guide how the code is instantiated.
--
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/CAFk2RUYgvAUNpM3JjQ-h6wLt_VtXLzmoVMOrzYoKj6C%2BKjENuA%40mail.gmail.com.
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Tue, 7 Feb 2017 15:56:58 +0100
Raw View
--001a11407132c04d3d0547f1f56f
Content-Type: text/plain; charset=UTF-8
On Tue, Feb 7, 2017 at 3:20 PM, TONGARI J <tongari95@gmail.com> wrote:
> The control flow. You can use 'return', 'break', etc inside the block
that can get you to the outer block, which is what lambda expression can't
do.
I see.
Well, not really. I do not see that explained in the proposal at all. I
only see a return in an if statement there, but *that* you can have in a
lambda.
I'd say that the proposal has a lot to explain before it can be called a
proposal.
Cheers,
V.
--
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/CAA7YVg2x8Zzb-3Gj84tOi8pghinpn4ED0QzYWyp9ZvCE2eT2uQ%40mail.gmail.com.
--001a11407132c04d3d0547f1f56f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Feb 7, 2017 at 3:20 PM, TONGARI J <span dir=3D"ltr"><<a href=3D"mail=
to:tongari95@gmail.com" target=3D"_blank">tongari95@gmail.com</a>></span=
> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quot=
e">> The control flow. You can use 'return', 'break', et=
c inside the block that can get you to the outer block, which is what lambd=
a expression can't do.</div><div class=3D"gmail_quote"><br></div><div c=
lass=3D"gmail_quote">I see.</div><div class=3D"gmail_quote"><br></div><div =
class=3D"gmail_quote">Well, not really. I do not see that explained in the =
proposal at all. I only see a return in an if statement there, but <i>that<=
/i>=C2=A0you can have in a lambda.</div><div class=3D"gmail_quote"><br></di=
v><div class=3D"gmail_quote">I'd say that the proposal has a lot to exp=
lain before it can be called a proposal.</div><div class=3D"gmail_quote"><b=
r></div><div class=3D"gmail_quote">Cheers,</div><div class=3D"gmail_quote">=
V.</div></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/CAA7YVg2x8Zzb-3Gj84tOi8pghinpn4ED0QzY=
Wyp9ZvCE2eT2uQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2x8Zzb-3Gj=
84tOi8pghinpn4ED0QzYWyp9ZvCE2eT2uQ%40mail.gmail.com</a>.<br />
--001a11407132c04d3d0547f1f56f--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Tue, 7 Feb 2017 06:57:27 -0800 (PST)
Raw View
------=_Part_795_484942680.1486479448188
Content-Type: multipart/alternative;
boundary="----=_Part_796_1944131224.1486479448189"
------=_Part_796_1944131224.1486479448189
Content-Type: text/plain; charset=UTF-8
On Monday, February 6, 2017 at 7:57:56 PM UTC-6, szollos...@gmail.com wrote:
>
> Hi,
>
> Please find below the initial draft for a statement expression proposal.
> Any ideas, hints, suggestions are welcome. I understand that it's my first
> proposal and it might take several iterations if ever to make if fly, so
> I'd be very glad about points where I could make it better (one of them is
> formatting, which I'm going to fix); whether to add more detail or less;
> whether to change examples.
>
> Link to the proposal's initial draft:
> http://lorro.hu/cplusplus/statement_expressions.html
>
> Thanks in advance,
> -lorro
>
One thing we would want to ensure for something like this example:
#define return_if_false(a) ({ auto tmp = (a); if (!tmp) return std::move(tmp
); std::move(tmp); })
is that all the return copy-elision rules apply in this case as well. We'd
probably want to be able to write it like:
#define return_if_false(a) ({ auto tmp = (a); if (!tmp) return tmp; tmp; })
auto x = return_if_false(y); // tmp is constructed in place in x, if the
return branch isn't taken
GCC's current implementation doesn't have this kind of copy-elision.
--
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/d3228c76-242f-415b-b4c7-0fbb757cbfc8%40isocpp.org.
------=_Part_796_1944131224.1486479448189
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, February 6, 2017 at 7:57:56 PM UTC-6, s=
zollos...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
dir=3D"ltr">Hi,<br><br>Please find below the initial draft for a statement=
expression proposal. Any ideas, hints, suggestions are welcome. I understa=
nd that it's my first proposal and it might take several iterations if =
ever to make if fly, so I'd be very glad about points where I could mak=
e it better (one of them is formatting, which I'm going to fix); whethe=
r to add more detail or less; whether to change examples.<br><br>Link to th=
e proposal's initial draft:<br><a href=3D"http://lorro.hu/cplusplus/sta=
tement_expressions.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Florro.hu%2Fcpl=
usplus%2Fstatement_expressions.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjC=
NHLZIb6auYtRyI2yunCdZC9m0_UdA';return true;" onclick=3D"this.href=3D=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Florro.hu%2Fcplusplus%2Fstatem=
ent_expressions.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHLZIb6auYtRyI2=
yunCdZC9m0_UdA';return true;">http://lorro.hu/cplusplus/<wbr>statement_=
expressions.html</a><br><br>Thanks in advance,<br>-lorro<br></div></blockqu=
ote><div><br></div><div>One thing we would want to ensure for something lik=
e this example:</div><div><br></div><div><span style=3D"color: rgb(0, 0, 0)=
;"><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250)=
; border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px;=
word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprett=
yprint"><span style=3D"color: #800;" class=3D"styled-by-prettify">#define</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> return_if_f=
alse</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">a</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">({</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> tmp </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">a</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">if</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(!</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">tmp</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">return</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"colo=
r: #000;" class=3D"styled-by-prettify">move</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">tmp</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">move<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">tmp</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">})</span></div></code></div></span></div><di=
v><br></div><div>is that all the return copy-elision rules apply in this ca=
se as well. We'd probably want to be able to write it like:</div><div><=
br></div><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250=
, 250); border-color: rgb(187, 187, 187); border-style: solid; border-width=
: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #800;" class=3D"styled-by-prettify">#de=
fine</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> retur=
n_if_false</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">({</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> tmp </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">a</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">if</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"styled-=
by-prettify">tmp</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> tmp</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> tmp</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</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"styled-b=
y-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> return_if_fal=
se</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">y</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">// tmp is constructed in place in x, if the=
return branch isn't taken</span></div></code></div><div><font color=3D=
"#000000"><br></font></div><div><font color=3D"#000000">GCC's current i=
mplementation doesn't have this kind of copy-elision.=C2=A0</font></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/d3228c76-242f-415b-b4c7-0fbb757cbfc8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d3228c76-242f-415b-b4c7-0fbb757cbfc8=
%40isocpp.org</a>.<br />
------=_Part_796_1944131224.1486479448189--
------=_Part_795_484942680.1486479448188--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 7 Feb 2017 07:04:28 -0800 (PST)
Raw View
------=_Part_1773_1687325082.1486479868599
Content-Type: multipart/alternative;
boundary="----=_Part_1774_430393821.1486479868599"
------=_Part_1774_430393821.1486479868599
Content-Type: text/plain; charset=UTF-8
On Monday, February 6, 2017 at 8:57:56 PM UTC-5, szollos...@gmail.com wrote:
>
> Hi,
>
> Please find below the initial draft for a statement expression proposal.
> Any ideas, hints, suggestions are welcome. I understand that it's my first
> proposal and it might take several iterations if ever to make if fly, so
> I'd be very glad about points where I could make it better (one of them is
> formatting, which I'm going to fix); whether to add more detail or less;
> whether to change examples.
>
> Link to the proposal's initial draft:
> http://lorro.hu/cplusplus/statement_expressions.html
>
>
I see a lot of what I would consider needless restrictions in this
proposal. It makes no sense to only allow some statements inside a
statement expression. Functions don't have restrictions on the classes you
can create within them, besides the fact that they cannot be templates. As
such, there's no reason for statement expressions to have that restriction
either.
Either a statement expression allows *statements*, or it doesn't. It
shouldn't be a subset of statements.
It's good that you've looked at existing implementations. But you shouldn't
let that restrict the proposal unduly. Not unless you have specific
knowledge that such implementations would be a hardship.
At the end of the day, a "statement expression" isn't really a thing. It's
just a grammatical construct that allows multiple statements to potentially
resolve to a value that gets used to initialize an object. It should not be
limited in what it can do relative to that.
Now, parameters and "named statements", I don't think those should even be
part of the proposal. That's macro-style thinking, and that's not really
what this is about. Once it has a name, that means you have to decide what
that name means. Is it a function? If so, what can you do with it. And so
on. Those are too complicated to deal with in such a proposal.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8e589360-0c87-4341-83b4-9274d57b5160%40isocpp.org.
------=_Part_1774_430393821.1486479868599
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, February 6, 2017 at 8:57:56 PM UTC-5, szollos..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">Hi,<br><br>Please find below the initial draft for a statement express=
ion proposal. Any ideas, hints, suggestions are welcome. I understand that =
it's my first proposal and it might take several iterations if ever to =
make if fly, so I'd be very glad about points where I could make it bet=
ter (one of them is formatting, which I'm going to fix); whether to add=
more detail or less; whether to change examples.<br><br>Link to the propos=
al's initial draft:<br><a href=3D"http://lorro.hu/cplusplus/statement_e=
xpressions.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Florro.hu%2Fcplusplus%2=
Fstatement_expressions.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHLZIb6a=
uYtRyI2yunCdZC9m0_UdA';return true;" onclick=3D"this.href=3D'http:/=
/www.google.com/url?q\x3dhttp%3A%2F%2Florro.hu%2Fcplusplus%2Fstatement_expr=
essions.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHLZIb6auYtRyI2yunCdZC9=
m0_UdA';return true;">http://lorro.hu/cplusplus/<wbr>statement_expressi=
ons.html</a><br><br></div></blockquote><div><br>I see a lot of what I would=
consider needless restrictions in this proposal. It makes no sense to only=
allow some statements inside a statement expression. Functions don't h=
ave restrictions on the classes you can create within them, besides the fac=
t that they cannot be templates. As such, there's no reason for stateme=
nt expressions to have that restriction either.<br><br>Either a statement e=
xpression allows <i>statements</i>, or it doesn't. It shouldn't be =
a subset of statements.<br><br>It's good that you've looked at exis=
ting implementations. But you shouldn't let that restrict the proposal =
unduly. Not unless you have specific knowledge that such implementations wo=
uld be a hardship.<br><br>At the end of the day, a "statement expressi=
on" isn't really a thing. It's just a grammatical construct th=
at allows multiple statements to potentially resolve to a value that gets u=
sed to initialize an object. It should not be limited in what it can do rel=
ative to that.<br><br>Now, parameters and "named statements", I d=
on't think those should even be part of the proposal. That's macro-=
style thinking, and that's not really what this is about. Once it has a=
name, that means you have to decide what that name means. Is it a function=
? If so, what can you do with it. And so on. Those are too complicated to d=
eal with in such a proposal.<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/8e589360-0c87-4341-83b4-9274d57b5160%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8e589360-0c87-4341-83b4-9274d57b5160=
%40isocpp.org</a>.<br />
------=_Part_1774_430393821.1486479868599--
------=_Part_1773_1687325082.1486479868599--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 7 Feb 2017 07:05:53 -0800 (PST)
Raw View
------=_Part_1827_785013833.1486479953345
Content-Type: multipart/alternative;
boundary="----=_Part_1828_580024757.1486479953346"
------=_Part_1828_580024757.1486479953346
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 7, 2017 at 9:52:36 AM UTC-5, Ville Voutilainen wrote:
>
> On 7 February 2017 at 16:50, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> >> More generally I wonder if extending inline functions with something
> might
> >> be a nicer route:
> >
> >
> > The point of a statement expression is that it's part of the current
> > function. It's not doing a separate call; it's just a block of code that
> > produces a value. That way, you can still do things like access local
> > variables and parameters, use `break` and `return` as if you were in the
> > function (which you are) etc.
>
> Here's a question: how do I get from this proposal to a
> statement-expression template?
> I want to write generic code blocks that I can glue into other places,
> passing template
> arguments that guide how the code is instantiated.
>
You write a macro.
--
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/59c46395-df9e-4821-bb49-4eb731ce1eac%40isocpp.org.
------=_Part_1828_580024757.1486479953346
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, February 7, 2017 at 9:52:36 AM UTC-5, =
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 7 F=
ebruary 2017 at 16:50, Nicol Bolas <<a href=3D"javascript:" target=3D"_b=
lank" gdf-obfuscated-mailto=3D"C6neWEytAgAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;">jmck...@gmail.com</a>> wrote:
<br>>> More generally I wonder if extending inline functions with som=
ething might
<br>>> be a nicer route:
<br>>
<br>>
<br>> The point of a statement expression is that it's part of the c=
urrent
<br>> function. It's not doing a separate call; it's just a bloc=
k of code that
<br>> produces a value. That way, you can still do things like access lo=
cal
<br>> variables and parameters, use `break` and `return` as if you were =
in the
<br>> function (which you are) etc.
<br>
<br>
Here's a question: how do I get from this proposal to a
<br>statement-expression template?
<br>I want to write generic code blocks that I can glue into other places,
<br>passing template
<br>arguments that guide how the code is instantiated.
<br></blockquote><div><br>You write a macro.<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/59c46395-df9e-4821-bb49-4eb731ce1eac%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/59c46395-df9e-4821-bb49-4eb731ce1eac=
%40isocpp.org</a>.<br />
------=_Part_1828_580024757.1486479953346--
------=_Part_1827_785013833.1486479953345--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 7 Feb 2017 07:07:00 -0800 (PST)
Raw View
------=_Part_1835_604883175.1486480020960
Content-Type: multipart/alternative;
boundary="----=_Part_1836_332994734.1486480020960"
------=_Part_1836_332994734.1486480020960
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 7, 2017 at 9:57:02 AM UTC-5, Viacheslav Usov wrote:
>
> On Tue, Feb 7, 2017 at 3:20 PM, TONGARI J <tong...@gmail.com <javascript:>
> > wrote:
>
> > The control flow. You can use 'return', 'break', etc inside the block
> that can get you to the outer block, which is what lambda expression can't
> do.
>
> I see.
>
> Well, not really. I do not see that explained in the proposal at all. I
> only see a return in an if statement there, but *that* you can have in a
> lambda.
>
No, you can't. The return in the statement expression returns *from the
function itself*. A return in a lambda returns *from the lambda*.
>
> I'd say that the proposal has a lot to explain before it can be called a
> proposal.
>
> Cheers,
> V.
>
--
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/5c379cc7-100e-4818-86ad-36faeafab401%40isocpp.org.
------=_Part_1836_332994734.1486480020960
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, February 7, 2017 at 9:57:02 AM UTC-5, =
Viacheslav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On Tue, Feb 7, 2017 at 3:20 PM, TO=
NGARI J <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"VKFxFYqtAgAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D'javascript:';return true;" onclick=3D"this.href=3D'javasc=
ript:';return true;">tong...@gmail.com</a>></span> wrote:</div><div =
class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">> The control=
flow. You can use 'return', 'break', etc inside the block =
that can get you to the outer block, which is what lambda expression can=
9;t do.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote=
">I see.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quot=
e">Well, not really. I do not see that explained in the proposal at all. I =
only see a return in an if statement there, but <i>that</i>=C2=A0you can ha=
ve in a lambda.</div></div></div></blockquote><div><br>No, you can't. T=
he return in the statement expression returns <i>from the function itself</=
i>. A return in a lambda returns <i>from the lambda</i>.<br>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">I'd say that the =
proposal has a lot to explain before it can be called a proposal.</div><div=
class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Cheers,</div><d=
iv class=3D"gmail_quote">V.</div></div></div>
</blockquote></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/5c379cc7-100e-4818-86ad-36faeafab401%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5c379cc7-100e-4818-86ad-36faeafab401=
%40isocpp.org</a>.<br />
------=_Part_1836_332994734.1486480020960--
------=_Part_1835_604883175.1486480020960--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 7 Feb 2017 07:13:07 -0800 (PST)
Raw View
------=_Part_1764_530339829.1486480387185
Content-Type: multipart/alternative;
boundary="----=_Part_1765_1601279374.1486480387185"
------=_Part_1765_1601279374.1486480387185
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 7, 2017 at 9:57:28 AM UTC-5, Barry Revzin wrote:
>
>
>
> On Monday, February 6, 2017 at 7:57:56 PM UTC-6, szollos...@gmail.com
> wrote:
>>
>> Hi,
>>
>> Please find below the initial draft for a statement expression proposal.
>> Any ideas, hints, suggestions are welcome. I understand that it's my first
>> proposal and it might take several iterations if ever to make if fly, so
>> I'd be very glad about points where I could make it better (one of them is
>> formatting, which I'm going to fix); whether to add more detail or less;
>> whether to change examples.
>>
>> Link to the proposal's initial draft:
>> http://lorro.hu/cplusplus/statement_expressions.html
>>
>> Thanks in advance,
>> -lorro
>>
>
> One thing we would want to ensure for something like this example:
>
> #define return_if_false(a) ({ auto tmp = (a); if (!tmp) return std::move(
> tmp); std::move(tmp); })
>
> is that all the return copy-elision rules apply in this case as well. We'd
> probably want to be able to write it like:
>
> #define return_if_false(a) ({ auto tmp = (a); if (!tmp) return tmp; tmp;
> })
> auto x = return_if_false(y); // tmp is constructed in place in x, if the
> return branch isn't taken
>
> GCC's current implementation doesn't have this kind of copy-elision.
>
Presumably, elision would happen naturally. `tmp` is a local variable.
`return tmp` is a return statement. It doesn't matter *where* this
statement is, NRVO can be applied if it is returning a local
(non-parameter) object that matches the type.
Similarly, you seem to be talking more about lvalue-to-xvalue conversion
than NRVO. That is, `return tmp;`, even if the compiler cannot elide the
named variable, will still convert the lvalue into an xvalue for the
purpose of initializing the return value object. So `return tmp;` will move
into the return value if it is able.
And this suggests even more strongly the need for an explicit syntax to
resolve the value of a statement expression. That way, we can hook
`in_return tmp;` into the lvalue-to-xvalue machinery that already exists
for `return` and `co_return`. This would also allow us a way to specify
elision rules for `in_return`'s values in statement expressions.
--
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/1efcb423-abd0-4922-910a-7082321b0606%40isocpp.org.
------=_Part_1765_1601279374.1486480387185
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, February 7, 2017 at 9:57:28 AM UTC-5, =
Barry Revzin 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"><br><br>On Monday, February 6, 2017 at 7:57:56 PM UTC-6, <a>szollos..=
..@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">Hi,<br><br>Please find below the initial draft for a statement expressi=
on proposal. Any ideas, hints, suggestions are welcome. I understand that i=
t's my first proposal and it might take several iterations if ever to m=
ake if fly, so I'd be very glad about points where I could make it bett=
er (one of them is formatting, which I'm going to fix); whether to add =
more detail or less; whether to change examples.<br><br>Link to the proposa=
l's initial draft:<br><a href=3D"http://lorro.hu/cplusplus/statement_ex=
pressions.html" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Florro.hu%2Fcplusplus%2F=
statement_expressions.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHLZIb6au=
YtRyI2yunCdZC9m0_UdA';return true;" onclick=3D"this.href=3D'http://=
www.google.com/url?q\x3dhttp%3A%2F%2Florro.hu%2Fcplusplus%2Fstatement_expre=
ssions.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHLZIb6auYtRyI2yunCdZC9m=
0_UdA';return true;">http://lorro.hu/cplusplus/<wbr>statement_expressio=
ns.html</a><br><br>Thanks in advance,<br>-lorro<br></div></blockquote><div>=
<br></div><div>One thing we would want to ensure for something like this ex=
ample:</div><div><br></div><div><span style=3D"color:rgb(0,0,0)"><div style=
=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border-=
style:solid;border-width:1px;word-wrap:break-word"><code><div><span style=
=3D"color:#800">#define</span><span style=3D"color:#000"> return_if_false</=
span><span style=3D"color:#660">(</span><span style=3D"color:#000">a</span>=
<span style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span=
style=3D"color:#660">({</span><span style=3D"color:#000"> </span><span sty=
le=3D"color:#008">auto</span><span style=3D"color:#000"> tmp </span><span s=
tyle=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#000">a</span><span style=3D"=
color:#660">);</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#008">if</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
60">(!</span><span style=3D"color:#000">tmp</span><span style=3D"color:#660=
">)</span><span style=3D"color:#000"> </span><span style=3D"color:#008">ret=
urn</span><span style=3D"color:#000"> std</span><span style=3D"color:#660">=
::</span><span style=3D"color:#000">move</span><span style=3D"color:#660">(=
</span><span style=3D"color:#000">tmp</span><span style=3D"color:#660">);</=
span><span style=3D"color:#000"> std</span><span style=3D"color:#660">::</s=
pan><span style=3D"color:#000">move</span><span style=3D"color:#660">(</spa=
n><span style=3D"color:#000">tmp</span><span style=3D"color:#660">);</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#660">})</span></di=
v></code></div></span></div><div><br></div><div>is that all the return copy=
-elision rules apply in this case as well. We'd probably want to be abl=
e to write it like:</div><div><br></div><div style=3D"background-color:rgb(=
250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:=
1px;word-wrap:break-word"><code><div><span style=3D"color:#800">#define</sp=
an><span style=3D"color:#000"> return_if_false</span><span style=3D"color:#=
660">(</span><span style=3D"color:#000">a</span><span style=3D"color:#660">=
)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">({</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#008">auto</spa=
n><span style=3D"color:#000"> tmp </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#660">(</span><s=
pan style=3D"color:#000">a</span><span style=3D"color:#660">);</span><span =
style=3D"color:#000"> </span><span style=3D"color:#008">if</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">(!</span><span style=3D=
"color:#000">tmp</span><span style=3D"color:#660">)</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#008">return</span><span style=3D"co=
lor:#000"> tmp</span><span style=3D"color:#660">;</span><span style=3D"colo=
r:#000"> tmp</span><span style=3D"color:#660">;</span><span style=3D"color:=
#000"> </span><span style=3D"color:#660">})</span><span style=3D"color:#000=
"><br></span><span style=3D"color:#008">auto</span><span style=3D"color:#00=
0"> x </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000=
"> return_if_false</span><span style=3D"color:#660">(</span><span style=3D"=
color:#000">y</span><span style=3D"color:#660">);</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#800">// tmp is constructed in place i=
n x, if the return branch isn't taken</span></div></code></div><div><fo=
nt color=3D"#000000"><br></font></div><div><font color=3D"#000000">GCC'=
s current implementation doesn't have this kind of copy-elision.</font>=
</div></div></blockquote><div><br>Presumably, elision would happen naturall=
y. `tmp` is a local variable. `return tmp` is a return statement. It doesn&=
#39;t matter <i>where</i> this statement is, NRVO can be applied if it is r=
eturning a local (non-parameter) object that matches the type.<br><br>Simil=
arly, you seem to be talking more about lvalue-to-xvalue conversion than NR=
VO. That is, `return tmp;`, even if the compiler cannot elide the named var=
iable, will still convert the lvalue into an xvalue for the purpose of init=
ializing the return value object. So `return tmp;` will move into the retur=
n value if it is able.<br><br>And this suggests even more strongly the need=
for an explicit syntax to resolve the value of a statement expression. Tha=
t way, we can hook `in_return tmp;`=C2=A0 into the lvalue-to-xvalue machine=
ry that already exists for `return` and `co_return`. This would also allow =
us a way to specify elision rules for `in_return`'s values in statement=
expressions.<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/1efcb423-abd0-4922-910a-7082321b0606%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1efcb423-abd0-4922-910a-7082321b0606=
%40isocpp.org</a>.<br />
------=_Part_1765_1601279374.1486480387185--
------=_Part_1764_530339829.1486480387185--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Tue, 7 Feb 2017 16:13:19 +0100
Raw View
--f403045ea69633e8b20547f23016
Content-Type: text/plain; charset=UTF-8
On Tue, Feb 7, 2017 at 4:07 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> No, you can't. The return in the statement expression returns *from the
function itself*. A return in a lambda returns *from the lambda*.
Per your unpublished proposal, perhaps.
Per the subject of this thread, who knows.
Cheers,
V.
--
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/CAA7YVg3Gep2aMkFN6MWu-BPu5ELO_K-DF2KZCOs0%3DYmv85ckxw%40mail.gmail.com.
--f403045ea69633e8b20547f23016
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Feb 7, 2017 at 4:07 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></sp=
an> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_qu=
ote">> No, you can't. The return in the statement expression returns=
<i>from the function itself</i>. A return in a lambda returns <i>from the =
lambda</i>.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">Per your unpublished proposal, perhaps.</div><div class=3D"gmail_quot=
e"><br></div><div class=3D"gmail_quote">Per the subject of this thread, who=
knows.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote=
">Cheers,</div><div class=3D"gmail_quote">V.</div></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/CAA7YVg3Gep2aMkFN6MWu-BPu5ELO_K-DF2KZ=
COs0%3DYmv85ckxw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3Gep2aMk=
FN6MWu-BPu5ELO_K-DF2KZCOs0%3DYmv85ckxw%40mail.gmail.com</a>.<br />
--f403045ea69633e8b20547f23016--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 7 Feb 2017 07:29:16 -0800 (PST)
Raw View
------=_Part_1815_1057355355.1486481356160
Content-Type: multipart/alternative;
boundary="----=_Part_1816_389892683.1486481356160"
------=_Part_1816_389892683.1486481356160
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 7, 2017 at 10:13:22 AM UTC-5, Viacheslav Usov wrote:
>
> On Tue, Feb 7, 2017 at 4:07 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
> > No, you can't. The return in the statement expression returns *from the
> function itself*. A return in a lambda returns *from the lambda*.
>
> Per your unpublished proposal, perhaps.
>
> Per the subject of this thread, who knows.
>
.... we do know. It's right there in the Motivation section. The proposal
even has a pointless feature macro for it: __cplusplus_se_ret.
--
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/5472b5eb-1c0e-4c13-abe6-8b69ed16ea6f%40isocpp.org.
------=_Part_1816_389892683.1486481356160
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 7, 2017 at 10:13:22 AM UTC-5, Viaches=
lav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><div class=3D"gmail_quote">On Tue, Feb 7, 2017 at 4:07 PM, Nicol Bol=
as <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"u61ZRW6uAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">jmck...@gmail.com</a>></span> wrote:</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">> No, you can'=
t. The return in the statement expression returns <i>from the function itse=
lf</i>. A return in a lambda returns <i>from the lambda</i>.</div><div clas=
s=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Per your unpublished=
proposal, perhaps.</div><div class=3D"gmail_quote"><br></div><div class=3D=
"gmail_quote">Per the subject of this thread, who knows.</div></div></div><=
/blockquote><div><br>... we do know. It's right there in the Motivation=
section. The proposal even has a pointless feature macro for it: __cpluspl=
us_se_ret. <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/5472b5eb-1c0e-4c13-abe6-8b69ed16ea6f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5472b5eb-1c0e-4c13-abe6-8b69ed16ea6f=
%40isocpp.org</a>.<br />
------=_Part_1816_389892683.1486481356160--
------=_Part_1815_1057355355.1486481356160--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Tue, 7 Feb 2017 16:38:42 +0100
Raw View
--f403045ea0a8fda9030547f28aba
Content-Type: text/plain; charset=UTF-8
On Tue, Feb 7, 2017 at 4:29 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> ... we do know. It's right there in the Motivation section.
Nope. The motivation section has no verbiage like *from the function
itself.* The sample that it has can be interpreted either way (and it is
silly either way). You may have experience with something named
"statement expressions" in some other language or on some particular
implementation, so what they want to say may be (you think) clear to you.
It is not to me. To me that looks like a very low quality proposal, whose
readers need to guess what is being proposed.
Cheers,
V.
--
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/CAA7YVg2YE9mUc3LmmT3FZO0VKENTBjRoVqsFB3VjJwbjM5TgzQ%40mail.gmail.com.
--f403045ea0a8fda9030547f28aba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Feb 7, 2017 at 4:29 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></sp=
an> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_qu=
ote">> ... we do know. It's right there in the Motivation section.</=
div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Nope. T=
he motivation section has no verbiage like=C2=A0<i style=3D"font-size:12.8p=
x">from the function itself.</i><span style=3D"font-size:12.8px">=C2=A0The =
sample that it has can be interpreted either way (and it is silly either wa=
y). You may have experience=C2=A0with something named "statement=C2=A0=
expressions" in some other language=C2=A0or on some particular impleme=
ntation, so what they want to say may be (you think) clear to you. It is no=
t to me. To me that looks like a very low quality proposal, whose readers n=
eed to guess what is being proposed.</span></div><div class=3D"gmail_quote"=
><span style=3D"font-size:12.8px"><br></span></div><div class=3D"gmail_quot=
e"><span style=3D"font-size:12.8px">Cheers,</span></div><div class=3D"gmail=
_quote"><span style=3D"font-size:12.8px">V.</span></div></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/CAA7YVg2YE9mUc3LmmT3FZO0VKENTBjRoVqsF=
B3VjJwbjM5TgzQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2YE9mUc3Lm=
mT3FZO0VKENTBjRoVqsFB3VjJwbjM5TgzQ%40mail.gmail.com</a>.<br />
--f403045ea0a8fda9030547f28aba--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 7 Feb 2017 10:48:04 -0500
Raw View
On 2017-02-06 21:39, gmisocpp@gmail.com wrote:
> I very much would prefer at a minimum, this:
>
> int product = ({
> int j = 1;
> for (auto i : v)
> j *= i;
> produce j;
> });
Bikeshed: `produce` or `yield`? Or, if abbreviated lambdas is accepted,
unary prefix `=>`?
I'd really like to converge to only *one* new keyword that can be used
in multiple contexts. Besides this and P0057, think generator functions,
also.
Moreover, if we do something like this, can you write:
auto x = ({
if (expr)
produce y; // SE execution ends here if we get here
// additional logic
produce z;
});
....?
--
Matthew
--
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/5899EC34.8080301%40gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 7 Feb 2017 07:49:37 -0800 (PST)
Raw View
------=_Part_1798_666276205.1486482577626
Content-Type: multipart/alternative;
boundary="----=_Part_1799_1023482673.1486482577626"
------=_Part_1799_1023482673.1486482577626
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 7, 2017 at 10:38:46 AM UTC-5, Viacheslav Usov wrote:
>
> On Tue, Feb 7, 2017 at 4:29 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
> > ... we do know. It's right there in the Motivation section.
>
> Nope. The motivation section has no verbiage like *from the function
> itself.* The sample that it has can be interpreted either way (and it is
> silly either way).
>
How exactly is it "silly either way"? If `return tmp` returns the value
from the function, then it's clear what's happening. It will initialize the
variable or return from the function.
It may be unnecessary for that particular case, but it is hardly silly.
> You may have experience with something named "statement expressions" in
> some other language or on some particular implementation, so what they want
> to say may be (you think) clear to you. It is not to me. To me that looks
> like a very low quality proposal, whose readers need to guess what is being
> proposed.
>
I agree that the proposal should actually explain what a statement
expression is, conceptually.
I would also suggest that motivations *besides* "wrap it in a macro" be
specified. The current motivation and examples all suggest that this
feature exists *solely* for the benefit of macro programming.
And that's not something we should invent language features for.
--
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/bd3d5d9b-c118-40b3-b63d-e0c2d13f4a5c%40isocpp.org.
------=_Part_1799_1023482673.1486482577626
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 7, 2017 at 10:38:46 AM UTC-5, Viaches=
lav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><div class=3D"gmail_quote">On Tue, Feb 7, 2017 at 4:29 PM, Nicol Bol=
as <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"PFjuFNGvAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">jmck...@gmail.com</a>></span> wrote:</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">> ... we do know. =
It's right there in the Motivation section.</div><div class=3D"gmail_qu=
ote"><br></div><div class=3D"gmail_quote">Nope. The motivation section has =
no verbiage like=C2=A0<i style=3D"font-size:12.8px">from the function itsel=
f.</i><span style=3D"font-size:12.8px">=C2=A0The sample that it has can be =
interpreted either way (and it is silly either way).</span></div></div></di=
v></blockquote><div><br>How exactly is it "silly either way"? If =
`return tmp` returns the value from the function, then it's clear what&=
#39;s happening. It will initialize the variable or return from the functio=
n.<br><br>It may be unnecessary for that particular case, but it is hardly =
silly.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><span style=3D"font-size:12.8px">Y=
ou may have experience=C2=A0with something named "statement=C2=A0expre=
ssions" in some other language=C2=A0or on some particular implementati=
on, so what they want to say may be (you think) clear to you. It is not to =
me. To me that looks like a very low quality proposal, whose readers need t=
o guess what is being proposed.</span></div></div></div></blockquote><div><=
br>I agree that the proposal should actually explain what a statement expre=
ssion is, conceptually.<br><br>I would also suggest that motivations <i>bes=
ides</i> "wrap it in a macro" be specified. The current motivatio=
n and examples all suggest that this feature exists <i>solely</i> for the b=
enefit of macro programming.<br><br>And that's not something we should =
invent language features for.<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/bd3d5d9b-c118-40b3-b63d-e0c2d13f4a5c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bd3d5d9b-c118-40b3-b63d-e0c2d13f4a5c=
%40isocpp.org</a>.<br />
------=_Part_1799_1023482673.1486482577626--
------=_Part_1798_666276205.1486482577626--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 7 Feb 2017 10:57:47 -0500
Raw View
On 2017-02-06 22:01, David Krauss wrote:
> There was a recent discussion on this list, =E2=80=9Ccapturing monads in
> lambda,=E2=80=9D about continuation capture in lambda expressions, i.e.
> [return]{ return 23; }.
>=20
> That proposal suggested that the continuation could be passed into,
> for instance, functions from <algorithm> and it would implement dynamic
> unwinding like throw. You seem to be not proposing that, but it=E2=80=99s
> unclear what mechanism prohibits it from happening. What happens when a
> reference or pointer is taken to a named statement expression?
One possible answer is that they are closer to macros/templates (i.e.
the compiler knows their definition and substitutes them inline at point
of use), and you cannot take their address.
This part of the proposal might warrant moving to a "Future Directions"
section.
--=20
Matthew
--=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/5899EE7B.90800%40gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 7 Feb 2017 18:52:04 +0200
Raw View
On 7 February 2017 at 17:05, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Tuesday, February 7, 2017 at 9:52:36 AM UTC-5, Ville Voutilainen wrote:
>>
>> On 7 February 2017 at 16:50, Nicol Bolas <jmck...@gmail.com> wrote:
>> >> More generally I wonder if extending inline functions with something
>> >> might
>> >> be a nicer route:
>> >
>> >
>> > The point of a statement expression is that it's part of the current
>> > function. It's not doing a separate call; it's just a block of code that
>> > produces a value. That way, you can still do things like access local
>> > variables and parameters, use `break` and `return` as if you were in the
>> > function (which you are) etc.
>>
>> Here's a question: how do I get from this proposal to a
>> statement-expression template?
>> I want to write generic code blocks that I can glue into other places,
>> passing template
>> arguments that guide how the code is instantiated.
>
>
> You write a macro.
Ah, good to know you're so opposed to this proposal that you want to
kill it right away, before it goes any further.
--
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/CAFk2RUan3Bo%3DqRzCNzqw5R2ufPAXRhynadOWzMc90YoF_GGi%3DQ%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 7 Feb 2017 10:44:05 -0800 (PST)
Raw View
------=_Part_2150_1519664590.1486493046024
Content-Type: multipart/alternative;
boundary="----=_Part_2151_1586986968.1486493046024"
------=_Part_2151_1586986968.1486493046024
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 7, 2017 at 10:48:07 AM UTC-5, Matthew Woehlke wrote:
>
> On 2017-02-06 21:39, gmis...@gmail.com <javascript:> wrote:
> > I very much would prefer at a minimum, this:
> >
> > int product = ({
> > int j = 1;
> > for (auto i : v)
> > j *= i;
> > produce j;
> > });
>
> Bikeshed: `produce` or `yield`? Or, if abbreviated lambdas is accepted,
> unary prefix `=>`?
>
> I'd really like to converge to only *one* new keyword that can be used
> in multiple contexts. Besides this and P0057, think generator functions,
> also.
>
None of the P0057 ones would be appropriate. `co_yield` and `co_return`
should be things that you can do *within* statement expressions, which
cause the function as a whole to co_yield or co_return. You ought to be
able to use them in statement expressions of coroutines.
That's why it needs to be a new keyword.
> Moreover, if we do something like this, can you write:
>
> auto x = ({
> if (expr)
> produce y; // SE execution ends here if we get here
> // additional logic
> produce z;
> });
>
> ...?
>
It would resolve exactly like return type deduction: if the statement
expression's `in_return` or whatever do not all deduce to the same type,
you get UB.
Though the exact form of the deduction (`auto` vs `decltype(auto)`)
probably should be ironed out.
--
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/610aa674-c702-4a72-aa1e-18a9768936fd%40isocpp.org.
------=_Part_2151_1586986968.1486493046024
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 7, 2017 at 10:48:07 AM UTC-5, Matthew=
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-02-06 2=
1:39, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"LJ=
5y31OwAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:=
9;;return true;" onclick=3D"this.href=3D'javascript:';return true;"=
>gmis...@gmail.com</a> wrote:
<br>> I very much would prefer at a minimum, this:
<br>>=20
<br>> int product =3D ({
<br>> =C2=A0 =C2=A0 int j =3D 1;
<br>> =C2=A0 =C2=A0 for (auto i : v)
<br>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 j *=3D i;
<br>> =C2=A0 =C2=A0 produce j;
<br>> });
<br>
<br>Bikeshed: `produce` or `yield`? Or, if abbreviated lambdas is accepted,
<br>unary prefix `=3D>`?
<br>
<br>I'd really like to converge to only *one* new keyword that can be u=
sed
<br>in multiple contexts. Besides this and P0057, think generator functions=
,
<br>also.<br></blockquote><div><br>None of the P0057 ones would be appropri=
ate. `co_yield` and `co_return` should be things that you can do <i>within<=
/i> statement expressions, which cause the function as a whole to co_yield =
or co_return. You ought to be able to use them in statement expressions of =
coroutines.<br><br>That's why it needs to be a new keyword.<br>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">
Moreover, if we do something like this, can you write:
<br>
<br>=C2=A0 auto x =3D ({
<br>=C2=A0 =C2=A0 if (expr)
<br>=C2=A0 =C2=A0 =C2=A0 produce y; // SE execution ends here if we get her=
e
<br>=C2=A0 =C2=A0 // additional logic
<br>=C2=A0 =C2=A0 produce z;
<br>=C2=A0 });
<br>
<br>...?
<br></blockquote><div><br>It would resolve exactly like return type deducti=
on: if the statement expression's `in_return` or whatever do not all de=
duce to the same type, you get UB.<br><br>Though the exact form of the dedu=
ction (`auto` vs `decltype(auto)`) probably should be ironed out. <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/610aa674-c702-4a72-aa1e-18a9768936fd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/610aa674-c702-4a72-aa1e-18a9768936fd=
%40isocpp.org</a>.<br />
------=_Part_2151_1586986968.1486493046024--
------=_Part_2150_1519664590.1486493046024--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 7 Feb 2017 10:46:54 -0800 (PST)
Raw View
------=_Part_2034_1982052257.1486493214787
Content-Type: multipart/alternative;
boundary="----=_Part_2035_1242010700.1486493214787"
------=_Part_2035_1242010700.1486493214787
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 7, 2017 at 11:52:06 AM UTC-5, Ville Voutilainen wrote:
>
> On 7 February 2017 at 17:05, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> >
> >
> > On Tuesday, February 7, 2017 at 9:52:36 AM UTC-5, Ville Voutilainen
> wrote:
> >>
> >> On 7 February 2017 at 16:50, Nicol Bolas <jmck...@gmail.com> wrote:
> >> >> More generally I wonder if extending inline functions with something
> >> >> might
> >> >> be a nicer route:
> >> >
> >> >
> >> > The point of a statement expression is that it's part of the current
> >> > function. It's not doing a separate call; it's just a block of code
> that
> >> > produces a value. That way, you can still do things like access local
> >> > variables and parameters, use `break` and `return` as if you were in
> the
> >> > function (which you are) etc.
> >>
> >> Here's a question: how do I get from this proposal to a
> >> statement-expression template?
> >> I want to write generic code blocks that I can glue into other places,
> >> passing template
> >> arguments that guide how the code is instantiated.
> >
> >
> > You write a macro.
>
> Ah, good to know you're so opposed to this proposal that you want to
> kill it right away, before it goes any further.
>
I don't want C++ to have named/parameterized statement expressions at all, *let
alone* templates of them. I see utility for statement expressions as a
concept beyond "way to stick stuff into macros that don't interfere with
other code", and I don't think the feature should be presented as a way to
that end.
--
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/a26f80b4-9702-4a3a-8cf7-5f3b8302168b%40isocpp.org.
------=_Part_2035_1242010700.1486493214787
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 7, 2017 at 11:52:06 AM UTC-5, Ville V=
outilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 7 February=
2017 at 17:05, Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"UT85uNGzAgAJ" rel=3D"nofollow" onmousedown=3D"this.=
href=3D'javascript:';return true;" onclick=3D"this.href=3D'java=
script:';return true;">jmck...@gmail.com</a>> wrote:
<br>>
<br>>
<br>> On Tuesday, February 7, 2017 at 9:52:36 AM UTC-5, Ville Voutilaine=
n wrote:
<br>>>
<br>>> On 7 February 2017 at 16:50, Nicol Bolas <<a>jmck...@gmail.=
com</a>> wrote:
<br>>> >> More generally I wonder if extending inline functions=
with something
<br>>> >> might
<br>>> >> be a nicer route:
<br>>> >
<br>>> >
<br>>> > The point of a statement expression is that it's part=
of the current
<br>>> > function. It's not doing a separate call; it's ju=
st a block of code that
<br>>> > produces a value. That way, you can still do things like =
access local
<br>>> > variables and parameters, use `break` and `return` as if =
you were in the
<br>>> > function (which you are) etc.
<br>>>
<br>>> Here's a question: how do I get from this proposal to a
<br>>> statement-expression template?
<br>>> I want to write generic code blocks that I can glue into other=
places,
<br>>> passing template
<br>>> arguments that guide how the code is instantiated.
<br>>
<br>>
<br>> You write a macro.
<br>
<br>Ah, good to know you're so opposed to this proposal that you want t=
o
<br>kill it right away, before it goes any further.
<br></blockquote><div><br>I don't want C++ to have named/parameterized =
statement expressions at all, <i>let alone</i> templates of them. I see uti=
lity for statement expressions as a concept beyond "way to stick stuff=
into macros that don't interfere with other code", and I don'=
t think the feature should be presented as a way to that end.<br></div></di=
v>
<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/a26f80b4-9702-4a3a-8cf7-5f3b8302168b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a26f80b4-9702-4a3a-8cf7-5f3b8302168b=
%40isocpp.org</a>.<br />
------=_Part_2035_1242010700.1486493214787--
------=_Part_2034_1982052257.1486493214787--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Tue, 7 Feb 2017 14:30:36 -0500
Raw View
On 2017-02-07 13:44, Nicol Bolas wrote:
> On Tuesday, February 7, 2017 at 10:48:07 AM UTC-5, Matthew Woehlke wrote:
>> On 2017-02-06 21:39, gmis...@gmail.com <javascript:> wrote:
>>> I very much would prefer at a minimum, this:
>>>
>>> int product = ({
>>> int j = 1;
>>> for (auto i : v)
>>> j *= i;
>>> produce j;
>>> });
>>
>> Bikeshed: `produce` or `yield`? Or, if abbreviated lambdas is accepted,
>> unary prefix `=>`?
>>
>> I'd really like to converge to only *one* new keyword that can be used
>> in multiple contexts. Besides this and P0057, think generator functions,
>> also.
>
> None of the P0057 ones would be appropriate. `co_yield` and `co_return`
> should be things that you can do *within* statement expressions, which
> cause the function as a whole to co_yield or co_return. You ought to be
> able to use them in statement expressions of coroutines.
>
> That's why it needs to be a new keyword.
Arf. You're right, and the same goes for generators or whatever; the SE
should be able to use those control keywords and have them mean what
they mean outside the SE. So, yeah, you need a SE-specific keyword. (In
which case, if abbreviated lambdas are accepted, I'm going to vote for
`=>` :-).)
>> Moreover, if we do something like this, can you write:
>>
>> auto x = ({
>> if (expr)
>> produce y; // SE execution ends here if we get here
>> // additional logic
>> produce z;
>> });
>>
>> ...?
>
> It would resolve exactly like return type deduction: if the statement
> expression's `in_return` or whatever do not all deduce to the same type,
> you get UB.
Uh... UB? Really? I would think ill-formed, which is how return type
deduction works...
Actually, I hadn't even thought about that, though the answer ("like
return type deduction") is obvious. I find it more odd that you can
cause the SE to early-exit *at all* (besides something that tosses flow
even further, like `break` or `return`). I guess you're okay with that,
given you're thinking past it.
--
Matthew
--
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/589A205C.9030405%40gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 7 Feb 2017 12:01:26 -0800 (PST)
Raw View
------=_Part_2201_1427754749.1486497686424
Content-Type: multipart/alternative;
boundary="----=_Part_2202_604609606.1486497686425"
------=_Part_2202_604609606.1486497686425
Content-Type: text/plain; charset=UTF-8
On Tuesday, February 7, 2017 at 2:30:39 PM UTC-5, Matthew Woehlke wrote:
>
> On 2017-02-07 13:44, Nicol Bolas wrote:
> > On Tuesday, February 7, 2017 at 10:48:07 AM UTC-5, Matthew Woehlke
> wrote:
> >> On 2017-02-06 21:39, gmis...@gmail.com <javascript:> wrote:
> >>> I very much would prefer at a minimum, this:
> >>>
> >>> int product = ({
> >>> int j = 1;
> >>> for (auto i : v)
> >>> j *= i;
> >>> produce j;
> >>> });
> >>
> >> Bikeshed: `produce` or `yield`? Or, if abbreviated lambdas is accepted,
> >> unary prefix `=>`?
> >>
> >> I'd really like to converge to only *one* new keyword that can be used
> >> in multiple contexts. Besides this and P0057, think generator
> functions,
> >> also.
> >
> > None of the P0057 ones would be appropriate. `co_yield` and `co_return`
> > should be things that you can do *within* statement expressions, which
> > cause the function as a whole to co_yield or co_return. You ought to be
> > able to use them in statement expressions of coroutines.
> >
> > That's why it needs to be a new keyword.
>
> Arf. You're right, and the same goes for generators or whatever; the SE
> should be able to use those control keywords and have them mean what
> they mean outside the SE. So, yeah, you need a SE-specific keyword. (In
> which case, if abbreviated lambdas are accepted, I'm going to vote for
> `=>` :-).)
>
That would be confusing. After all, `=>` doesn't mean `return`; it means a
lot more than just to return something. It also specifically overrides the
default return type deduction on lambdas (using `decltype(auto)` instead of
`auto`). And it includes `noexcept` stuff.
More to the point, `=>` is for defining a *function*, and SEs explicitly
are not functions. Using `=>` to mean "SE resolves to X" would be very odd
indeed.
>> Moreover, if we do something like this, can you write:
> >>
> >> auto x = ({
> >> if (expr)
> >> produce y; // SE execution ends here if we get here
> >> // additional logic
> >> produce z;
> >> });
> >>
> >> ...?
> >
> > It would resolve exactly like return type deduction: if the statement
> > expression's `in_return` or whatever do not all deduce to the same type,
> > you get UB.
>
> Uh... UB? Really? I would think ill-formed, which is how return type
> deduction works...
>
Sorry, brain fart. Yes, ill-formed.
> Actually, I hadn't even thought about that, though the answer ("like
> return type deduction") is obvious. I find it more odd that you can
> cause the SE to early-exit *at all* (besides something that tosses flow
> even further, like `break` or `return`). I guess you're okay with that,
> given you're thinking past it.
>
The way I see it, once you want to be able to have statements inside of
expressions, you shouldn't add restrictions to what kind of statements you
want in there unless it's absolutely necessary. So having the expression
evaluate to a value at an arbitrary location is perfectly understandable.
The main thing I want to make sure we *don't do* is turn these into
"functors that are magically connected to the location of their creation".
They should be evaluated in exactly and only one place: the place where
they are defined.
--
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/3130bbbb-7e3e-413d-8044-7b254d266bcb%40isocpp.org.
------=_Part_2202_604609606.1486497686425
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, February 7, 2017 at 2:30:39 PM UTC-5, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-02-07 13=
:44, Nicol Bolas wrote:
<br>> On Tuesday, February 7, 2017 at 10:48:07 AM UTC-5, Matthew Woehlke=
wrote:
<br>>> On 2017-02-06 21:39, <a>gmis...@gmail.com</a> <javascript:&=
gt; wrote:=20
<br>>>> I very much would prefer at a minimum, this:=20
<br>>>>
<br>>>> int product =3D ({=20
<br>>>> =C2=A0 =C2=A0 int j =3D 1;=20
<br>>>> =C2=A0 =C2=A0 for (auto i : v)=20
<br>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 j *=3D i;=20
<br>>>> =C2=A0 =C2=A0 produce j;=20
<br>>>> });=20
<br>>>
<br>>> Bikeshed: `produce` or `yield`? Or, if abbreviated lambdas is =
accepted,=20
<br>>> unary prefix `=3D>`?=20
<br>>>
<br>>> I'd really like to converge to only *one* new keyword that=
can be used=20
<br>>> in multiple contexts. Besides this and P0057, think generator =
functions,=20
<br>>> also.
<br>>=20
<br>> None of the P0057 ones would be appropriate. `co_yield` and `co_re=
turn`=20
<br>> should be things that you can do *within* statement expressions, w=
hich=20
<br>> cause the function as a whole to co_yield or co_return. You ought =
to be=20
<br>> able to use them in statement expressions of coroutines.
<br>>=20
<br>> That's why it needs to be a new keyword.
<br>
<br>Arf. You're right, and the same goes for generators or whatever; th=
e SE
<br>should be able to use those control keywords and have them mean what
<br>they mean outside the SE. So, yeah, you need a SE-specific keyword. (In
<br>which case, if abbreviated lambdas are accepted, I'm going to vote =
for
<br>`=3D>` :-).)<br></blockquote><div><br>That would be confusing. After=
all, `=3D>` doesn't mean `return`; it means a lot more than just to=
return something. It also specifically overrides the default return type d=
eduction on lambdas (using `decltype(auto)` instead of `auto`). And it incl=
udes `noexcept` stuff.<br><br>More to the point, `=3D>` is for defining =
a <i>function</i>, and SEs explicitly are not functions. Using `=3D>` to=
mean "SE resolves to X" would be very odd indeed.<br><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">
>> Moreover, if we do something like this, can you write:=20
<br>>>
<br>>> =C2=A0 auto x =3D ({=20
<br>>> =C2=A0 =C2=A0 if (expr)=20
<br>>> =C2=A0 =C2=A0 =C2=A0 produce y; // SE execution ends here if w=
e get here=20
<br>>> =C2=A0 =C2=A0 // additional logic=20
<br>>> =C2=A0 =C2=A0 produce z;=20
<br>>> =C2=A0 });=20
<br>>>
<br>>> ...?=20
<br>>=20
<br>> It would resolve exactly like return type deduction: if the statem=
ent=20
<br>> expression's `in_return` or whatever do not all deduce to the =
same type,=20
<br>> you get UB.
<br>
<br>Uh... UB? Really? I would think ill-formed, which is how return type
<br>deduction works...<br></blockquote><div><br>Sorry, brain fart. Yes, ill=
-formed.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
Actually, I hadn't even thought about that, though the answer ("li=
ke
<br>return type deduction") is obvious. I find it more odd that you ca=
n
<br>cause the SE to early-exit *at all* (besides something that tosses flow
<br>even further, like `break` or `return`). I guess you're okay with t=
hat,
<br>given you're thinking past it.<br></blockquote><div><br></div>The w=
ay I see it, once you want to be able to have statements inside of expressi=
ons, you shouldn't add restrictions to what kind of statements you want=
in there unless it's absolutely necessary. So having the expression ev=
aluate to a value at an arbitrary location is perfectly understandable.<br>=
<br>The main thing I want to make sure we <i>don't do</i> is turn these=
into "functors that are magically connected to the location of their =
creation". They should be evaluated in exactly and only one place: the=
place where they are defined.<br></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/3130bbbb-7e3e-413d-8044-7b254d266bcb%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3130bbbb-7e3e-413d-8044-7b254d266bcb=
%40isocpp.org</a>.<br />
------=_Part_2202_604609606.1486497686425--
------=_Part_2201_1427754749.1486497686424--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 7 Feb 2017 22:20:04 +0100
Raw View
Le 07/02/2017 =C3=A0 15:52, Ville Voutilainen a =C3=A9crit :
> On 7 February 2017 at 16:50, Nicol Bolas <jmckesson@gmail.com> wrote:
>>> More generally I wonder if extending inline functions with something mi=
ght
>>> be a nicer route:
>>
>> The point of a statement expression is that it's part of the current
>> function. It's not doing a separate call; it's just a block of code that
>> produces a value. That way, you can still do things like access local
>> variables and parameters, use `break` and `return` as if you were in the
>> function (which you are) etc.
>
> Here's a question: how do I get from this proposal to a
> statement-expression template?
> I want to write generic code blocks that I can glue into other places,
> passing template
> arguments that guide how the code is instantiated.
>
Wouldn't the section "Support for named parametric SE" respond to this need=
?
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/d09d325e-edca-afe1-b123-d549e7463709%40wanadoo.f=
r.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 07 Feb 2017 15:11:21 -0800
Raw View
On ter=C3=A7a-feira, 7 de fevereiro de 2017 22:20:41 PST TONGARI J wrote:
> The control flow. You can use 'return', 'break', etc inside the block tha=
t
> can get you to the outer block, which is what lambda expression can't do.
while ({(break; true;)})
continue;
Is that break in scope of the while?
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/9360242.LnOStbd6Wn%40tjmaciei-mobl1.
.
Author: TONGARI J <tongari95@gmail.com>
Date: Wed, 8 Feb 2017 09:45:23 +0800
Raw View
--001a114f5d7ca07fe70547fb0490
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
2017-02-08 7:11 GMT+08:00 Thiago Macieira <thiago@macieira.org>:
> On ter=C3=A7a-feira, 7 de fevereiro de 2017 22:20:41 PST TONGARI J wrote:
> > The control flow. You can use 'return', 'break', etc inside the block
> that
> > can get you to the outer block, which is what lambda expression can't d=
o.
>
> while ({(break; true;)})
> continue;
>
> Is that break in scope of the while?
>
Note that you get the syntax the other way round, it's ({}) not {()}.
It's an interesting question, seems GCC and Clang disagree here.
My gut feeling is that the 'break' should apply to some outer level other
than the while-stmt, as what GCC does.
--=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/CANCwVhf3fd_pXJMkjWViwJZxO1cwQAx0MRZGPzToZHia_1G=
CCw%40mail.gmail.com.
--001a114f5d7ca07fe70547fb0490
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-02-08 7:11 GMT+08:00 Thiago Macieira <span dir=3D"ltr"><<a href=3D"mail=
to:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>></span=
>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left:1px solid rgb(204,204,204);padding-left:1ex"><span class=3D"gmai=
l-">On ter=C3=A7a-feira, 7 de fevereiro de 2017 22:20:41 PST TONGARI J wrot=
e:<br>
> The control flow. You can use 'return', 'break', etc i=
nside the block that<br>
> can get you to the outer block, which is what lambda expression can=
9;t do.<br>
<br>
</span>while ({(break; true;)})<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 continue;<br>
<br>
Is that break in scope of the while?<br></blockquote><div><br></div><div>No=
te that you get the syntax the other way round, it's ({}) not {()}.</di=
v>It's an interesting question, seems GCC and Clang disagree here.<br>M=
y gut feeling is that the 'break' should apply to some outer level =
other than the while-stmt, as what GCC does.</div></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/CANCwVhf3fd_pXJMkjWViwJZxO1cwQAx0MRZG=
PzToZHia_1GCCw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANCwVhf3fd_pXJMk=
jWViwJZxO1cwQAx0MRZGPzToZHia_1GCCw%40mail.gmail.com</a>.<br />
--001a114f5d7ca07fe70547fb0490--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 07 Feb 2017 20:33:42 -0800
Raw View
On quarta-feira, 8 de fevereiro de 2017 09:45:23 PST TONGARI J wrote:
> Note that you get the syntax the other way round, it's ({}) not {()}.
Sorry, just trying to write from memory.
> It's an interesting question, seems GCC and Clang disagree here.
> My gut feeling is that the 'break' should apply to some outer level other
> than the while-stmt, as what GCC does.
Another question (just for food for thought): would statement expressions be
allowed in constexpr contexts?
struct S
{
int i;
constexpr S() : i(({ something_constexpr(); 1; })) {}
}
My gut feeling is that so long it is still constexpr, it should be allowed.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/2142762.QbIpQDiU5q%40tjmaciei-mobl1.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 8 Feb 2017 16:30:33 -0800
Raw View
--001a114b317c1529f705480e1816
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 7 February 2017 at 17:45, TONGARI J <tongari95@gmail.com> wrote:
> 2017-02-08 7:11 GMT+08:00 Thiago Macieira <thiago@macieira.org>:
>
>> On ter=C3=A7a-feira, 7 de fevereiro de 2017 22:20:41 PST TONGARI J wrote=
:
>> > The control flow. You can use 'return', 'break', etc inside the block
>> that
>> > can get you to the outer block, which is what lambda expression can't
>> do.
>>
>> while ({(break; true;)})
>> continue;
>>
>> Is that break in scope of the while?
>>
>
> Note that you get the syntax the other way round, it's ({}) not {()}.
> It's an interesting question, seems GCC and Clang disagree here.
> My gut feeling is that the 'break' should apply to some outer level other
> than the while-stmt, as what GCC does.
>
Actually, that's not what GCC does. Its diagnostics and code generation are
out of sync: it requires a surrounding loop construct but the break
statement actually breaks out of the inner while statement.
--=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/CAOfiQq%3DfwkqBOFb5eEnqQEZsXO3K8ogWUNo0hJKHcCEow=
aKkpA%40mail.gmail.com.
--001a114b317c1529f705480e1816
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 7=
February 2017 at 17:45, TONGARI J <span dir=3D"ltr"><<a href=3D"mailto:=
tongari95@gmail.com" target=3D"_blank">tongari95@gmail.com</a>></span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><span class=3D"">2017-02-08 7:11 GMT+08=
:00 Thiago Macieira <span dir=3D"ltr"><<a href=3D"mailto:thiago@macieira=
..org" target=3D"_blank">thiago@macieira.org</a>></span>:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><span class=3D"m_-6264644462919093677=
gmail-">On ter=C3=A7a-feira, 7 de fevereiro de 2017 22:20:41 PST TONGARI J =
wrote:<br>
> The control flow. You can use 'return', 'break', etc i=
nside the block that<br>
> can get you to the outer block, which is what lambda expression can=
9;t do.<br>
<br>
</span>while ({(break; true;)})<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 continue;<br>
<br>
Is that break in scope of the while?<br></blockquote><div><br></div></span>=
<div>Note that you get the syntax the other way round, it's ({}) not {(=
)}.</div>It's an interesting question, seems GCC and Clang disagree her=
e.<br>My gut feeling is that the 'break' should apply to some outer=
level other than the while-stmt, as what GCC does.</div></div></div></bloc=
kquote><div><br></div><div>Actually, that's not what GCC does. Its diag=
nostics and code generation are out of sync: it requires a surrounding loop=
construct but the break statement actually breaks out of the inner while s=
tatement.</div></div></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/CAOfiQq%3DfwkqBOFb5eEnqQEZsXO3K8ogWUN=
o0hJKHcCEowaKkpA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DfwkqB=
OFb5eEnqQEZsXO3K8ogWUNo0hJKHcCEowaKkpA%40mail.gmail.com</a>.<br />
--001a114b317c1529f705480e1816--
.
Author: szollosi.lorand@gmail.com
Date: Wed, 8 Feb 2017 17:11:45 -0800 (PST)
Raw View
------=_Part_17_894778651.1486602705807
Content-Type: multipart/alternative;
boundary="----=_Part_18_225077464.1486602705808"
------=_Part_18_225077464.1486602705808
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi,
Thanks for all the valuable responses. I'll try to answer the open items=20
and those where I can add.
*gmis> produce j;Nicol Bolas> =3D>*I'm okay with either version. Note that=
=20
there are two distinct changes here:
- Having a keyword/macro before the last expression. `=3D>' would be=20
intuitive if simple lambda expressions are accepted. `produce' means it =
can=20
be defined as empty in current compilers to make them conforming.
- Allowing multiple `=3D>'/`produce' points. This is useful (and should =
be=20
included), but note that this means we're trading the return-from-caller=
=20
problem to produce-from caller problem.
*David Krauss> =E2=80=9Ccapturing monads in lambda,=E2=80=9D about continua=
tion capture in=20
lambda expressions, i.e. [return]{ return 23; }Ville Voutilainen> I want to=
=20
write generic code blocks that I can glue into other places, passing=20
template arguments that guide how the code is instantiated. *
Yep, that's from me as well. I'm working on it, with many open items as=20
complexity is blowing up exponentially. Currently I think capture-return=20
should be a part of the template argument list, without being an actual=20
template argument; it should rather be auto-captured there. Once that's=20
ready for proposal, this can be thought of as a simplified case. In case=20
you're interested, these three should be equal:
template<return>
int fn() { return 23; }
// note that neither of the functions have a direct return statement
int test_fn() { fn(); }
int test_se() { ({ return 23; }); }
int test_l() { []<return>(){ return 23; }(); }
*Tony V E> before and after tables*
Wish I could! Currently I cannot produce the same functionality without=20
major redesign of the caller (or modification to the caller and abusing=20
exceptions badly). Or do you mean to include caller as well?
*Viacheslav Usov> I do not see that explained in the proposal at all.*Good=
=20
point. Added a short one on this in the introduction.
*Barry Revzin> copy-elision*I've added it as an optional (hopefully=20
implemented feature).
.... to be continued in next mail ...
Thanks, -lorro
--=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/8c51347c-cfc2-4c94-8998-c381c1f27e20%40isocpp.or=
g.
------=_Part_18_225077464.1486602705808
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>Thanks for all the valuable responses. I'll=
try to answer the open items and those where I can add.<br><br><i><b>gmis&=
gt; produce j;<br>Nicol Bolas> =3D><br></b></i>I'm okay with eith=
er version. Note that there are two distinct changes here:<br><ul><li>Havin=
g a keyword/macro before the last expression. `=3D>' would be intuit=
ive if simple lambda expressions are accepted. `produce' means it can b=
e defined as empty in current compilers to make them conforming.</li><li>Al=
lowing multiple `=3D>'/`produce' points. This is useful (and sho=
uld be included), but note that this means we're trading the return-fro=
m-caller problem to produce-from caller problem.</li></ul><i><b>David Kraus=
s> =E2=80=9C<font face=3D"Helvetica Neue">capturing monads in lambda,=E2=
=80=9D</font>=C2=A0about continuation capture in lambda expressions, i.e. <=
font face=3D"Courier">[return]{ return 23; }<br></font></b><b>Ville Voutila=
inen> I want to write generic code blocks that I can glue into other pla=
ces,
<br>passing template
arguments that guide how the code is instantiated.
</b></i><br>Yep, that's from me as well. I'm working on it, with ma=
ny open items as complexity is blowing up exponentially. Currently I think =
capture-return should be a part of the template argument list, without bein=
g an actual template argument; it should rather be auto-captured there. Onc=
e that's ready for proposal, this can be thought of as a simplified cas=
e. In case you're interested, these three should be equal:<br><br><div =
style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, =
187); border-style: solid; border-width: 1px; overflow-wrap: break-word;" c=
lass=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: #008;" class=3D"styled-by-prettify">template</spa=
n><span style=3D"color: #080;" class=3D"styled-by-prettify"><return><=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> fn</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">return</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">23</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n 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"styled-by-prettify"><br></span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">// note that neither of the functions have a dire=
ct return statement</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> tes=
t_fn</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</sp=
an><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"styled-by-prettify"> fn</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">();</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"styled-by=
-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t=
est_se</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><code class=3D"prett=
yprint"><span style=3D"color: #660;" class=3D"styled-by-prettify">({</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=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=
: #066;" class=3D"styled-by-prettify">23</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">});</span></code><span style=3D"color: #660;" class=3D"styled-b=
y-prettify"></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"styled-by-prettify"><br></span><code=
class=3D"prettyprint"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
test_l</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0 </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">[]<</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">>(){</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </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: #066;" class=3D"styled-by=
-prettify">23</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">}();</span><spa=
n 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"styled-by-prettify"><br></span><span style=3D"color: #800=
;" class=3D"styled-by-prettify"></span></code></div></code></div><br><b>Ton=
y V E> before and after tables</b><br>Wish I could! Currently I cannot p=
roduce the same functionality without major redesign of the caller (or modi=
fication to the caller and abusing exceptions badly). Or do you mean to inc=
lude caller as well?<br><br><i><b><span class=3D"_username"><span class=3D"=
IVILX2C-D-a" style=3D"color: rgb(34, 34, 34);">Viacheslav Usov> </span><=
/span>I do not see that explained in the proposal at all.<br></b></i>Good p=
oint. Added a short one on this in the introduction.<br><br><b><i>Barry Rev=
zin> copy-elision</i><br></b>I've added it as an optional (hopefully=
implemented feature).<br><br>... to be continued in next mail ...<br><br>T=
hanks, -lorro<br></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/8c51347c-cfc2-4c94-8998-c381c1f27e20%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8c51347c-cfc2-4c94-8998-c381c1f27e20=
%40isocpp.org</a>.<br />
------=_Part_18_225077464.1486602705808--
------=_Part_17_894778651.1486602705807--
.
Author: szollosi.lorand@gmail.com
Date: Wed, 8 Feb 2017 18:04:04 -0800 (PST)
Raw View
------=_Part_45_484713333.1486605844542
Content-Type: multipart/alternative;
boundary="----=_Part_46_1172750703.1486605844542"
------=_Part_46_1172750703.1486605844542
Content-Type: text/plain; charset=UTF-8
.... continued from previous mail ...
*Nicol Bolas> But you shouldn't let that restrict the proposal unduly. Not
unless you have specific knowledge that such implementations would be a
hardship.*I'd be the best if all the features were accepted by the
committee; however, I do not want to keep it from being standardized if
some points are inconclusive/rejected. Therefore I suggested a 'tristate
ticklist' where each feature can be accepted, rejected (in which 2 cases
feature disc. macros are unnecessary) or optionally accepted (in which case
a feat. disc. macro is suggested). Optional, as in other parts of the
standard means: you, as a compiler writer 'don't have to do this, but if
you do, do it this way'.
Note that I'm new and not aware of the voting process. If such a proposal
cannot be made, let me know and I come up with something else.
As for hardships, I've checked some manuals. Intel especially claims that
destructors and some other features are not allowed due to the difficulty
of them (think of it this way: *when* should an object created in SE be
destructed? If at produce, we can't have RAII; if at the end of the
statement, we need to specifically state that SE body is function-like in
the sense that "temporaries don't last till the end of the statement").
*Nicol Bolas> Now, parameters and "named statements", I don't think those
should even be part of the proposal. **I don't want C++ to have
named/parameterized statement expressions at all, let alone templates of
them. *
I understand you don't want these. I'd like you to understand that many,
including myself, do. Thus it - sooner or later - gets implemented (read:
I'm already looking into how to do it on Itanium ABI); and if it's not
standardized, it gets implemented multiple ways by multiple vendors. That's
a nightmarish vision we want to avoid. Hence I proposed these as *optional
features*. I do not ask you to 'vote for accepting it', I ask you to
consider these under the 'don't have to do this, but if you do, do it this
way'-rule.
Note that, by having them as inline templates (or similar), they are still
'macro-like', but with the benefit of type safety, ADL, namespaces and no
`#undef' and redefining (which I actually consider a benefit). If the issue
you see is with some features of functions/templates/lambdas that macros
don't have or do much differently, please help me understand and I'll try
to come up with an idea that solves both these issues *and* the
above-mentioned benefits.
*Viacheslav Usov> The motivation section has no verbiage like [return] from
the function itself.*I've added an explicit description of this in the
introduction, that is, `return' inside a SE means return from the
evaluating point of the statement expression; similarly for `break',
`continue', et al. Indeed, it was not clear if you don't assume current SE
from gcc.
NB. another possible keyword for `produce' is `continue'. It has the
advantage of not needing a new keyword and that it's similar in meaning to
the current, loop-based `continue'. One can distinguish `continue k' from
`continue', so we can access the loop-based one as long as the function is
not void. If it is, we might need another syntax, perhaps `continue []{}()'
(where the lambda is any no-op expr. evaluating to void).
*Nicol Bolas> I would also suggest that motivations besides "wrap it in a
macro" be specified. The current motivation and examples all suggest that
this feature exists solely for the benefit of macro programming.*
If you could elaborate a bit on this, I'd be happy to fix these parts. For
me, the non-macro-like use case would be the parametric one, but I feel
you're thinking of something else.
*David Krauss> What happens when a reference or pointer is taken to a named
statement expression? Is the name a new kind of entity?*I'd suggest
allowing for both *as long as used within the function*. In runtime, this
is not an issue; in compile-time, this has to be validated by the compiler.
Note that a named SE is like a template in which `return' is resolved by
the function instantiating it.
Thiago Macieira, TONGARI J, Richard Smith> while ({(break; true;)})
Good question! My gut feeling tells to follow what gcc currently *compiles*,
i.e., the control-flow keywords should be overridden as soon as the keyword
is 'in scope', similarly to a variable being considered 'in scope' as soon
as brought in scope. That said, I'm okay to change this if you prefer
otherwise.
Thanks again for all the comments and help on this,
-lorro
--
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/7ec89ac1-3a5b-4b58-8bdc-f6936194d5f7%40isocpp.org.
------=_Part_46_1172750703.1486605844542
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">... continued from previous mail ...<br><br><i><b>Nicol Bo=
las> But you shouldn't let that restrict the proposal unduly. Not un=
less you=20
have specific knowledge that such implementations would be a hardship.<br><=
/b></i>I'd be the best if all the features were accepted by the committ=
ee; however, I do not want to keep it from being standardized if some point=
s are inconclusive/rejected. Therefore I suggested a 'tristate ticklist=
' where each feature can be accepted, rejected (in which 2 cases featur=
e disc. macros are unnecessary) or optionally accepted (in which case a fea=
t. disc. macro is suggested). Optional, as in other parts of the standard m=
eans: you, as a compiler writer 'don't have to do this, but if you =
do, do it this way'.<br>Note that I'm new and not aware of the voti=
ng process. If such a proposal cannot be made, let me know and I come up wi=
th something else.<br>As for hardships, I've checked some manuals. Inte=
l especially claims that destructors and some other features are not allowe=
d due to the difficulty of them (think of it this way: <i>when</i> should a=
n object created in SE be destructed? If at produce, we can't have RAII=
; if at the end of the statement, we need to specifically state that SE bod=
y is function-like in the sense that "temporaries don't last till =
the end of the statement").<br><br><i><b>Nicol Bolas> Now, paramete=
rs and "named statements", I don't think those should even be=
part of the proposal. </b></i><i><b>I don't want C++ to have named/par=
ameterized statement expressions at all, <i>let alone</i> templates of them=
.. </b></i><br>I understand you don't want these. I'd like you to un=
derstand that many, including myself, do. Thus it - sooner or later - gets =
implemented (read: I'm already looking into how to do it on Itanium ABI=
); and if it's not standardized, it gets implemented multiple ways by m=
ultiple vendors. That's a nightmarish vision we want to avoid. Hence I =
proposed these as <i>optional features</i>. I do not ask you to 'vote f=
or accepting it', I ask you to consider these under the 'don't =
have to do this, but if you do, do it this way'-rule.<br>Note that, by =
having them as inline templates (or similar), they are still=20
'macro-like', but with the benefit of type safety, ADL, namespaces =
and=20
no `#undef' and redefining (which I actually consider a benefit). If th=
e
issue you see is with some features of functions/templates/lambdas that
macros don't have or do much differently, please help me understand an=
d I'll try to come up=20
with an idea that solves both these issues <i>and</i> the above-mentioned b=
enefits.<br><i><b><span class=3D"_username"><span class=3D"IVILX2C-D-a" sty=
le=3D"color: rgb(34, 34, 34);">Viacheslav Usov> </span></span>The motiva=
tion section has no verbiage like [return] <span style=3D"font-size:12.8px"=
><u>from the function itself.</u><br></span></b><span style=3D"font-size:12=
..8px"></span></i><span style=3D"font-size:12.8px">I've added an explici=
t description of this in the introduction, that is, `return' inside a S=
E means return from the evaluating point of the statement expression; simil=
arly for `break', `continue', et al. Indeed, it was not clear if yo=
u don't assume current</span> SE from gcc.<br>NB. another possible keyw=
ord for `produce' is `continue'. It has the advantage of not needin=
g a new keyword and that it's similar in meaning to the current, loop-b=
ased `continue'. One can distinguish `continue k' from `continue=
9;, so we can access the loop-based one as long as the function is not void=
.. If it is, we might need another syntax, perhaps `continue []{}()' (wh=
ere the lambda is any no-op expr. evaluating to void).<br><br><i><b>Nicol B=
olas> I would also suggest that motivations besides "wrap it in a m=
acro" be specified. The current motivation and examples all suggest th=
at this feature exists solely for the benefit of macro programming.</b></i>=
<br>If you could elaborate a bit on this, I'd be happy to fix these par=
ts. For me, the non-macro-like use case would be the parametric one, but I =
feel you're thinking of something else.<br><br><i><b>David Krauss> W=
hat happens when a reference or pointer is taken to a named statement expre=
ssion? Is the name a new kind of entity?<br></b></i>I'd suggest allowin=
g for both <i>as long as used within the function</i>. In runtime, this is =
not an issue; in compile-time, this has to be validated by the compiler. No=
te that a named SE is like a template in which `return' is resolved by =
the function instantiating it.<br><br><span class=3D"_username"><span class=
=3D"IVILX2C-D-a" style=3D"color: rgb(34, 34, 34);">Thiago Macieira, </span>=
</span><span class=3D"_username"><span class=3D"IVILX2C-D-a" style=3D"color=
: rgb(34, 34, 34);"><span class=3D"_username"><span class=3D"IVILX2C-D-a" s=
tyle=3D"color: rgb(34, 34, 34);">TONGARI J, </span></span>Richard Smith>=
</span></span>while ({(break; true;)})<br>Good question! My gut feeling te=
lls to follow what gcc currently <i>compiles</i>, i.e., the control-flow ke=
ywords should be overridden as soon as the keyword is 'in scope', s=
imilarly to a variable being considered 'in scope' as soon as broug=
ht in scope. That said, I'm okay to change this if you prefer otherwise=
..<br><br>Thanks again for all the comments and help on this,<br>-lorro<br><=
/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/7ec89ac1-3a5b-4b58-8bdc-f6936194d5f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7ec89ac1-3a5b-4b58-8bdc-f6936194d5f7=
%40isocpp.org</a>.<br />
------=_Part_46_1172750703.1486605844542--
------=_Part_45_484713333.1486605844542--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 8 Feb 2017 18:56:59 -0800 (PST)
Raw View
------=_Part_16_361431761.1486609019331
Content-Type: multipart/alternative;
boundary="----=_Part_17_1273314425.1486609019332"
------=_Part_17_1273314425.1486609019332
Content-Type: text/plain; charset=UTF-8
On Wednesday, February 8, 2017 at 9:04:04 PM UTC-5, szollos...@gmail.com
wrote:
>
> ... continued from previous mail ...
>
>
> *Nicol Bolas> But you shouldn't let that restrict the proposal unduly. Not
> unless you have specific knowledge that such implementations would be a
> hardship.*I'd be the best if all the features were accepted by the
> committee; however, I do not want to keep it from being standardized if
> some points are inconclusive/rejected. Therefore I suggested a 'tristate
> ticklist' where each feature can be accepted, rejected (in which 2 cases
> feature disc. macros are unnecessary) or optionally accepted (in which case
> a feat. disc. macro is suggested). Optional, as in other parts of the
> standard means: you, as a compiler writer 'don't have to do this, but if
> you do, do it this way'.
> Note that I'm new and not aware of the voting process. If such a proposal
> cannot be made, let me know and I come up with something else.
> As for hardships, I've checked some manuals. Intel especially claims that
> destructors and some other features are not allowed due to the difficulty
> of them
>
> (think of it this way: *when* should an object created in SE be
> destructed? If at produce, we can't have RAII;
>
Um, why can't you have RAII? That's like saying that you can't have RAII if
you use a lambda to mimic expression statements.
Expression statements should be scopes; hence the use of {} to declare
them. Just like any scope, automatic variables end their lifetimes when
control leaves that scope, whether through "produce" (ugh), return, break,
or whatever. I see no reason why this would affect RAII.
*Nicol Bolas> Now, parameters and "named statements", I don't think those
> should even be part of the proposal. **I don't want C++ to have
> named/parameterized statement expressions at all, let alone templates of
> them. *
> I understand you don't want these. I'd like you to understand that many,
> including myself, do. Thus it - sooner or later - gets implemented (read:
> I'm already looking into how to do it on Itanium ABI); and if it's not
> standardized, it gets implemented multiple ways by multiple vendors. That's
> a nightmarish vision we want to avoid.
>
Are GCC and Clang developers implementing "parameterized named statements"
as a compiler feature? If not, then you seem to be talking about a
hypothetical, not something that's actually happening.
Hence I proposed these as *optional features*. I do not ask you to 'vote
> for accepting it', I ask you to consider these under the 'don't have to do
> this, but if you do, do it this way'-rule.
> Note that, by having them as inline templates (or similar), they are still
> 'macro-like', but with the benefit of type safety, ADL, namespaces and no
> `#undef' and redefining (which I actually consider a benefit).
>
How is there type-safety? How is there ADL or namespaces? All of those
things come from the cite of *usage*, not the cite of definition. What can
the compiler do except convert them into a bunch of tokens to be pasted in
at the right place?
Remember: the whole point of these statements is that they have direct
access to the outer scope. As such, the meaning of potentially every
identifier could be radically different. It's basically templates, only
much, much harder.
Consider something as simple as this:
named_statement stmt() = ({produce foo(thingy);});
So... what does the compiler do with `stmt`? What does that mean? Well, you
could use it in numerous circumstances:
//Case 1
int foo(int);
int thingy = ...;
stmt();
//Case 2
struct bar
{
int foo(int);
void func()
{
int thingy = ...;
stmt();
}
};
//Case 3
struct bar
{
int foo(int);
void func()
{
stmt();
}
int thingy;
};
//Case 4
struct foo{foo(int); ... };
int thingy = ...;
stmt();
In case 1, `stmt` resolves to calling a non-member function named `foo`
with a local variable named `thingy`, resulting in an `int`.
In case 2, `stmt` resolves to calling a member function of `bar` named
`foo`, using a local variable named `thingy`, resulting in an `int`.
In case 3, `stmt` resolves to calling a member function of `bar` named
`foo`, using a member variable named `thingy`, resulting in an `int`.
In case 4, `stmt` resolves to a prvalue of type `foo`, direct initialized
from a variable named `thingy`.
Given just the definition of `stmt`, what can the compiler reasonable do to
that which can result in all of those scenarios being legal C++? The *only
thing it can do* is some basic token recognition and storage, to be
regurgitated later when `stmt` is invoked.
So where do you get "type safety, ADL, namespaces" from? Because `stmt`
knows *nothing* about those things. The call to `foo` may use ADL or be a
member function. Hell, as I pointed out, it may not even be a call; it may
construct a type with that name. So where is the safety here? The compiler
can't know what `foo(thingy)` is, since what it resolves to is entirely
context dependent.
Oh sure, there are some things it might be able to detect that macros
cannot. It knows that `if for else` is not legit code, while a macro can't
tell you that until you actually use it. You can't piece together fragments
of statements; the statements have to be whole and complete on their own.
But otherwise, the compiler has *no idea* what is going on. So I really
don't see the benefits to this over a macro.
Templates are explicit restricted, which makes it possible for the compiler
to have an inkling as to what is going on. In a template, you say
explicitly what kind of thing the template parameters are: values,
typenames, or templates. And dependent names have to be explicitly
qualified, so that the compiler understands what's going on.
A template may invoke different functions depending on its template
arguments. But explicit specializations aside, it cannot do radically
different things with different parameters. An expression that calls a
function *always* calls a function; it never sometimes does direct
initialization.
The only way statement expressions can work is if the cite of their
declaration is also the cite of their invocation.
If the issue you see is with some features of functions/templates/lambdas
> that macros don't have or do much differently, please help me understand
> and I'll try to come up with an idea that solves both these issues *and*
> the above-mentioned benefits.
>
I don't understand what you mean here.
*Nicol Bolas> I would also suggest that motivations besides "wrap it in a
> macro" be specified. The current motivation and examples all suggest that
> this feature exists solely for the benefit of macro programming.*
> If you could elaborate a bit on this, I'd be happy to fix these parts. For
> me, the non-macro-like use case would be the parametric one, but I feel
> you're thinking of something else.
>
Any form of complex variable initialization would qualify. Have you ever
written a block of code who's sole purpose was to compute a value/object?
One that perhaps created a few local variables that nobody else ever
touched? But it's a one-off, so there's no point in making it a function.
And maybe it needs local variables, so that would require you to forward
them as parameters and other hassles; it'd be much clearer to just do it
here.
Have you ever needed to initialize a class member with something that was
too complex to be an expression, so you used a lambda to compute the value?
This is also a common idiom.
To me, statement expressions are all about complex ways to compute a value.
Sometimes, that computation ends in failure (`return`, `break`, `throw`,
etc). But ultimately, the point of using them is to get a value. They have
their own scope, but they're just as much a part of the outer scope as
anything else. So they can access the outer scope just like any other scope.
You seem to want them to make macro writers' lives easier, so that they can
isolate their code from the outside, so that they can affect the outer
scope in some way, etc.
--
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/3f7b192c-4f6d-4a03-b6ca-ce4b2d09fe96%40isocpp.org.
------=_Part_17_1273314425.1486609019332
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, February 8, 2017 at 9:04:04 PM UTC-5, szollo=
s...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">... continued from previous mail ...<br><br><i><b>Nicol Bolas> =
But you shouldn't let that restrict the proposal unduly. Not unless you=
=20
have specific knowledge that such implementations would be a hardship.<br><=
/b></i>I'd
be the best if all the features were accepted by the committee;=20
however, I do not want to keep it from being standardized if some points
are inconclusive/rejected. Therefore I suggested a 'tristate ticklist&=
#39;=20
where each feature can be accepted, rejected (in which 2 cases feature=20
disc. macros are unnecessary) or optionally accepted (in which case a=20
feat. disc. macro is suggested). Optional, as in other parts of the=20
standard means: you, as a compiler writer 'don't have to do this, b=
ut if
you do, do it this way'.<br>Note that I'm new and not aware of the=
=20
voting process. If such a proposal cannot be made, let me know and I=20
come up with something else.<br>As for hardships, I've checked some=20
manuals. Intel especially claims that destructors and some other=20
features are not allowed due to the difficulty of them</div></blockquote><d=
iv><br>=C2=A0</div><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">(think of it this way: <i>when</i> should an object created in SE be =
destructed? If at produce, we can't have RAII;</div></blockquote><div><=
br>Um, why can't you have RAII? That's like saying that you can'=
;t have RAII if you use a lambda to mimic expression statements.<br><br>Exp=
ression
statements should be scopes; hence the use of {} to declare them. Just=20
like any scope, automatic variables end their lifetimes when control=20
leaves that scope, whether through "produce" (ugh), return, break=
, or=20
whatever. I see no reason why this would affect RAII.<br><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><i><b>Nicol Bolas>=
Now, parameters and "named statements", I don't think those =
should even be part of the proposal. </b></i><i><b>I don't want C++ to =
have named/parameterized statement expressions at all, <i>let alone</i> tem=
plates of them. </b></i><br>I
understand you don't want these. I'd like you to understand that m=
any,=20
including myself, do. Thus it - sooner or later - gets implemented=20
(read: I'm already looking into how to do it on Itanium ABI); and if=20
it's not standardized, it gets implemented multiple ways by multiple=20
vendors. That's a nightmarish vision we want to avoid.</div></blockquot=
e><div><br>Are
GCC and Clang developers implementing "parameterized named statements=
"=20
as a compiler feature? If not, then you seem to be talking about a=20
hypothetical, not something that's actually happening.<br><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hence I proposed=
these as <i>optional features</i>.
I do not ask you to 'vote for accepting it', I ask you to consider=
=20
these under the 'don't have to do this, but if you do, do it this=
=20
way'-rule.<br>Note that, by having them as inline templates (or similar=
), they are still=20
'macro-like', but with the benefit of type safety, ADL, namespaces =
and=20
no `#undef' and redefining (which I actually consider a benefit).</div>=
</blockquote><div><br>How is there type-safety? How is there ADL or namespa=
ces? All of those things come from the cite of <i>usage</i>,
not the cite of definition. What can the compiler do except convert=20
them into a bunch of tokens to be pasted in at the right place?<br><br>Reme=
mber:
the whole point of these statements is that they have direct access to=20
the outer scope. As such, the meaning of potentially every identifier=20
could be radically different. It's basically templates, only much, much=
=20
harder.<br><br>Consider something as simple as this:<br><br>named_statement=
stmt() =3D ({produce foo(thingy);});<br><br>So... what does the compiler d=
o with `stmt`? What does that mean? Well, you could use it in numerous circ=
umstances:<br><br>//Case 1<br>int foo(int);<br>int thingy =3D ...;<br>stmt(=
);<br><br>//Case 2<br>struct bar<br>{<br>=C2=A0 int foo(int);<br><br>=C2=A0=
void func()<br>=C2=A0 {<br>=C2=A0=C2=A0=C2=A0 int thingy =3D ...;<br>=C2=
=A0=C2=A0=C2=A0 stmt();<br>=C2=A0 }<br>};<br><br>//Case 3<br>struct bar<br>=
{<br>=C2=A0 int foo(int);<br><br>=C2=A0 void func()<br>=C2=A0 {<br>=C2=A0=
=C2=A0=C2=A0 stmt();<br>=C2=A0 }<br><br>=C2=A0 int thingy;<br>};<br><br>//C=
ase 4<br>struct foo{foo(int); ... };<br>int thingy =3D ...;<br>stmt();<br><=
br>In
case 1, `stmt` resolves to calling a non-member function named `foo`=20
with a local variable named `thingy`, resulting in an `int`.<br><br>In=20
case 2, `stmt` resolves to calling a member function of `bar` named=20
`foo`, using a local variable named `thingy`, resulting in an `int`.<br><br=
>In
case 3, `stmt` resolves to calling a member function of `bar` named=20
`foo`, using a member variable named `thingy`, resulting in an `int`.<br><b=
r>In case 4, `stmt` resolves to a prvalue of type `foo`, direct initialized=
from a variable named `thingy`.<br><br>Given
just the definition of `stmt`, what can the compiler reasonable do to=20
that which can result in all of those scenarios being legal C++? The <i>onl=
y thing it can do</i> is some basic token recognition and storage, to be re=
gurgitated later when `stmt` is invoked.<br><br>So where do you get "t=
ype safety, ADL, namespaces" from? Because `stmt` knows <i>nothing</i>
about those things. The call to `foo` may use ADL or be a member=20
function. Hell, as I pointed out, it may not even be a call; it may=20
construct a type with that name. So where is the safety here? The=20
compiler can't know what `foo(thingy)` is, since what it resolves to is=
=20
entirely context dependent.<br><br>Oh sure, there are some things it=20
might be able to detect that macros cannot. It knows that `if for else`=20
is not legit code, while a macro can't tell you that until you actually=
=20
use it. You can't piece together fragments of statements; the statement=
s
have to be whole and complete on their own.<br><br>But otherwise, the comp=
iler has <i>no idea</i> what is going on. So I really don't see the ben=
efits to this over a macro.<br><br>Templates
are explicit restricted, which makes it possible for the compiler to=20
have an inkling as to what is going on. In a template, you say=20
explicitly what kind of thing the template parameters are: values,=20
typenames, or templates. And dependent names have to be explicitly=20
qualified, so that the compiler understands what's going on.<br><br>A=
=20
template may invoke different functions depending on its template=20
arguments. But explicit specializations aside, it cannot do radically=20
different things with different parameters. An expression that calls a=20
function <i>always</i> calls a function; it never sometimes does direct ini=
tialization.<br><br>The only way statement expressions can work is if the c=
ite of their declaration is also the cite of their invocation.<br><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">If the
issue you see is with some features of functions/templates/lambdas that
macros don't have or do much differently, please help me understand an=
d I'll try to come up=20
with an idea that solves both these issues <i>and</i> the above-mentioned b=
enefits.<br></div></blockquote><div><br>I don't understand what you mea=
n here.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><i><b>Nicol
Bolas> I would also suggest that motivations besides "wrap it in a=
=20
macro" be specified. The current motivation and examples all suggest=
=20
that this feature exists solely for the benefit of macro programming.</b></=
i><br>If
you could elaborate a bit on this, I'd be happy to fix these parts. Fo=
r
me, the non-macro-like use case would be the parametric one, but I feel
you're thinking of something else.<br></div></blockquote><div><br>Any=
=20
form of complex variable initialization would qualify. Have you ever=20
written a block of code who's sole purpose was to compute a=20
value/object? One that perhaps created a few local variables that nobody
else ever touched? But it's a one-off, so there's no point in maki=
ng it
a function. And maybe it needs local variables, so that would require=20
you to forward them as parameters and other hassles; it'd be much=20
clearer to just do it here.<br><br>Have you ever needed to initialize a=20
class member with something that was too complex to be an expression, so
you used a lambda to compute the value? This is also a common idiom.<br><b=
r>To
me, statement expressions are all about complex ways to compute a=20
value. Sometimes, that computation ends in failure (`return`, `break`,=20
`throw`, etc). But ultimately, the point of using them is to get a=20
value. They have their own scope, but they're just as much a part of th=
e
outer scope as anything else. So they can access the outer scope just=20
like any other scope.<br><br>You seem to want them to make macro=20
writers' lives easier, so that they can isolate their code from the=20
outside, so that they can affect the outer scope in some way, etc.</div></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/3f7b192c-4f6d-4a03-b6ca-ce4b2d09fe96%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3f7b192c-4f6d-4a03-b6ca-ce4b2d09fe96=
%40isocpp.org</a>.<br />
------=_Part_17_1273314425.1486609019332--
------=_Part_16_361431761.1486609019331--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Thu, 9 Feb 2017 11:28:50 +0100
Raw View
--001a1140233290427e05481672ff
Content-Type: text/plain; charset=UTF-8
Frankly, I do not really understand *why* we would want this.
Without the control statements, statement expressions are not different
from lambdas as I remarked earlier.
So it is really flow control inside expressions that is being proposed. But
the only motivating example given is a way to write a macro. Examples given
further, up to the parametric SE, are also focused on macros. So, just
given the proposal (up to PSE), we are talking about a language feature to
support macro-programming. That kind of motivation seems strange to me.
Now, the parametric stuff. The essence of that is a non-local transfer of
control from arbitrary functions. That is akin to exceptions, and, given
the story of noexcept, we have firmly established that we need means of
establishing hard guarantees of no non-local transfer of control. Now, if
we introduce another non-local transfer mechanism, we will also introduce
the same pile of problems that noexcept has dealt with.
Cheers,
V.
--
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/CAA7YVg2mbdj4jsj-WHJKyC2%3D93aGzYXz1RM4LYkzyfBP%3DdW%3DaA%40mail.gmail.com.
--001a1140233290427e05481672ff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">Frankly, I do not really unders=
tand <i>why</i>=C2=A0we would want this.</div><div class=3D"gmail_extra"><b=
r></div><div class=3D"gmail_extra">Without the control statements, statemen=
t expressions are not different from lambdas as I remarked earlier.</div><d=
iv class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">So it is real=
ly flow control inside expressions that is being proposed. But the only mot=
ivating example given is a way to write a macro. Examples given further, up=
to the parametric SE, are also focused on macros. So, just given the propo=
sal (up to PSE), we are talking about a language feature to support macro-p=
rogramming. That kind of motivation seems strange to me.</div><div class=3D=
"gmail_extra"><br></div><div class=3D"gmail_extra">Now, the parametric stuf=
f. The essence of that is a non-local transfer of control from arbitrary fu=
nctions. That is akin to exceptions, and, given the story of noexcept, we h=
ave firmly established that we need means of establishing hard guarantees o=
f no non-local transfer of control. Now, if we introduce another non-local =
transfer mechanism, we will also introduce the same pile of problems that n=
oexcept has dealt with.</div><div class=3D"gmail_extra"><br></div><div clas=
s=3D"gmail_extra">Cheers,</div><div class=3D"gmail_extra">V.</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/CAA7YVg2mbdj4jsj-WHJKyC2%3D93aGzYXz1R=
M4LYkzyfBP%3DdW%3DaA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2mbd=
j4jsj-WHJKyC2%3D93aGzYXz1RM4LYkzyfBP%3DdW%3DaA%40mail.gmail.com</a>.<br />
--001a1140233290427e05481672ff--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 9 Feb 2017 07:32:36 -0800 (PST)
Raw View
------=_Part_223_700770201.1486654356218
Content-Type: multipart/alternative;
boundary="----=_Part_224_504266782.1486654356218"
------=_Part_224_504266782.1486654356218
Content-Type: text/plain; charset=UTF-8
On Thursday, February 9, 2017 at 5:28:56 AM UTC-5, Viacheslav Usov wrote:
>
> Frankly, I do not really understand *why* we would want this.
>
> Without the control statements, statement expressions are not different
> from lambdas as I remarked earlier.
>
Ignoring return/break/continue, they are different from lambdas in several
ways. They're much cleaner, for example. It's hard to recognize the
difference between:
auto i = [&] {
//several
//lines
//of
//code
};
And:
auto i = [&] {
//several
//lines
//of
//code
}();
With a statement expression, the distinction becomes quite clear.
Also, manipulating scope-accessible variables does not require you to say
`[&] mutable`, as it would with a lambda.
> So it is really flow control inside expressions that is being proposed.
> But the only motivating example given is a way to write a macro. Examples
> given further, up to the parametric SE, are also focused on macros. So,
> just given the proposal (up to PSE), we are talking about a language
> feature to support macro-programming. That kind of motivation seems strange
> to me.
>
> Now, the parametric stuff. The essence of that is a non-local transfer of
> control from arbitrary functions. That is akin to exceptions, and, given
> the story of noexcept, we have firmly established that we need means of
> establishing hard guarantees of no non-local transfer of control.
>
That's not the point of noexcept. The point of noexcept is to allow code to
detect when a process may not fail and thus potentially use more efficient
algorithms. `variant` implementations benefit from this greatly.
Issuing a non-local return/break/continue through code would not be the
same thing.
Now, I highly despise the idea of passing around functions that can
non-local jump out of code. But my concern is not about `noexcept` and so
forth. It's about the ease with which such things can be broken. Adding an
exception-like mechanism for them will not change how easy they are to
break.
--
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/1e70b7b4-3bf9-4a87-8721-8a2ef024a1ef%40isocpp.org.
------=_Part_224_504266782.1486654356218
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, February 9, 2017 at 5:28:56 AM UTC-5, Viaches=
lav Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div>Frankly, I do not really understand <i>why</i>=C2=A0we would want th=
is.</div><div><br></div><div>Without the control statements, statement expr=
essions are not different from lambdas as I remarked earlier.</div></div></=
blockquote><div><br>Ignoring return/break/continue, they are different from=
lambdas in several ways. They're much cleaner, for example. It's h=
ard to recognize the difference between:<br><br><div style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><=
code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> i </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</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"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">//several=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">//lines</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 <=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">//of</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span=
><span style=3D"color: #800;" class=3D"styled-by-prettify">//code</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code></di=
v><br>And:<br><br><div style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; overfl=
ow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><di=
v class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-=
prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> i </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">[&]</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"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: =
#800;" class=3D"styled-by-prettify">//several</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: =
#800;" class=3D"styled-by-prettify">//lines</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">//of</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">//code</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">}();</span></div></code></div><br>With a statement expre=
ssion, the distinction becomes quite clear.<br><br>Also, manipulating scope=
-accessible variables does not require you to say `[&] mutable`, as it =
would with a lambda.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><div>So it is really flow control inside express=
ions that is being proposed. But the only motivating example given is a way=
to write a macro. Examples given further, up to the parametric SE, are als=
o focused on macros. So, just given the proposal (up to PSE), we are talkin=
g about a language feature to support macro-programming. That kind of motiv=
ation seems strange to me.</div><div><br></div><div>Now, the parametric stu=
ff. The essence of that is a non-local transfer of control from arbitrary f=
unctions. That is akin to exceptions, and, given the story of noexcept, we =
have firmly established that we need means of establishing hard guarantees =
of no non-local transfer of control.</div></div></blockquote><div><br>That&=
#39;s not the point of noexcept. The point of noexcept is to allow code to =
detect when a process may not fail and thus potentially use more efficient =
algorithms. `variant` implementations benefit from this greatly.<br><br>Iss=
uing a non-local return/break/continue through code would not be the same t=
hing.<br><br>Now, I highly despise the idea of passing around functions tha=
t can non-local jump out of code. But my concern is not about `noexcept` an=
d so forth. It's about the ease with which such things can be broken. A=
dding an exception-like mechanism for them will not change how easy they ar=
e to break.<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/1e70b7b4-3bf9-4a87-8721-8a2ef024a1ef%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1e70b7b4-3bf9-4a87-8721-8a2ef024a1ef=
%40isocpp.org</a>.<br />
------=_Part_224_504266782.1486654356218--
------=_Part_223_700770201.1486654356218--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Thu, 9 Feb 2017 16:48:01 +0100
Raw View
--001a114105dc02f93605481ae8c3
Content-Type: text/plain; charset=UTF-8
On Thu, Feb 9, 2017 at 4:32 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> With a statement expression, the distinction becomes quite clear.
True, and I almost proposed some nicer syntax for that some time ago, but
we are ultimately talking about a three char difference.
> That's not the point of noexcept. The point of noexcept is to allow code
to detect when a process may not fail and thus potentially use more
efficient algorithms. `variant` implementations benefit from this greatly.
"May not fail" is just a sub-set of "no non-local transfer of control".
> Issuing a non-local return/break/continue through code would not be the
same thing.
Yeah, by definition, *if *so defined. Functionally, though, one could
implement all that non-local stuff with exceptions today.
Because functionally they are really similar. I singled out noexcept simply
because its very existence is tangible evidence that we want very strict
control over non-local transfer of control. I agree that all that non-local
stuff adds a lot more complexity than we might want to deal with, in more
than just one way.
Cheers,
V.
--
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/CAA7YVg3X29-O2Jse4GtUst2x%3DF2JjMEno%3D3vHZ%2BbpsaTdHE28Q%40mail.gmail.com.
--001a114105dc02f93605481ae8c3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Feb 9, 2017 at 4:32 PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>></sp=
an> wrote:<br><div><br></div><div>> With a statement expression, the dis=
tinction becomes quite clear.</div><div><br></div><div>True, and I almost p=
roposed some nicer syntax for that some time ago, but we are ultimately tal=
king about a three char difference.</div><div><br></div><div>> That'=
s not the point of noexcept. The point of noexcept is to allow code to dete=
ct when a process may not fail and thus potentially use more efficient algo=
rithms. `variant` implementations benefit from this greatly.</div><div><br>=
</div><div>"May not fail" is just a sub-set of "no non-local=
transfer of control".</div><div><br></div><div>> Issuing a non-loc=
al return/break/continue through code would not be the same thing.</div><di=
v><br></div><div>Yeah, by definition, <i>if </i>so defined. Functionally, t=
hough, one could implement all that non-local stuff with exceptions today.<=
/div><div><br></div><div>Because functionally they are really similar. I si=
ngled out noexcept simply because its very existence is tangible evidence t=
hat we want very strict control over non-local transfer of control. I agree=
that all that non-local stuff adds a lot more complexity than we might wan=
t to deal with, in more than just one way.</div><div><br></div><div>Cheers,=
</div><div>V.</div></div></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/CAA7YVg3X29-O2Jse4GtUst2x%3DF2JjMEno%=
3D3vHZ%2BbpsaTdHE28Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg3X29=
-O2Jse4GtUst2x%3DF2JjMEno%3D3vHZ%2BbpsaTdHE28Q%40mail.gmail.com</a>.<br />
--001a114105dc02f93605481ae8c3--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 09 Feb 2017 10:05:05 -0800
Raw View
On quinta-feira, 9 de fevereiro de 2017 07:32:36 PST Nicol Bolas wrote:
> auto i = [&] {
> //several
> //lines
> //of
> //code
> };
>
> And:
>
> auto i = [&] {
> //several
> //lines
> //of
> //code
> }();
Easy solution: use the actual return type, instead of auto.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/2864746.nM5Srvyeaq%40tjmaciei-mobl1.
.
Author: szollosi.lorand@gmail.com
Date: Thu, 9 Feb 2017 13:39:36 -0800 (PST)
Raw View
------=_Part_360_423636968.1486676376967
Content-Type: multipart/alternative;
boundary="----=_Part_361_2121243896.1486676376967"
------=_Part_361_2121243896.1486676376967
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi,
2017. febru=C3=A1r 9., cs=C3=BCt=C3=B6rt=C3=B6k 3:56:59 UTC+1 id=C5=91pontb=
an Nicol Bolas a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
>
> Um, why can't you have RAII? That's like saying that you can't have RAII=
=20
> if you use a lambda to mimic expression statements.
>
> I hope we can, and I agree with the above implementation if Intel can be=
=20
concieved.
=20
> Consider something as simple as this:
>
> named_statement stmt() =3D ({produce foo(thingy);});
>
> So... what does the compiler do with `stmt`? What does that mean?
>
Ok, I see your point much clearer now and I can assure you, I don't want=20
the things you mentioned (neither in this proposal nor the next). I'm=20
actually going for something much cleaner and lightweight with named SE;=20
thus, I think I should rewrite this part. My plan is to make the above a=20
compile-time error outright. The reason it's a compile-time error is that=
=20
`foo' and `thingy' are not defined *at the point of definition*. If you=20
want a named SE / parametric SE that has parameters called `foo' and=20
`thingy' (as opposed to capture, which we normally do), you naturally have=
=20
to specify it (along with type) in the function argument list:
template<typename F, typename T>
auto namedstmt(F&& foo, T&& thingy)
/* -> decltype(foo(thingy)) */ // if needed
({ produce foo(thingy); })
}
auto paramstmt =3D [&](auto&& foo, auto&& thingy)=20
/* -> decltype(foo(thingy)) */ // if needed
({ produce foo(thingy); })
Note that this (the lambda-like parametric version) still allows for=20
capturing *in the defining context*:
int foo(int);
auto paramstmt =3D [&](auto&& thingy)=20
/* -> decltype(foo(thingy)) */ // if needed
({ produce foo(thingy); })
=20
Note that we have perfect type safety from the point the named / parametric=
=20
SE appears in the code. I do think that we want very similar things: when=
=20
you say 'appear only once', I translate it to 'capture only once'. After=20
all, calling these kind of expressions is not much different from building=
=20
a trampoline and placing them in a loop.
As for use cases: for anything that doesn't need control stmts, I have to=
=20
admit that I'm currently using lambdas. I also agree, had SE been=20
standardized, I used them all the time instead of `[&]{ ... }()'; not=20
because of the 5 chars, but because it's cleaner.
You seem to want them to make macro writers' lives easier, so that they can=
=20
> isolate their code from the outside, so that they can affect the outer=20
> scope in some way, etc.
>
Quite the contrary: I'm planning to estabilish a language construct that=20
*avoids* macros. Indeed, I have to fix the proposal in many points: I only=
=20
introduced named / parametric SE in the end, therefore there are only=20
macro-based examples before. This needs to be fixed. I also want to point=
=20
out how it can be used without involving macros (both simple SE and named /=
=20
parametric SE).
--=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/5ef67df0-42f7-4867-9143-b0fb409f5a41%40isocpp.or=
g.
------=_Part_361_2121243896.1486676376967
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>2017. febru=C3=A1r 9., cs=C3=BCt=C3=B6rt=C3=B6k=
3:56:59 UTC+1 id=C5=91pontban Nicol Bolas a k=C3=B6vetkez=C5=91t =C3=ADrta=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><div>Um,=
why can't you have RAII? That's like saying that you can't hav=
e RAII if you use a lambda to mimic expression statements.<br><br></div></d=
iv></blockquote><div>I hope we can, and I agree with the above implementati=
on if Intel can be concieved.<br>=C2=A0<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr">Consider something as simple as this:<b=
r><div><br>named_statement stmt() =3D ({produce foo(thingy);});<br><br>So..=
.. what does the compiler do with `stmt`? What does that mean?</div></div></=
blockquote><div>Ok, I see your point much clearer now and I can assure you,=
I don't want the things you mentioned (neither in this proposal nor th=
e next). I'm actually going for something much cleaner and lightweight =
with named SE; thus, I think I should rewrite this part. My plan is to make=
the above a compile-time error outright. The reason it's a compile-tim=
e error is that `foo' and `thingy' are not defined <i>at the point =
of definition</i>. If you want a named SE / parametric SE that has paramete=
rs called `foo' and `thingy' (as opposed to capture, which we norma=
lly do), you naturally have to specify it (along with type) in the function=
argument list:<br><br><div style=3D"background-color: rgb(250, 250, 250); =
border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; o=
verflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint=
"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"style=
d-by-prettify">template</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">typename</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> F</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> T</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">auto</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> namedstmt</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">F</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&&</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">&&</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> thingy</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">/* -> decltype(foo(thingy)) */=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> // if nee=
ded<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">({<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> produce fo=
o</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">thingy</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">);</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"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> paramstmt</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify"> =3D [&](</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">auto</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&&</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&&</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> thingy</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><br><code class=3D"prettyprin=
t"><span style=3D"color: #800;" class=3D"styled-by-prettify">/* -> declt=
ype(foo(thingy)) */ </span></code><code class=3D"prettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">// if needed<br></span></cod=
e><span style=3D"color: #660;" class=3D"styled-by-prettify">({</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> produce foo</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">thingy</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">})</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span></div></code></div><br>Note that this (the lam=
bda-like parametric version) still allows for capturing <i>in the defining =
context</i>:<br><br><br><div style=3D"background-color: rgb(250, 250, 250);=
border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; =
overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprin=
t"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">int foo(int);<br><br></span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> paramstmt</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify"> =3D [&](</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify"></span><span style=3D"color: #660;" class=3D"styled=
-by-prettify"></span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"></span><span style=3D"color: #660;" class=3D"styled-by-prettify"></span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&&</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> thingy</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><br><code class=3D"prettyprint"><spa=
n style=3D"color: #800;" class=3D"styled-by-prettify">/* -> decltype(foo=
(thingy)) */ </span></code><code class=3D"prettyprint"><span style=3D"color=
: #000;" class=3D"styled-by-prettify">// if needed<br></span></code><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">({</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> produce foo</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">thingy</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">})</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span></div></code></div>=C2=A0<br>Note that we have perfect =
type safety from the point the named / parametric SE appears in the code. I=
do think that we want very similar things: when you say 'appear only o=
nce', I translate it to 'capture only once'. After all, calling=
these kind of expressions is not much different from building a trampoline=
and placing them in a loop.<br><br>As for use cases: for anything that doe=
sn't need control stmts, I have to admit that I'm currently using l=
ambdas. I also agree, had SE been standardized, I used them all the time in=
stead of `[&]{ ... }()'; not because of the 5 chars, but because it=
's cleaner.<br><br><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">You seem to want them to make macro=20
writers' lives easier, so that they can isolate their code from the=20
outside, so that they can affect the outer scope in some way, etc.<br></div=
></blockquote>Quite the contrary: I'm planning to estabilish a language=
construct that <i>avoids</i> macros. Indeed, I have to fix the proposal in=
many points: I only introduced named / parametric SE in the end, therefore=
there are only macro-based examples before. This needs to be fixed. I also=
want to point out how it can be used without involving macros (both simple=
SE and named / parametric SE).<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/5ef67df0-42f7-4867-9143-b0fb409f5a41%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5ef67df0-42f7-4867-9143-b0fb409f5a41=
%40isocpp.org</a>.<br />
------=_Part_361_2121243896.1486676376967--
------=_Part_360_423636968.1486676376967--
.
Author: szollosi.lorand@gmail.com
Date: Thu, 9 Feb 2017 14:00:36 -0800 (PST)
Raw View
------=_Part_341_111207975.1486677636050
Content-Type: multipart/alternative;
boundary="----=_Part_342_1906882658.1486677636050"
------=_Part_342_1906882658.1486677636050
Content-Type: text/plain; charset=UTF-8
....
Hi,
Now, the parametric stuff. The essence of that is a non-local transfer of
> control from arbitrary functions. That is akin to exceptions, and, given
> the story of noexcept, we have firmly established that we need means of
> establishing hard guarantees of no non-local transfer of control. Now, if
> we introduce another non-local transfer mechanism, we will also introduce
> the same pile of problems that noexcept has dealt with.
>
My understanding is that the problem with exceptions is that a function
(unless `noexcept()') can throw *anything*, therefore control might be
taken to *any other* (outer) catch block *dynamically.* Neither of these
three apply to any SE, not even to my other idea on the "capturing
monads..." thread (`throw inline / catch inline'):
- we can tell exactly which kind of control transfers can happen
(because SE *source* must be visible, thus you see the captured control
stmts);
- at this point, only the caller is affected (in the "capturing
monads..." thread this is different, but still the exact type -> catch is
deducible compile-time or in IDE);
- all of these bind compile-time, whereas exceptions (as of today) bind
runtime, which is their greatest limiting factor.
To put it another way, probably noone complained about a function that
returns `std::variant<return_type, exception_types...>'. In fact, SE moves
in this direction, as the variant is easily checked / delegated for
visitation inside and the code logic is kept intact.
Thanks,
-lorro
--
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/8600c33f-3f20-48bc-b030-281a4fa64692%40isocpp.org.
------=_Part_342_1906882658.1486677636050
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">...<br><br>Hi,<br><br><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div>Now, the parametric stuff. The essence of th=
at is a non-local transfer of control from arbitrary functions. That is aki=
n to exceptions, and, given the story of noexcept, we have firmly establish=
ed that we need means of establishing hard guarantees of no non-local trans=
fer of control. Now, if we introduce another non-local transfer mechanism, =
we will also introduce the same pile of problems that noexcept has dealt wi=
th.</div></div></blockquote><div>My understanding is that the problem with =
exceptions is that a function (unless `noexcept()') can throw <i>anythi=
ng</i>, therefore control might be taken to <i>any other</i> (outer) catch =
block <i>dynamically.</i> Neither of these three apply to any SE, not even =
to my other idea on the "capturing monads..." thread (`throw inli=
ne / catch inline'):<br><ul><li>we can tell exactly which kind of contr=
ol transfers can happen (because SE <i>source</i> must be visible, thus you=
see the captured control stmts);</li><li>at this point, only the caller is=
affected (in the "capturing monads..." thread this is different,=
but still the exact type -> catch is deducible compile-time or in IDE);=
</li><li>all of these bind compile-time, whereas exceptions (as of today) b=
ind runtime, which is their greatest limiting factor.</li></ul>To put it an=
other way, probably noone complained about a function that returns `std::va=
riant<return_type, exception_types...>'. In fact, SE moves in thi=
s direction, as the variant is easily checked / delegated for visitation in=
side and the code logic is kept intact.<br><br>Thanks,<br>-lorro<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/8600c33f-3f20-48bc-b030-281a4fa64692%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8600c33f-3f20-48bc-b030-281a4fa64692=
%40isocpp.org</a>.<br />
------=_Part_342_1906882658.1486677636050--
------=_Part_341_111207975.1486677636050--
.
Author: szollosi.lorand@gmail.com
Date: Thu, 9 Feb 2017 14:30:13 -0800 (PST)
Raw View
------=_Part_441_980215307.1486679414064
Content-Type: multipart/alternative;
boundary="----=_Part_442_1480292210.1486679414064"
------=_Part_442_1480292210.1486679414064
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
....
Hi,
2017. febru=C3=A1r 9., cs=C3=BCt=C3=B6rt=C3=B6k 19:05:17 UTC+1 id=C5=91pont=
ban Thiago Macieira a=20
k=C3=B6vetkez=C5=91t =C3=ADrta:
>
> On quinta-feira, 9 de fevereiro de 2017 07:32:36 PST Nicol Bolas wrote:=
=20
> > auto i =3D [&] {=20
> > //several=20
> > //lines=20
> > //of=20
> > //code=20
> > };=20
> >=20
> > And:=20
> >=20
> > auto i =3D [&] {=20
> > //several=20
> > //lines=20
> > //of=20
> > //code=20
> > }();=20
>
> Easy solution: use the actual return type, instead of auto.=20
>
Sir, that's indeed doable for simple types, but consider the following:
struct Desc;
std::map<std::string, Desc> sn2desc;
std::set<std::pair<std::string, std::string>> nNsnS;
const std::string k;
// make_filter_first returns a custom range that walks over
// ->second where ->first is k; I used this recently
// Disclaimer: don't do this with boost, that's UB.
auto descs =3D [&]() {
return make_filter_first(ps, k)
| transformed([](const std::string& sn) =3D> sn2desc[sn])
| filtered([](const Desc& desc) =3D> desc.accepted_);
}();
Do you really want to write the type it returns? If I were to, I'd=20
duplicate the body and try find to the typos...
Thanks,
-lorro
--=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/c7732f37-870d-48a3-81b9-78f77074fb40%40isocpp.or=
g.
------=_Part_442_1480292210.1486679414064
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">...<br><br>Hi,<br><br>2017. febru=C3=A1r 9., cs=C3=BCt=C3=
=B6rt=C3=B6k 19:05:17 UTC+1 id=C5=91pontban Thiago Macieira a k=C3=B6vetkez=
=C5=91t =C3=ADrta:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On quinta-fe=
ira, 9 de fevereiro de 2017 07:32:36 PST Nicol Bolas wrote:
<br>> auto i =3D [&] {
<br>> =C2=A0 //several
<br>> =C2=A0 //lines
<br>> =C2=A0 //of
<br>> =C2=A0 //code
<br>> };
<br>>=20
<br>> And:
<br>>=20
<br>> auto i =3D [&] {
<br>> =C2=A0 //several
<br>> =C2=A0 //lines
<br>> =C2=A0 //of
<br>> =C2=A0 //code
<br>> }();
<br>
<br>Easy solution: use the actual return type, instead of auto.
<br></blockquote><div>=C2=A0Sir, that's indeed doable for simple types,=
but consider the following:<br><div style=3D"background-color: rgb(250, 25=
0, 250); border-color: rgb(187, 187, 187); border-style: solid; border-widt=
h: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">struct Desc;<br>std::map<std::string, Desc> s=
n2desc;</span><br><span style=3D"color: #008;" class=3D"styled-by-prettify"=
><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">set=
</span><span style=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;" class=3D"styled-by-prettify">pair</span><span style=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;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">string</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">string</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">>></span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> nNsnS</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;<br></span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">const</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: #008;" class=
=3D"styled-by-prettify">string</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify"></span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> k;<br></span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify"></span></code></span><span style=3D"color: #008;" class=3D"styled-by=
-prettify"><code class=3D"prettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify"><br>// </span></code></span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span styl=
e=3D"color: #800;" class=3D"styled-by-prettify"><code class=3D"prettyprint"=
><span style=3D"color: #000;" class=3D"styled-by-prettify">make_filter_firs=
t</span><span style=3D"color: #660;" class=3D"styled-by-prettify"> </span><=
/code>returns a custom range that walks over<br>// ->second where ->f=
irst is k</span><span style=3D"color: #000;" class=3D"styled-by-prettify">;=
I used this recently<br>// Disclaimer: don't do this with boost, that&=
#39;s UB.<br></span></code></span></code>auto</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> descs </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">[&]</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"></span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> {</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"></span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0=C2=A0=C2=A0 return </s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">make_filter_f=
irst</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">ps</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> k</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 |</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> transformed([](const std::string& sn) =3D> sn2de=
sc[sn])</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0 =C2=A0=C2=A0 | filtered([](const Des=
c& desc) =3D> desc.accepted_);<br></span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span=
style=3D"color: #000;" class=3D"styled-by-prettify"></span></code></span><=
/code>}();<br></span></div></code></div><br>Do you really want to write the=
type it returns? If I were to, I'd duplicate the body and try find to =
the typos...<br><br>Thanks,<br>-lorro<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/c7732f37-870d-48a3-81b9-78f77074fb40%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c7732f37-870d-48a3-81b9-78f77074fb40=
%40isocpp.org</a>.<br />
------=_Part_442_1480292210.1486679414064--
------=_Part_441_980215307.1486679414064--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 9 Feb 2017 15:42:26 -0800 (PST)
Raw View
------=_Part_426_945630055.1486683746393
Content-Type: multipart/alternative;
boundary="----=_Part_427_1184142682.1486683746394"
------=_Part_427_1184142682.1486683746394
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, February 9, 2017 at 4:39:37 PM UTC-5, szollos...@gmail.com=20
wrote:
>
> Hi,
>
> 2017. febru=C3=A1r 9., cs=C3=BCt=C3=B6rt=C3=B6k 3:56:59 UTC+1 id=C5=91pon=
tban Nicol Bolas a=20
> k=C3=B6vetkez=C5=91t =C3=ADrta:
>>
>>
>> Um, why can't you have RAII? That's like saying that you can't have RAII=
=20
>> if you use a lambda to mimic expression statements.
>>
>> I hope we can, and I agree with the above implementation if Intel can be=
=20
> concieved.
>
Who cares what Intel says or doesn't say? The goal isn't to take some=20
intersection of random stuff from separate compilers. The goal is to make a=
=20
functioning feature which is standard across compilers. If that means Intel=
=20
has to do some work, then they have to do some work.
Just like Microsoft had to practically rebuild their front-end to make=20
`constexpr`, expression SFINAE, and other C++11 features work (not to=20
mention two-phase lookup which they still haven't done).
Consider something as simple as this:
>>
>> named_statement stmt() =3D ({produce foo(thingy);});
>>
>> So... what does the compiler do with `stmt`? What does that mean?
>>
> Ok, I see your point much clearer now and I can assure you, I don't want=
=20
> the things you mentioned (neither in this proposal nor the next). I'm=20
> actually going for something much cleaner and lightweight with named SE;=
=20
> thus, I think I should rewrite this part. My plan is to make the above a=
=20
> compile-time error outright. The reason it's a compile-time error is that=
=20
> `foo' and `thingy' are not defined *at the point of definition*. If you=
=20
> want a named SE / parametric SE that has parameters called `foo' and=20
> `thingy' (as opposed to capture, which we normally do), you naturally hav=
e=20
> to specify it (along with type) in the function argument list:
>
> template<typename F, typename T>
> auto namedstmt(F&& foo, T&& thingy)
> /* -> decltype(foo(thingy)) */ // if needed
> ({ produce foo(thingy); })
> }
>
> auto paramstmt =3D [&](auto&& foo, auto&& thingy)=20
> /* -> decltype(foo(thingy)) */ // if needed
> ({ produce foo(thingy); })
>
>
OK, so you don't actually want statement expressions. What you want are a=
=20
slightly modified of function that can magically invoke=20
`return/break/continue` into their calling contexts. Presumably through=20
multiple layers of such functions.
Because right now, that seems to be the *only difference* between a named=
=20
SE and a function.
You also need to explain exactly what kind of error you get if `break` or=
=20
`continue` isn't legal from the context in which a statement function is=20
called.
I'm starting to agree with Viacheslav here. This is starting to seem very=
=20
much like a modified form of exception handling. Essentially, you're saying=
=20
`throw return value` or `throw break` or whatever. And the compiler catches=
=20
it at certain places and does that.
--=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/6818d534-e764-4ccf-ab05-bd4358cd1db9%40isocpp.or=
g.
------=_Part_427_1184142682.1486683746394
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, February 9, 2017 at 4:39:37 PM UTC-5, szollos=
....@gmail.com 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">Hi,<br><br>2017. febru=C3=A1r 9., cs=C3=BCt=C3=B6rt=C3=B6k 3:56:59=
UTC+1 id=C5=91pontban Nicol Bolas a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>Um, why can'=
t you have RAII? That's like saying that you can't have RAII if you=
use a lambda to mimic expression statements.<br><br></div></div></blockquo=
te><div>I hope we can, and I agree with the above implementation if Intel c=
an be concieved.</div></div></blockquote><div><br>Who cares what Intel says=
or doesn't say? The goal isn't to take some intersection of random=
stuff from separate compilers. The goal is to make a functioning feature w=
hich is standard across compilers. If that means Intel has to do some work,=
then they have to do some work.<br><br>Just like Microsoft had to practica=
lly rebuild their front-end to make `constexpr`, expression SFINAE, and oth=
er C++11 features work (not to mention two-phase lookup which they still ha=
ven't done).<br><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div> </div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div d=
ir=3D"ltr">Consider something as simple as this:<br><div><br>named_statemen=
t stmt() =3D ({produce foo(thingy);});<br><br>So... what does the compiler =
do with `stmt`? What does that mean?</div></div></blockquote><div>Ok, I see=
your point much clearer now and I can assure you, I don't want the thi=
ngs you mentioned (neither in this proposal nor the next). I'm actually=
going for something much cleaner and lightweight with named SE; thus, I th=
ink I should rewrite this part. My plan is to make the above a compile-time=
error outright. The reason it's a compile-time error is that `foo'=
and `thingy' are not defined <i>at the point of definition</i>. If you=
want a named SE / parametric SE that has parameters called `foo' and `=
thingy' (as opposed to capture, which we normally do), you naturally ha=
ve to specify it (along with type) in the function argument list:<br><br><d=
iv style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187)=
;border-style:solid;border-width:1px"><code><div><span style=3D"color:#008"=
>template</span><span style=3D"color:#660"><</span><span style=3D"color:=
#008">typename</span><span style=3D"color:#000"> F</span><span style=3D"col=
or:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#0=
08">typename</span><span style=3D"color:#000"> T</span><span style=3D"color=
:#660">></span><span style=3D"color:#000"><br></span><span style=3D"colo=
r:#008">auto</span><span style=3D"color:#000"> namedstmt</span><span style=
=3D"color:#660">(</span><span style=3D"color:#000">F</span><span style=3D"c=
olor:#660">&&</span><span style=3D"color:#000"> foo</span><span sty=
le=3D"color:#660">,</span><span style=3D"color:#000"> T</span><span style=
=3D"color:#660">&&</span><span style=3D"color:#000"> thingy</span><=
span style=3D"color:#660">)</span><span style=3D"color:#000"><br></span><sp=
an style=3D"color:#800">/* -> decltype(foo(thingy)) */</span><span style=
=3D"color:#000"> // if needed<br></span><span style=3D"color:#660">({</span=
><span style=3D"color:#000"> produce foo</span><span style=3D"color:#660">(=
</span><span style=3D"color:#000">thingy</span><span style=3D"color:#660">)=
;</span><span style=3D"color:#000"> </span><span style=3D"color:#660">})</s=
pan><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</spa=
n><span style=3D"color:#000"><br><br></span><span style=3D"color:#008">auto=
</span><span style=3D"color:#000"> paramstmt</span><span style=3D"color:#66=
0"> =3D [&](</span><span style=3D"color:#008">auto</span><span style=3D=
"color:#660">&&</span><span style=3D"color:#000"> foo</span><span s=
tyle=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">auto</span><span style=3D"color:#660">&&</span><spa=
n style=3D"color:#000"> thingy</span><span style=3D"color:#660">)</span><sp=
an style=3D"color:#000"> </span><br><code><span style=3D"color:#800">/* -&g=
t; decltype(foo(thingy)) */ </span></code><code><span style=3D"color:#000">=
// if needed<br></span></code><span style=3D"color:#660">({</span><span sty=
le=3D"color:#000"> produce foo</span><span style=3D"color:#660">(</span><sp=
an style=3D"color:#000">thingy</span><span style=3D"color:#660">);</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">})</span><span =
style=3D"color:#000"><br></span></div></code></div><br></div></div></blockq=
uote><div><br>OK, so you don't actually want statement expressions. Wha=
t you want are a slightly modified of function that can magically invoke `r=
eturn/break/continue` into their calling contexts. Presumably through multi=
ple layers of such functions.<br><br>Because right now, that seems to be th=
e <i>only difference</i> between a named SE and a function.</div><br>You al=
so need to explain exactly what kind of error you get if `break` or `contin=
ue` isn't legal from the context in which a statement function is calle=
d.<br><br>I'm starting to agree with Viacheslav here. This is starting =
to seem very much like a modified form of exception handling. Essentially, =
you're saying `throw return value` or `throw break` or whatever. And th=
e compiler catches it at certain places and does that.<br></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/6818d534-e764-4ccf-ab05-bd4358cd1db9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6818d534-e764-4ccf-ab05-bd4358cd1db9=
%40isocpp.org</a>.<br />
------=_Part_427_1184142682.1486683746394--
------=_Part_426_945630055.1486683746393--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 9 Feb 2017 15:53:13 -0800 (PST)
Raw View
------=_Part_1475_122697966.1486684393808
Content-Type: multipart/alternative;
boundary="----=_Part_1476_1744197980.1486684393808"
------=_Part_1476_1744197980.1486684393808
Content-Type: text/plain; charset=UTF-8
On Thursday, February 9, 2017 at 5:00:36 PM UTC-5, szollos...@gmail.com
wrote:
>
> ...
>
> Hi,
>
> Now, the parametric stuff. The essence of that is a non-local transfer of
>> control from arbitrary functions. That is akin to exceptions, and, given
>> the story of noexcept, we have firmly established that we need means of
>> establishing hard guarantees of no non-local transfer of control. Now, if
>> we introduce another non-local transfer mechanism, we will also introduce
>> the same pile of problems that noexcept has dealt with.
>>
> My understanding is that the problem with exceptions is that a function
> (unless `noexcept()') can throw *anything*, therefore control might be
> taken to *any other* (outer) catch block *dynamically.*
>
No, that is a problem, not "the problem."
`noexcept` exists so that code can detect if certain operations are
guaranteed to be able to complete. And if they are, then more efficient
ways of doing them can be used based on that certainty.
> Neither of these three apply to any SE, not even to my other idea on the
> "capturing monads..." thread (`throw inline / catch inline'):
>
> - we can tell exactly which kind of control transfers can happen
> (because SE *source* must be visible, thus you see the captured
> control stmts);
> - at this point, only the caller is affected (in the "capturing
> monads..." thread this is different, but still the exact type -> catch is
> deducible compile-time or in IDE);
> - all of these bind compile-time, whereas exceptions (as of today)
> bind runtime, which is their greatest limiting factor.
>
> To put it another way, probably noone complained about a function that
> returns `std::variant<return_type, exception_types...>'. In fact, SE moves
> in this direction, as the variant is easily checked / delegated for
> visitation inside and the code logic is kept intact.
>
Java has proven that this is a bad idea. It's essentially forcibly checked
exceptions, where every layer of a function must either handle the
exception or explicitly name it as an exception that gets thrown. Just
because you put the "exception_types" in the function's return value
instead of its exception specification list does not change all of the
problems with such things.
So yes, people do complain about functions that return such nonsense.
`expected` is one thing. A giant variant with one good value and a bunch of
arbitrary errors is a function that, instead of using C++'s standard error
handling mechanism, has decided to make everyone else live with its
unwillingness to clean up its own dirt.
This is not a construct we want to proliferate in C++.
--
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/f1f41cdb-b956-4b38-888b-2fe7e98c828d%40isocpp.org.
------=_Part_1476_1744197980.1486684393808
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, February 9, 2017 at 5:00:36 PM UTC-5, szollos=
....@gmail.com 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">...<br><br>Hi,<br><br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div>Now, the parametric stuff. The essence of that is a non-l=
ocal transfer of control from arbitrary functions. That is akin to exceptio=
ns, and, given the story of noexcept, we have firmly established that we ne=
ed means of establishing hard guarantees of no non-local transfer of contro=
l. Now, if we introduce another non-local transfer mechanism, we will also =
introduce the same pile of problems that noexcept has dealt with.</div></di=
v></blockquote><div>My understanding is that the problem with exceptions is=
that a function (unless `noexcept()') can throw <i>anything</i>, there=
fore control might be taken to <i>any other</i> (outer) catch block <i>dyna=
mically.</i></div></div></blockquote><div><br>No, that is a problem, not &q=
uot;the problem."<br><br>`noexcept` exists so that code can detect if =
certain operations are guaranteed to be able to complete. And if they are, =
then more efficient ways of doing them can be used based on that certainty.=
<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div>Neither of these three apply to any SE, not even to my other idea o=
n the "capturing monads..." thread (`throw inline / catch inline&=
#39;):<br><ul><li>we can tell exactly which kind of control transfers can h=
appen (because SE <i>source</i> must be visible, thus you see the captured =
control stmts);</li><li>at this point, only the caller is affected (in the =
"capturing monads..." thread this is different, but still the exa=
ct type -> catch is deducible compile-time or in IDE);</li><li>all of th=
ese bind compile-time, whereas exceptions (as of today) bind runtime, which=
is their greatest limiting factor.</li></ul>To put it another way, probabl=
y noone complained about a function that returns `std::variant<return_ty=
pe, exception_types...>'. In fact, SE moves in this direction, as th=
e variant is easily checked /=20
delegated for visitation inside and the code logic is kept intact.</div></d=
iv></blockquote><div><br>Java has proven that this is a bad idea. It's =
essentially forcibly checked exceptions, where every layer of a function mu=
st either handle the exception or explicitly name it as an exception that g=
ets thrown. Just because you put the "exception_types" in the fun=
ction's return value instead of its exception specification list does n=
ot change all of the problems with such things.<br><br>So yes, people do co=
mplain about functions that return such nonsense. `expected` is one thing. =
A giant variant with one good value and a bunch of arbitrary errors is a fu=
nction that, instead of using C++'s standard error handling mechanism, =
has decided to make everyone else live with its unwillingness to clean up i=
ts own dirt.<br><br>This is not a construct we want to proliferate in C++.<=
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/f1f41cdb-b956-4b38-888b-2fe7e98c828d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f1f41cdb-b956-4b38-888b-2fe7e98c828d=
%40isocpp.org</a>.<br />
------=_Part_1476_1744197980.1486684393808--
------=_Part_1475_122697966.1486684393808--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 09 Feb 2017 17:35:21 -0800
Raw View
On quinta-feira, 9 de fevereiro de 2017 14:30:13 PST szollosi.lorand@gmail.com
wrote:
> Sir, that's indeed doable for simple types, but consider the following:
[cut]
> Do you really want to write the type it returns? If I were to, I'd
> duplicate the body and try find to the typos...
It's your choice. You can choose to write the actual type and know that the
lambda is being run, or you can look at the trailing end to see the ().
In my opinion, use of auto should be avoided, so that silly mistakes when
refactoring code don't change expected behaviour.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--
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/3823358.7r5abvSy4S%40tjmaciei-mobl1.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 9 Feb 2017 18:03:41 -0800 (PST)
Raw View
------=_Part_469_828195815.1486692221223
Content-Type: multipart/alternative;
boundary="----=_Part_470_1761459713.1486692221224"
------=_Part_470_1761459713.1486692221224
Content-Type: text/plain; charset=UTF-8
On Thursday, February 9, 2017 at 8:35:31 PM UTC-5, Thiago Macieira wrote:
>
> On quinta-feira, 9 de fevereiro de 2017 14:30:13 PST szollos...@gmail.com
> <javascript:>
> wrote:
> > Sir, that's indeed doable for simple types, but consider the following:
> [cut]
> > Do you really want to write the type it returns? If I were to, I'd
> > duplicate the body and try find to the typos...
>
> It's your choice. You can choose to write the actual type and know that
> the
> lambda is being run, or you can look at the trailing end to see the ().
>
Or we can just have a way to do complex forms of object initialization.
If we have a lot of people (ab)using lambdas to do object initialization
(and we do), that should be seen as a sign of a language deficiency.
In my opinion, use of auto should be avoided, so that silly mistakes when
> refactoring code don't change expected behaviour.
>
By that logic, we shouldn't have `auto` at all.
Does it *really* matter exactly what type gets returned? No. What matters
is *how you use that type*. Whether the object it creates fits the code
that uses it. Sure, people can make "silly mistakes" when refactoring with
`auto` use. But pervasive use of `auto` for complex types *also* means that
you get to change return types without breaking people's code.
After all, they don't care what object it returns; they care whether the
object can do what they're going to do with 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/55e0e012-105d-472e-8636-96c92a552424%40isocpp.org.
------=_Part_470_1761459713.1486692221224
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, February 9, 2017 at 8:35:31 PM UTC-5,=
Thiago Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On quin=
ta-feira, 9 de fevereiro de 2017 14:30:13 PST <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"USxB7IptAwAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.hr=
ef=3D'javascript:';return true;">szollos...@gmail.com</a>=20
<br>wrote:
<br>> =C2=A0Sir, that's indeed doable for simple types, but consider=
the following:
<br>[cut]
<br>> Do you really want to write the type it returns? If I were to, I&#=
39;d
<br>> duplicate the body and try find to the typos...
<br>
<br>It's your choice. You can choose to write the actual type and know =
that the=20
<br>lambda is being run, or you can look at the trailing end to see the ().=
<br></blockquote><div><br>Or we can just have a way to do complex forms of =
object initialization.<br><br>If we have a lot of people (ab)using lambdas =
to do object initialization (and we do), that should be seen as a sign of a=
language deficiency.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
In my opinion, use of auto should be avoided, so that silly mistakes when=
=20
<br>refactoring code don't change expected behaviour.<br></blockquote><=
div><br>By that logic, we shouldn't have `auto` at all.<br><br>Does it =
<i>really</i> matter exactly what type gets returned? No. What matters is <=
i>how you use that type</i>. Whether the object it creates fits the code th=
at uses it. Sure, people can make "silly mistakes" when refactori=
ng with `auto` use. But pervasive use of `auto` for complex types <i>also</=
i> means that you get to change return types without breaking people's =
code.<br><br>After all, they don't care what object it returns; they ca=
re whether the object can do what they're going to do with it.<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/55e0e012-105d-472e-8636-96c92a552424%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/55e0e012-105d-472e-8636-96c92a552424=
%40isocpp.org</a>.<br />
------=_Part_470_1761459713.1486692221224--
------=_Part_469_828195815.1486692221223--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 09 Feb 2017 21:37:08 -0800
Raw View
Em quinta-feira, 9 de fevereiro de 2017, =C3=A0s 18:03:41 PST, Nicol Bolas=
=20
escreveu:
> > In my opinion, use of auto should be avoided, so that silly mistakes wh=
en
> > refactoring code don't change expected behaviour.
>=20
> By that logic, we shouldn't have `auto` at all.
I said avoided, not eliminated. There are good uses for auto, especially wh=
en=20
the type is used on that same line (new and static_cast, for example).
That and iterators are the only allowed uses of auto in Qt source code.
> Does it *really* matter exactly what type gets returned? No. What matters
> is *how you use that type*. Whether the object it creates fits the code
> that uses it. Sure, people can make "silly mistakes" when refactoring wit=
h
> `auto` use. But pervasive use of `auto` for complex types *also* means th=
at
> you get to change return types without breaking people's code.
>=20
> After all, they don't care what object it returns; they care whether the
> object can do what they're going to do with it.
Sounds like a job for Concepts.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
--=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/6171749.ztcef90uDL%40tjmaciei-mobl1.
.
Author: szollosi.lorand@gmail.com
Date: Fri, 10 Feb 2017 01:01:05 -0800 (PST)
Raw View
------=_Part_521_1756245316.1486717265843
Content-Type: multipart/alternative;
boundary="----=_Part_522_2064096512.1486717265843"
------=_Part_522_2064096512.1486717265843
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi,
2017. febru=C3=A1r 10., p=C3=A9ntek 0:42:26 UTC+1 id=C5=91pontban Nicol Bol=
as a k=C3=B6vetkez=C5=91t=20
=C3=ADrta:
>
> `return/break/continue` into their calling contexts. Presumably through=
=20
> multiple layers of such functions.
>
There are no multiple layers. `return' inside a SE means return *from the=
=20
evaluating context*, not from the defining context.
=20
> You also need to explain exactly what kind of error you get if `break` or=
=20
> `continue` isn't legal from the context in which a statement function is=
=20
> called.
>
Compile-time diagnostic. At the point of call it can be decided if the=20
named / parametric SE can be called. Yes, I do want to make it a part of=20
the type of `operator()' (or whatever mechanics we'll use to switch to the=
=20
return / break / continue continuations passed after destructing the=20
current one).
Think of it this way: `return' in a SE does the following:
- cleanup (by SE): destruct automatic storage duration variables not needed=
=20
in the return statement
- delegated return: jump to the cleanup (and then, return) code of the=20
caller
If you can 'limit the scope of' (read: ensure destruction of) ASDVs=20
mentioned in cleanup (which the compiler can do) and have TCO, the second=
=20
could essentially be a `[[noreturn]]' function implemented by the compiler=
=20
in assembly. So we're specifying a `[[noreturn]]' function at the calling=
=20
point.
=20
> I'm starting to agree with Viacheslav here. This is starting to seem very=
=20
> much like a modified form of exception handling. Essentially, you're sayi=
ng=20
> `throw return value` or `throw break` or whatever. And the compiler catch=
es=20
> it at certain places and does that.
>
No, `throw' propagates through multiple 'stack frames' (yep, calling=20
contexts). This does not. This always return / break / etc. from the=20
caller.=20
Thanks,
-lorro
--=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/9e4ab8d2-b8a2-40d0-9942-bf9bbeee259b%40isocpp.or=
g.
------=_Part_522_2064096512.1486717265843
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>2017. febru=C3=A1r 10., p=C3=A9ntek 0:42:26 UTC=
+1 id=C5=91pontban Nicol Bolas a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=C2=A0`return/break/cont=
inue` into their calling contexts. Presumably through multiple layers of su=
ch functions.<br></div></blockquote><div>There are no multiple layers. `ret=
urn' inside a SE means return <i>from the evaluating context</i>, not f=
rom the defining context.<br>=C2=A0<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr">You also need to explain exactly what kind =
of error you get if `break` or `continue` isn't legal from the context =
in which a statement function is called.<br></div></blockquote><div>Compile=
-time diagnostic. At the point of call it can be decided if the named / par=
ametric SE can be called. Yes, I do want to make it a part of the type of `=
operator()' (or whatever mechanics we'll use to switch to the retur=
n / break / continue continuations passed after destructing the current one=
).<br>Think of it this way: `return' in a SE does the following:<br>- c=
leanup (by SE): destruct automatic storage duration variables not needed in=
the return statement<br>- delegated return: jump to the cleanup (and then,=
return) code of the caller<br>If you can 'limit the scope of' (rea=
d: ensure destruction of) ASDVs mentioned in cleanup (which the compiler ca=
n do) and have TCO, the second could essentially be a `[[noreturn]]' fu=
nction implemented by the compiler in assembly. So we're specifying a `=
[[noreturn]]' function at the calling point.<br></div><div>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I'm start=
ing to agree with Viacheslav here. This is starting to seem very much like =
a modified form of exception handling. Essentially, you're saying `thro=
w return value` or `throw break` or whatever. And the compiler catches it a=
t certain places and does that.<br></div></blockquote><div>No, `throw' =
propagates through multiple 'stack frames' (yep, calling contexts).=
This does not. This always return / break / etc. from the caller. <br><br>=
Thanks,<br>-lorro<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/9e4ab8d2-b8a2-40d0-9942-bf9bbeee259b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9e4ab8d2-b8a2-40d0-9942-bf9bbeee259b=
%40isocpp.org</a>.<br />
------=_Part_522_2064096512.1486717265843--
------=_Part_521_1756245316.1486717265843--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Fri, 10 Feb 2017 11:03:47 +0100
Raw View
--94eb2c065d98c8b5de05482a3629
Content-Type: text/plain; charset=UTF-8
On Thu, Feb 9, 2017 at 11:00 PM, <szollosi.lorand@gmail.com> wrote:
> My understanding is that the problem with exceptions is that a function
(unless `noexcept()') can throw *anything*, therefore control might be
taken to *any other* (outer) catch block *dynamically.*
For any code that calls a noexcept functor, it does not matter *where* the
control will be taken from. That code expects that the functor returns
normally, or the entire abstract machine gets terminated.
> we can tell exactly which kind of control transfers can happen (because
SE *source* must be visible, thus you see the captured control stmts);
False. The code calling a functor that is actually a PSE *has no idea* where
the control is transferred to. As I said just above, that code may well
expect that the control may not be transferred anywhere at all.
Your example used std::accumulate(). The latter definitely does not know
anything about your PSE and the context it was defined in,
Cheers,
V.
--
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/CAA7YVg1-Z3ZSsG9G9XU4zvgQWRwV8aQJ%3DiPDxDN9F7k-yRqhxw%40mail.gmail.com.
--94eb2c065d98c8b5de05482a3629
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Feb 9, 2017 at 11:00 PM, <span dir=3D"ltr"><<a href=3D"mailto:szoll=
osi.lorand@gmail.com" target=3D"_blank">szollosi.lorand@gmail.com</a>></=
span> wrote:<br><div><br></div><div>> My understanding is that the probl=
em with exceptions is that a function (unless `noexcept()') can throw <=
i>anything</i>, therefore control might be taken to <i>any other</i> (outer=
) catch block <i>dynamically.</i></div><div><br></div><div>For any code tha=
t calls a noexcept functor, it does not matter <i>where</i>=C2=A0the contro=
l will be taken from. That code expects that the functor returns normally, =
or the entire abstract machine gets terminated.</div><div><br></div><div>&g=
t; we can tell exactly which kind of control transfers can happen (because =
SE <i>source</i> must be visible, thus you see the captured control stmts);=
</div><div><br></div><div>False. The code calling a functor that is actuall=
y a PSE <i>has no idea</i>=C2=A0where the control is transferred to. As I s=
aid just above, that code may well expect that the control may not be trans=
ferred anywhere at all.</div><div><br></div><div>Your example used std::acc=
umulate(). The latter definitely does not know anything about your PSE and =
the context it was defined in,</div><div><br></div><div>Cheers,</div><div>V=
..</div></div></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/CAA7YVg1-Z3ZSsG9G9XU4zvgQWRwV8aQJ%3Di=
PDxDN9F7k-yRqhxw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1-Z3ZSsG=
9G9XU4zvgQWRwV8aQJ%3DiPDxDN9F7k-yRqhxw%40mail.gmail.com</a>.<br />
--94eb2c065d98c8b5de05482a3629--
.
Author: Vittorio Romeo <vittorio.romeo.vee@gmail.com>
Date: Fri, 10 Feb 2017 06:54:19 -0800 (PST)
Raw View
------=_Part_710_578074581.1486738459395
Content-Type: multipart/alternative;
boundary="----=_Part_711_1723111503.1486738459396"
------=_Part_711_1723111503.1486738459396
Content-Type: text/plain; charset=UTF-8
Just wanted to say that I really really like this proposal. I feel like
that there's way too much syntactical overhead when dealing with
perfectly-forwarded captures and trailing return types (as seen in the
`curry` example). Hopefully you'll submit it and it will be well-received.
On Tuesday, 7 February 2017 01:57:56 UTC, szollos...@gmail.com wrote:
>
> Hi,
>
> Please find below the initial draft for a statement expression proposal.
> Any ideas, hints, suggestions are welcome. I understand that it's my first
> proposal and it might take several iterations if ever to make if fly, so
> I'd be very glad about points where I could make it better (one of them is
> formatting, which I'm going to fix); whether to add more detail or less;
> whether to change examples.
>
> Link to the proposal's initial draft:
> http://lorro.hu/cplusplus/statement_expressions.html
>
> Thanks in advance,
> -lorro
>
--
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/fc4f3ec5-f7be-4a08-bb23-b6f157cfe24f%40isocpp.org.
------=_Part_711_1723111503.1486738459396
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Just wanted to say that I really really like this proposal=
.. I feel like that there's way too much syntactical overhead when deali=
ng with perfectly-forwarded captures and trailing return types (as seen in =
the `curry` example). Hopefully you'll submit it and it will be well-re=
ceived.<br><br>On Tuesday, 7 February 2017 01:57:56 UTC, szollos...@gmail.c=
om wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hi,=
<br><br>Please find below the initial draft for a statement expression prop=
osal. Any ideas, hints, suggestions are welcome. I understand that it's=
my first proposal and it might take several iterations if ever to make if =
fly, so I'd be very glad about points where I could make it better (one=
of them is formatting, which I'm going to fix); whether to add more de=
tail or less; whether to change examples.<br><br>Link to the proposal's=
initial draft:<br><a href=3D"http://lorro.hu/cplusplus/statement_expressio=
ns.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
;http://www.google.com/url?q\x3dhttp%3A%2F%2Florro.hu%2Fcplusplus%2Fstateme=
nt_expressions.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHLZIb6auYtRyI2y=
unCdZC9m0_UdA';return true;" onclick=3D"this.href=3D'http://www.goo=
gle.com/url?q\x3dhttp%3A%2F%2Florro.hu%2Fcplusplus%2Fstatement_expressions.=
html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHLZIb6auYtRyI2yunCdZC9m0_UdA&#=
39;;return true;">http://lorro.hu/cplusplus/<wbr>statement_expressions.html=
</a><br><br>Thanks in advance,<br>-lorro<br></div></blockquote></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/fc4f3ec5-f7be-4a08-bb23-b6f157cfe24f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fc4f3ec5-f7be-4a08-bb23-b6f157cfe24f=
%40isocpp.org</a>.<br />
------=_Part_711_1723111503.1486738459396--
------=_Part_710_578074581.1486738459395--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 10 Feb 2017 07:33:48 -0800 (PST)
Raw View
------=_Part_749_1489553341.1486740828193
Content-Type: multipart/alternative;
boundary="----=_Part_750_1212476205.1486740828193"
------=_Part_750_1212476205.1486740828193
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, February 10, 2017 at 4:01:06 AM UTC-5, szollos...@gmail.com=20
wrote:
>
> Hi,
>
> 2017. febru=C3=A1r 10., p=C3=A9ntek 0:42:26 UTC+1 id=C5=91pontban Nicol B=
olas a=20
> k=C3=B6vetkez=C5=91t =C3=ADrta:
>>
>> `return/break/continue` into their calling contexts. Presumably through=
=20
>> multiple layers of such functions.
>>
> There are no multiple layers. `return' inside a SE means return *from the=
=20
> evaluating context*, not from the defining context.
>
And where exactly is that? If you call a named statement, and that named=20
statement does a `for` loop in which it calls another named statement, then=
=20
the inner statement ought to be able to `break` from the outer named=20
statement, not into the ultimate calling function. So there very much are=
=20
stack frames here.
Stack frames of named statements.
If the inner statement issues a `return`, then it must terminate both the=
=20
inner and outer named statements. Exactly like exception handling.
Thus far, the only differences between this and exceptions are:
1: Presumably, named statements have to be defined where they are declared.=
=20
That is, they're always inline.
2: Presumably, named statements have no function pointer analog; you can't=
=20
pass them around and so forth. This makes the resolution of their control=
=20
structures a static property of the code.
It should also be noted that your focus on named statements removes much of=
=20
the purpose of in-function statement expressions. If a SE cannot access=20
stuff in the function it is defined within, then you can't really use it=20
for complex object initialization.
So it seems that there are two *separate* features: named statements and=20
statement expressions. They might share some syntactic elements, but they=
=20
really do need to act like distinct constructs.
--=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/68cf17ed-2bce-4346-af50-30a59c1852f7%40isocpp.or=
g.
------=_Part_750_1212476205.1486740828193
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, February 10, 2017 at 4:01:06 AM UTC-5, szollos.=
...@gmail.com 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">Hi,<br><br>2017. febru=C3=A1r 10., p=C3=A9ntek 0:42:26 UTC+1 id=C5=91=
pontban Nicol Bolas a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">=C2=A0`return/break/continue` into their=
calling contexts. Presumably through multiple layers of such functions.<br=
></div></blockquote><div>There are no multiple layers. `return' inside =
a SE means return <i>from the evaluating context</i>, not from the defining=
context.<br></div></div></blockquote><div><br>And where exactly is that? I=
f you call a named statement, and that named statement does a `for`=20
loop in which it calls another named statement, then the inner statement
ought to be able to `break` from the outer named statement, not into=20
the ultimate calling function. So there very much are stack frames here.<br=
><br>Stack frames of named statements.<br><br>If the inner statement issues=
a `return`, then it must terminate both the inner and outer named statemen=
ts. Exactly like exception handling.<br><br>Thus far, the only differences =
between this and exceptions are:<br><br>1: Presumably, named statements hav=
e to be defined where they are declared. That is, they're always inline=
..<br><br>2: Presumably, named statements have no function pointer analog; y=
ou can't pass them around and so forth. This makes the resolution of th=
eir control structures a static property of the code.<br><br>It should also=
be noted that your focus on named statements removes much of the purpose o=
f in-function statement expressions. If a SE cannot access stuff in the fun=
ction it is defined within, then you can't really use it for complex ob=
ject initialization.<br><br>So it seems that there are two <i>separate</i> =
features: named statements and statement expressions. They might share some=
syntactic elements, but they really do need to act like distinct construct=
s.<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/68cf17ed-2bce-4346-af50-30a59c1852f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/68cf17ed-2bce-4346-af50-30a59c1852f7=
%40isocpp.org</a>.<br />
------=_Part_750_1212476205.1486740828193--
------=_Part_749_1489553341.1486740828193--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 10 Feb 2017 07:43:03 -0800 (PST)
Raw View
------=_Part_699_1582419551.1486741383617
Content-Type: multipart/alternative;
boundary="----=_Part_700_238848190.1486741383618"
------=_Part_700_238848190.1486741383618
Content-Type: text/plain; charset=UTF-8
On Friday, February 10, 2017 at 5:03:50 AM UTC-5, Viacheslav Usov wrote:
>
> On Thu, Feb 9, 2017 at 11:00 PM, <szollos...@gmail.com <javascript:>>
> wrote:
> > we can tell exactly which kind of control transfers can happen (because
> SE *source* must be visible, thus you see the captured control stmts);
>
> False. The code calling a functor that is actually a PSE *has no idea* where
> the control is transferred to. As I said just above, that code may well
> expect that the control may not be transferred anywhere at all.
>
> Your example used std::accumulate(). The latter definitely does not know
> anything about your PSE and the context it was defined in,
>
That's a good point. The example in the proposal is this (preserved in case
it gets changed):
template<typename R>
int product_of_range(const R& r)
{
return std::accumulate(begin(r), end(r), 1, [&](int lhs, int rhs) ({
if (rhs == 0) return 0;
lhs * rhs;
}));
}
This code strongly suggests that you can *force* another function to
execute a statement expression. That is, the functor passed to `accumulate`
isn't a lambda; it's a statement expression object of some kind.
Once you can pass a statement expression around, once you can make a
function execute a statement expression without *knowing* that it is doing
so, you lose the static ability to determine what's going on in your code.
Not to mention the potential behavior with regard to return type deduction.
If a parameter to a function can affect return type deduction (by issuing a
return from a statement expression early), then figuring out what the
function's return type will be becomes untenable. It's bad enough having to
scan through a function to work out its return type.
Which of course gives us the possibility of a named statement passed to a
function *hijacking* a function's return type. That is, using the rules of
return type deduction to force it to return a different-yet-compatible
type. That could break all kinds of stuff.
So passing around named statements and invoking them like functions? No.
--
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/addf8837-e018-44f4-8643-39baf70f976b%40isocpp.org.
------=_Part_700_238848190.1486741383618
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, February 10, 2017 at 5:03:50 AM UTC-5, Viachesl=
av Usov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote">On Thu, Feb 9, 2017 at 11:00 PM, <span di=
r=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"kqz0z0eJAwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javasc=
ript:';return true;" onclick=3D"this.href=3D'javascript:';retur=
n true;">szollos...@gmail.com</a>></span> wrote:<div>> we can tell ex=
actly which kind of control transfers can happen (because SE <i>source</i> =
must be visible, thus you see the captured control stmts);</div><div><br></=
div><div>False. The code calling a functor that is actually a PSE <i>has no=
idea</i>=C2=A0where the control is transferred to. As I said just above, t=
hat code may well expect that the control may not be transferred anywhere a=
t all.</div><div><br></div><div>Your example used std::accumulate(). The la=
tter definitely does not know anything about your PSE and the context it wa=
s defined in,</div></div></div></div></blockquote><div><br>That's a goo=
d point. The example in the proposal is this (preserved in case it gets cha=
nged):<br><br><div style=3D"background-color: rgb(250, 250, 250); border-co=
lor: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-w=
rap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">template</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy"><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">ty=
pename</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> R</=
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 s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> product_of_range</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> R</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> r</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =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"> st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">accumulate</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">begin</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">r</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">),</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">end</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">r</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">),</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #066;" class=3D"styled-by-prettify">1</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">[&](</span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> lhs</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> rhs</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">({</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">if</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"style=
d-by-prettify">rhs </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 lhs </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> rhs</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}));</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">}</span></div></code></div><br>This code strongly suggests tha=
t you can <i>force</i> another function to execute a statement expression. =
That is, the functor passed to `accumulate` isn't a lambda; it's a =
statement expression object of some kind.<br><br>Once you can pass a statem=
ent expression around, once you can make a function execute a statement exp=
ression without <i>knowing</i> that it is doing so, you lose the static abi=
lity to determine what's going on in your code.<br><br>Not to mention t=
he potential behavior with regard to return type deduction. If a parameter =
to a function can affect return type deduction (by issuing a return from a =
statement expression early), then figuring out what the function's retu=
rn type will be becomes untenable. It's bad enough having to scan throu=
gh a function to work out its return type.<br><br>Which of course gives us =
the possibility of a named statement passed to a function <i>hijacking</i> =
a function's return type. That is, using the rules of return type deduc=
tion to force it to return a different-yet-compatible type. That could brea=
k all kinds of stuff.<br><br>So passing around named statements and invokin=
g them like functions? No.<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/addf8837-e018-44f4-8643-39baf70f976b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/addf8837-e018-44f4-8643-39baf70f976b=
%40isocpp.org</a>.<br />
------=_Part_700_238848190.1486741383618--
------=_Part_699_1582419551.1486741383617--
.
Author: Barry Revzin <barry.revzin@gmail.com>
Date: Fri, 10 Feb 2017 15:49:40 +0000
Raw View
--001a114f1e545a171705482f0cce
Content-Type: text/plain; charset=UTF-8
On Fri, Feb 10, 2017, 8:54 AM Vittorio Romeo <vittorio.romeo.vee@gmail.com>
wrote:
> Just wanted to say that I really really like this proposal. I feel like
> that there's way too much syntactical overhead when dealing with
> perfectly-forwarded captures and trailing return types (as seen in the
> `curry` example). Hopefully you'll submit it and it will be well-received.
>
This was meant to be a reply to my proposal right? The abbreviated lambda
syntax one? I saw your curry blog post and figured it'd make for a great
before-and-after example.
I can't make it to Kona but will hopefully present it in Toronto. I also
want to revamp my pointers-to-member proposal because I think std::invoke
is kind of miserable. And then curry() becomes even shorter and even more
readable.
Barry
--
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/CACS8nvca33X_jiu1K36YSoh0RbtmgLQ1YtFOoZ6p%3D3%3Djy06UbA%40mail.gmail.com.
--001a114f1e545a171705482f0cce
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Feb 10, 2017, 8=
:54 AM Vittorio Romeo <<a href=3D"mailto:vittorio.romeo.vee@gmail.com">v=
ittorio.romeo.vee@gmail.com</a>> wrote:<br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr" class=3D"gmail_msg">Just wanted to say that I real=
ly really like this proposal. I feel like that there's way too much syn=
tactical overhead when dealing with perfectly-forwarded captures and traili=
ng return types (as seen in the `curry` example). Hopefully you'll subm=
it it and it will be well-received.</div><div dir=3D"ltr" class=3D"gmail_ms=
g"></div></blockquote></div><div class=3D"gmail_quote"><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr" class=3D"gmail_msg"></div></blockquote></div><d=
iv><br></div><div>This was meant to be a reply to my proposal right? The ab=
breviated lambda syntax one?=C2=A0<span style=3D"font-size:13px">I saw your=
curry blog post and figured it'd make for a great before-and-after exa=
mple.=C2=A0</span></div><div><span style=3D"font-size:13px"><br></span></di=
v><div><span style=3D"font-size:13px">I can't make it to Kona but will =
hopefully present it in Toronto. I also want to revamp my pointers-to-membe=
r proposal because I think std::invoke is kind of miserable. And then curry=
() becomes even shorter and even more readable.</span></div><div><br></div>=
<div>Barry</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/CACS8nvca33X_jiu1K36YSoh0RbtmgLQ1YtFO=
oZ6p%3D3%3Djy06UbA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACS8nvca33X_=
jiu1K36YSoh0RbtmgLQ1YtFOoZ6p%3D3%3Djy06UbA%40mail.gmail.com</a>.<br />
--001a114f1e545a171705482f0cce--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 10 Feb 2017 08:00:16 -0800 (PST)
Raw View
------=_Part_738_1203488299.1486742416549
Content-Type: multipart/alternative;
boundary="----=_Part_739_514154703.1486742416549"
------=_Part_739_514154703.1486742416549
Content-Type: text/plain; charset=UTF-8
On Friday, February 10, 2017 at 10:43:03 AM UTC-5, Nicol Bolas wrote:
>
> On Friday, February 10, 2017 at 5:03:50 AM UTC-5, Viacheslav Usov wrote:
>>
>> On Thu, Feb 9, 2017 at 11:00 PM, <szollos...@gmail.com> wrote:
>> > we can tell exactly which kind of control transfers can happen (because
>> SE *source* must be visible, thus you see the captured control stmts);
>>
>> False. The code calling a functor that is actually a PSE *has no idea* where
>> the control is transferred to. As I said just above, that code may well
>> expect that the control may not be transferred anywhere at all.
>>
>> Your example used std::accumulate(). The latter definitely does not know
>> anything about your PSE and the context it was defined in,
>>
>
> That's a good point. The example in the proposal is this (preserved in
> case it gets changed):
>
> template<typename R>
> int product_of_range(const R& r)
> {
> return std::accumulate(begin(r), end(r), 1, [&](int lhs, int rhs) ({
> if (rhs == 0) return 0;
> lhs * rhs;
> }));
> }
>
> This code strongly suggests that you can *force* another function to
> execute a statement expression. That is, the functor passed to `accumulate`
> isn't a lambda; it's a statement expression object of some kind.
>
> Once you can pass a statement expression around, once you can make a
> function execute a statement expression without *knowing* that it is
> doing so, you lose the static ability to determine what's going on in your
> code.
>
> Not to mention the potential behavior with regard to return type
> deduction. If a parameter to a function can affect return type deduction
> (by issuing a return from a statement expression early), then figuring out
> what the function's return type will be becomes untenable. It's bad enough
> having to scan through a function to work out its return type.
>
> Which of course gives us the possibility of a named statement passed to a
> function *hijacking* a function's return type. That is, using the rules
> of return type deduction to force it to return a different-yet-compatible
> type. That could break all kinds of stuff.
>
> So passing around named statements and invoking them like functions? No.
>
Not to mention, `std::accumulate` itself doesn't have to directly call the
functor. It can call a sub-function which calls the functor. Or a
sub-function of a sub-function calls the functor. It may even have an
internal lambda that does the calling. Who knows?
The only way to make that named statement behave the way you want it to
(terminate `std::accumulate` itself, forcing it to `return 0`) is to
effectively link the named statement to `std::accumulate`. But even if that
were possible, you would *still* have to deal with the fact that you're
returning through all of those potential sub-functions.
So now we have a stack frame that contains actual functions, not just
statement expressions. So how exactly is this different from an exception?
--
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/9125cc7d-a7a9-4cee-844f-92a24ea650e3%40isocpp.org.
------=_Part_739_514154703.1486742416549
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, February 10, 2017 at 10:43:03 AM UTC-5, Nicol B=
olas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On=
Friday, February 10, 2017 at 5:03:50 AM UTC-5, Viacheslav Usov wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmai=
l_quote">On Thu, Feb 9, 2017 at 11:00 PM, <span dir=3D"ltr"><<a rel=3D"=
nofollow">szollos...@gmail.com</a>></span> wrote:<div>> we can tell e=
xactly which kind of control transfers can happen (because SE <i>source</i>=
must be visible, thus you see the captured control stmts);</div><div><br><=
/div><div>False. The code calling a functor that is actually a PSE <i>has n=
o idea</i>=C2=A0where the control is transferred to. As I said just above, =
that code may well expect that the control may not be transferred anywhere =
at all.</div><div><br></div><div>Your example used std::accumulate(). The l=
atter definitely does not know anything about your PSE and the context it w=
as defined in,</div></div></div></div></blockquote><div><br>That's a go=
od point. The example in the proposal is this (preserved in case it gets ch=
anged):<br><br><div style=3D"background-color:rgb(250,250,250);border-color=
:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><span sty=
le=3D"color:#008">template</span><span style=3D"color:#660"><</span><spa=
n style=3D"color:#008">typename</span><span style=3D"color:#000"> R</span><=
span style=3D"color:#660">></span><span style=3D"color:#000"><br></span>=
<span style=3D"color:#008">int</span><span style=3D"color:#000"> product_of=
_range</span><span style=3D"color:#660">(</span><span style=3D"color:#008">=
const</span><span style=3D"color:#000"> R</span><span style=3D"color:#660">=
&</span><span style=3D"color:#000"> r</span><span style=3D"color:#660">=
)</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">{<=
/span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"co=
lor:#008">return</span><span style=3D"color:#000"> std</span><span style=3D=
"color:#660">::</span><span style=3D"color:#000">accumulate</span><span sty=
le=3D"color:#660">(</span><span style=3D"color:#008">begin</span><span styl=
e=3D"color:#660">(</span><span style=3D"color:#000">r</span><span style=3D"=
color:#660">),</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#008">end</span><span style=3D"color:#660">(</span><span style=3D"color:#=
000">r</span><span style=3D"color:#660">),</span><span style=3D"color:#000"=
> </span><span style=3D"color:#066">1</span><span style=3D"color:#660">,</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">[&](<=
/span><span style=3D"color:#008">int</span><span style=3D"color:#000"> lhs<=
/span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span=
><span style=3D"color:#008">int</span><span style=3D"color:#000"> rhs</span=
><span style=3D"color:#660">)</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">({</span><span style=3D"color:#000"><br>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008">if</span><span style=3D=
"color:#000"> </span><span style=3D"color:#660">(</span><span style=3D"colo=
r:#000">rhs </span><span style=3D"color:#660">=3D=3D</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#066">0</span><span style=3D"color:=
#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:#008"=
>return</span><span style=3D"color:#000"> </span><span style=3D"color:#066"=
>0</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 lhs </span><span style=3D"color:#660">*</span><=
span style=3D"color:#000"> rhs</span><span style=3D"color:#660">;</span><sp=
an style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660"=
>}));</span><span style=3D"color:#000"><br></span><span style=3D"color:#660=
">}</span></div></code></div><br>This code strongly suggests that you can <=
i>force</i> another function to execute a statement expression. That is, th=
e functor passed to `accumulate` isn't a lambda; it's a statement e=
xpression object of some kind.<br><br>Once you can pass a statement express=
ion around, once you can make a function execute a statement expression wit=
hout <i>knowing</i> that it is doing so, you lose the static ability to det=
ermine what's going on in your code.<br><br>Not to mention the potentia=
l behavior with regard to return type deduction. If a parameter to a functi=
on can affect return type deduction (by issuing a return from a statement e=
xpression early), then figuring out what the function's return type wil=
l be becomes untenable. It's bad enough having to scan through a functi=
on to work out its return type.<br><br>Which of course gives us the possibi=
lity of a named statement passed to a function <i>hijacking</i> a function&=
#39;s return type. That is, using the rules of return type deduction to for=
ce it to return a different-yet-compatible type. That could break all kinds=
of stuff.<br><br>So passing around named statements and invoking them like=
functions? No.<br></div></div></blockquote><div><br>Not to mention, `std::=
accumulate` itself doesn't have to directly call the functor. It can ca=
ll a sub-function which calls the functor. Or a sub-function of a sub-funct=
ion calls the functor. It may even have an internal lambda that does the ca=
lling. Who knows?<br><br>The only way to make that named statement behave t=
he way you want it to (terminate `std::accumulate` itself, forcing it to `r=
eturn 0`) is to effectively link the named statement to `std::accumulate`. =
But even if that were possible, you would <i>still</i> have to deal with th=
e fact that you're returning through all of those potential sub-functio=
ns.<br><br>So now we have a stack frame that contains actual functions, not=
just statement expressions. So how exactly is this different from an excep=
tion?<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/9125cc7d-a7a9-4cee-844f-92a24ea650e3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9125cc7d-a7a9-4cee-844f-92a24ea650e3=
%40isocpp.org</a>.<br />
------=_Part_739_514154703.1486742416549--
------=_Part_738_1203488299.1486742416549--
.
Author: szollosi.lorand@gmail.com
Date: Sun, 12 Feb 2017 13:47:36 -0800 (PST)
Raw View
------=_Part_1112_399646855.1486936056360
Content-Type: multipart/alternative;
boundary="----=_Part_1113_2138160733.1486936056361"
------=_Part_1113_2138160733.1486936056361
Content-Type: text/plain; charset=UTF-8
Hi,
Thanks again for the feedback.
*Viacheslav Usov> The code calling a functor that is actually a PSE has no
idea where the control is transferred to. As I said just above, that code
may well expect that the control may not be transferred anywhere at all.*
Currently we don't have noexcept for PSEs and it's not clear what it'd mean
to have that, given you consider non-local transfer as an exception from
this point-of-view.. If you have a *function* that calls a *PSE* that calls
a *PSE*, then we have the guarantee that (unless by an actual throw) both
the inner and the outer PSE can at most cause the outer function to return.
Therefore I think that the function might still be noexcept. This is
different from an exception which might propagate outside that function.
*Viacheslav Usov> Your example used std::accumulate(). The latter
definitely does not know anything about your PSE and the context it was
defined in,*It does not know the context, similarly that it does not know
the context of a lambda. std::accumulate() accepts a template type. That
template type has a (possibly new kind of) *template *operator(), which is
resolved in std:accumulate() automatically by its `return'. Thus it does
know about my PSE, at least to the level that it knows that it has to
resolve the template return. Naturally this also means that PSEs are inline.
*Nicol Bolas> If you call a named statement, and that named statement does
a `for` loop in which it calls another named statement, then the inner
statement ought to be able to `break` from the outer named statement, not
into the ultimate calling function. So there very much are stack frames
here.*This is the same for SE, PSE and NSE. Stack frames are
implementation, not standard, therefore - so far - I've tried to avoid them
in the explanation. If it's easier to discuss in terms of implementations,
then a function / functor receives an implicit return continuation (=return
address) on the stack; a PSE might receive up to a return, break, continue
and produce continuation. I do look at normal SEs as function-like objects
that take these - this might be a difference in our p.o.v. - i.e., in my
model *any* SE is CALLed and uses RET for returning. Then the optimizer can
remove these if unnecessary. But that's just implementation.
*Nicol Bolas> If the inner statement issues a `return`, then it must
terminate both the inner and outer named statements. Exactly like exception
handling.*Not exactly: the exception might propagate out of any number of
functions. Inline return propagates only to the caller of the function that
called the SE/PSE/NSE. Thus a caling *function* can still be noexcept, even
if we consider non-local return as an exception-like entity *from the PSE*.
It might be exception-like from that point, but from the calling *function*,
it's a normal return (with the same return type). So I wouldn't consider
that as breaking the noexcept contract: the PSE-calling function's *caller*
will continue and can't distinguish (if not by value) if the callee or the
inner PSE returned.
*Nicol Bolas> If a SE cannot access stuff in the function it is defined
within, then you can't really use it for complex object initialization.*A
PSE can. Granted, dangling references or even UB might occur if you somehow
return such a PSE outside the context of captures; but the same happens
with lambdas. If I don't understand you correctly, could you please help me
understand what's missing?
*Nicol Bolas> This code strongly suggests that you can force another
function to execute a statement expression. That is, the functor passed to
`accumulate` isn't a lambda; it's a statement expression object of some
kind.*Yep, in my model it's passed similarly as a lambda (Note: I say
'passed', not 'called'). Sorry that I took this evident, that's one more
point I should explain in the text. To me, a PSE is defined at a point
(where it might have captures, but it doesn't capture continuations there);
then it can be passed around as an object of a specific type. It's
presumably non-copiable, it *might* be movable. It has a *template*
operator(), which is special. Had `return' (and the other control flow
statements) been a [[noreturn]] functor, it might have been just an
ordinary template parameter. Since it's not (and since we want auto-resolve
to avoid ugly syntax), it's *part of* the template specification, but *not*
a type parameter. This is similar to `...' being part of the argument list,
but not being a function argument. Thus it can only be resolved in a
context where that given keyword is actually allowed. Technical
implementation might require a stack frame - or just inlining.
*Nicol Bolas> Once you can pass a statement expression around, once you can
make a function execute a statement expression without knowing that it is
doing so*
Good point. If you think it's preferable, I might come up with a solution
to detect if `T' is a PSE/NSE. Note however that you (or your compiler)
still have the static ability to decide what's going on: all PSEs/NSEs must
be inlined and can't be hidden in a library or behind a virtual ptr.
*Nicol Bolas> Not to mention the potential behavior with regard to return
type deduction. If a parameter to a function can affect return type
deduction (by issuing a return from a statement expression early), then
figuring out what the function's return type will be becomes untenable*I
understand your concern, but in my model it works the other way around.
Assume a function f calling a PSE e. Then the return type of f is decided
first (name it RET); then the compiler, at each point of call with args...,
tries decltype(e)::operator<RET>()(args...). If it's invalid, then that's a
compile-time error. Thus you can't have a PSE that produces int but might
return nullopt in a function that would otherwise (read: w/o the PSE's
`return') return int. Return types are not affected - not conforming them
means invalid code.
*Nicol Bolas> Not to mention, `std::accumulate` itself doesn't have to
directly call the functor. It can call a sub-function which calls the
functor. Or a sub-function of a sub-function calls the functor. It may even
have an internal lambda that does the calling. Who knows?*
Specification. I'm okay with any number of nestings in `std::accumulate' as
long as returning from the innermost nest allows me to have identical
behaviour as the flat version. In other words, a PSE can only be used if
you have (valid, specified) assumptions about the internals of the function
you call. If you don't, you don't pass a PSE. It's just a feature. It's
useful when you're responsible for both the function and the PSE (which is
very oft) or when there's a clear specification of what early return does.
Note that you need to have specifications about how your lambda is called
as well.
If you wanted the other kind of guarantee, namely across several function
calls, then I'm considering inline catch as a separate proposal (which is
akin to take_return in the other thread; that *is* an exception, albeit a
quick one, resolved in compile-time, but still non-local).
Thanks,
-lorro
--
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/620c7221-1b6e-44bf-82cb-83bd4ac69e05%40isocpp.org.
------=_Part_1113_2138160733.1486936056361
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>Thanks again for the feedback.<br><br><i><b><sp=
an class=3D"_username"><span class=3D"IVILX2C-D-a" style=3D"color: rgb(34, =
34, 34);">Viacheslav Usov> </span></span>The code calling a functor that=
is actually a PSE has no idea=C2=A0where
the control is transferred to. As I said just above, that code may well
expect that the control may not be transferred anywhere at all.</b></i><br=
><br>Currently we don't have noexcept for PSEs and it's not clear w=
hat it'd mean to have that, given you consider non-local transfer as an=
exception from this point-of-view.. If you have a <i>function</i> that cal=
ls a <i>PSE</i> that calls a <i>PSE</i>, then we have the guarantee that (u=
nless by an actual throw) both the inner and the outer PSE can at most caus=
e the outer function to return. Therefore I think that the function might s=
till be noexcept. This is different from an exception which might propagate=
outside that function.<br><br><i><b><span class=3D"_username"><span class=
=3D"IVILX2C-D-a" style=3D"color: rgb(34, 34, 34);">Viacheslav Usov> </sp=
an></span>Your example used std::accumulate(). The latter definitely does n=
ot know
anything about your PSE and the context it was defined in,</b><b><br><br><=
/b></i>It does not know the context, similarly that it does not know the co=
ntext of a lambda. std::accumulate() accepts a template type. That template=
type has a (possibly new kind of) <i>template </i>operator(), which is res=
olved in std:accumulate() automatically by its `return'. Thus it does k=
now about my PSE, at least to the level that it knows that it has to resolv=
e the template return. Naturally this also means that PSEs are inline.<br><=
br><i><b>Nicol Bolas> If you call a named statement, and that named stat=
ement does a `for`=20
loop in which it calls another named statement, then the inner statement
ought to be able to `break` from the outer named statement, not into=20
the ultimate calling function. So there very much are stack frames here.<br=
><br></b></i>This is the same for SE, PSE and NSE. Stack frames are impleme=
ntation, not standard, therefore - so far - I've tried to avoid them in=
the explanation. If it's easier to discuss in terms of implementations=
, then a function / functor receives an implicit return continuation (=3Dre=
turn address) on the stack; a PSE might receive up to a return, break, cont=
inue and produce continuation. I do look at normal SEs as function-like obj=
ects that take these - this might be a difference in our p.o.v. - i.e., in =
my model <i>any</i> SE is CALLed and uses RET for returning. Then the optim=
izer can remove these if unnecessary. But that's just implementation.<b=
r><br><i><b>Nicol Bolas> If the inner statement issues a `return`, then =
it must terminate both=20
the inner and outer named statements. Exactly like exception handling.<br><=
br></b></i>Not exactly: the exception might propagate out of any number of =
functions. Inline return propagates only to the caller of the function that=
called the SE/PSE/NSE. Thus a caling <i>function</i> can still be noexcept=
, even if we consider non-local return as an exception-like entity <i>from =
the PSE</i>. It might be exception-like from that point, but from the calli=
ng <i>function</i>, it's a normal return (with the same return type). S=
o I wouldn't consider that as breaking the noexcept contract: the PSE-c=
alling function's <i>caller</i> will continue and can't distinguish=
(if not by value) if the callee or the inner PSE returned.<br><br><i><b>Ni=
col Bolas> If a SE cannot access stuff in the function it is defined wit=
hin, then=20
you can't really use it for complex object initialization.<br><br></b><=
/i>A PSE can. Granted, dangling references or even UB might occur if you so=
mehow return such a PSE outside the context of captures; but the same happe=
ns with lambdas. If I don't understand you correctly, could you please =
help me understand what's missing?<br><br><i><b>Nicol Bolas> This co=
de strongly suggests that you can force another=20
function to execute a statement expression. That is, the functor passed=20
to `accumulate` isn't a lambda; it's a statement expression object =
of=20
some kind.<br><br></b></i>Yep, in my model it's passed similarly as a l=
ambda (Note: I say 'passed', not 'called'). Sorry that I to=
ok this evident, that's one more point I should explain in the text. To=
me, a PSE is defined at a point (where it might have captures, but it does=
n't capture continuations there); then it can be passed around as an ob=
ject of a specific type. It's presumably non-copiable, it <i>might</i> =
be movable. It has a <i>template</i> operator(), which is special. Had `ret=
urn' (and the other control flow statements) been a [[noreturn]] functo=
r, it might have been just an ordinary template parameter. Since it's n=
ot (and since we want auto-resolve to avoid ugly syntax), it's <i>part =
of</i> the template specification, but <i>not</i> a type parameter. This is=
similar to `...' being part of the argument list, but not being a func=
tion argument. Thus it can only be resolved in a context where that given k=
eyword is actually allowed. Technical implementation might require a stack =
frame - or just inlining.<br><br><i><b>Nicol Bolas> Once you can pass a =
statement expression around, once you can make a function execute a stateme=
nt expression without knowing that it is doing so<br></b></i><br>Good point=
.. If you think it's preferable, I might come up with a solution to dete=
ct if `T' is a PSE/NSE. Note however that you (or your compiler) still =
have the static ability to decide what's going on: all PSEs/NSEs must b=
e inlined and can't be hidden in a library or behind a virtual ptr.<br>=
<br><i><b>Nicol Bolas> Not to mention the potential behavior with regard=
to return type=20
deduction. If a parameter to a function can affect return type deduction
(by issuing a return from a statement expression early), then figuring=20
out what the function's return type will be becomes untenable<br><br></=
b></i>I understand your concern, but in my model it works the other way aro=
und. Assume a function f calling a PSE e. Then the return type of f is deci=
ded first (name it RET); then the compiler, at each point of call with args=
...., tries decltype(e)::operator<RET>()(args...). If it's invalid=
, then that's a compile-time error. Thus you can't have a PSE that =
produces int but might return nullopt in a function that would otherwise (r=
ead: w/o the PSE's `return') return int. Return types are not affec=
ted - not conforming them means invalid code.<br><br><i><b>Nicol Bolas> =
Not to mention, `std::accumulate` itself doesn't have to directly call=
=20
the functor. It can call a sub-function which calls the functor. Or a=20
sub-function of a sub-function calls the functor. It may even have an=20
internal lambda that does the calling. Who knows?<br></b></i><br>Specificat=
ion. I'm okay with any number of nestings in `std::accumulate' as l=
ong as returning from the innermost nest allows me to have identical behavi=
our as the flat version. In other words, a PSE can only be used if you have=
(valid, specified) assumptions about the internals of the function you cal=
l. If you don't, you don't pass a PSE. It's just a feature. It&=
#39;s useful when you're responsible for both the function and the PSE =
(which is very oft) or when there's a clear specification of what early=
return does. Note that you need to have specifications about how your lamb=
da is called as well.<br>If you wanted the other kind of guarantee, namely =
across several function calls, then I'm considering inline catch as a s=
eparate proposal (which is akin to take_return in the other thread; that <i=
>is</i> an exception, albeit a quick one, resolved in compile-time, but sti=
ll non-local).<br><br>Thanks,<br>-lorro<br><br></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/620c7221-1b6e-44bf-82cb-83bd4ac69e05%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/620c7221-1b6e-44bf-82cb-83bd4ac69e05=
%40isocpp.org</a>.<br />
------=_Part_1113_2138160733.1486936056361--
------=_Part_1112_399646855.1486936056360--
.
Author: szollosi.lorand@gmail.com
Date: Sun, 12 Feb 2017 13:57:57 -0800 (PST)
Raw View
------=_Part_1278_1152322663.1486936677854
Content-Type: multipart/alternative;
boundary="----=_Part_1279_1277630236.1486936677854"
------=_Part_1279_1277630236.1486936677854
Content-Type: text/plain; charset=UTF-8
Hi,
Correction: tries decltype(e)::operator<return RET>()(args...)
Thanks,
-lorro
--
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/878cbb1b-ba51-442b-a516-40eaf6b619ea%40isocpp.org.
------=_Part_1279_1277630236.1486936677854
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>Correction: tries decltype(e)::operator<<spa=
n style=3D"color: rgb(255, 0, 0);">return</span> RET>()(args...)<div dir=
=3D"ltr"><br>Thanks,<br>-lorro<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/878cbb1b-ba51-442b-a516-40eaf6b619ea%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/878cbb1b-ba51-442b-a516-40eaf6b619ea=
%40isocpp.org</a>.<br />
------=_Part_1279_1277630236.1486936677854--
------=_Part_1278_1152322663.1486936677854--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 12 Feb 2017 17:41:22 -0800 (PST)
Raw View
------=_Part_1329_109723457.1486950082891
Content-Type: multipart/alternative;
boundary="----=_Part_1330_41595006.1486950082892"
------=_Part_1330_41595006.1486950082892
Content-Type: text/plain; charset=UTF-8
On Sunday, February 12, 2017 at 4:47:36 PM UTC-5, szollos...@gmail.com
wrote:
>
> Hi,
>
> Thanks again for the feedback.
>
> *Viacheslav Usov> The code calling a functor that is actually a PSE has no
> idea where the control is transferred to. As I said just above, that code
> may well expect that the control may not be transferred anywhere at all.*
>
> Currently we don't have noexcept for PSEs and it's not clear what it'd
> mean to have that, given you consider non-local transfer as an exception
> from this point-of-view.. If you have a *function* that calls a *PSE*
> that calls a *PSE*, then we have the guarantee that (unless by an actual
> throw) both the inner and the outer PSE can at most cause the outer
> function to return. Therefore I think that the function might still be
> noexcept. This is different from an exception which might propagate outside
> that function.
>
Here's a simple function:
template<typename F>
int caller(F f)
{
T *t = new T(...);
f();
delete t;
return 5;
}
Now, this has an obvious hole: if `f` throws, then you leak memory. So, we
do this:
template<typename F>
int caller(F f)
{
T *t = new T(...);
try{
f();
}
catch(...)
{
delete t;
throw;
}
delete t;
return 5;
}
That code is now perfectly fine. *Stupid* obviously, but perfectly fine.
Named statements break this code. If `f` forces a `return` on `caller`
early, `caller` becomes broken.
Your response might be to say, "Just use RAII". And while that might fix
this simple example, that's not a guarantee. There's a reason why
`catch(...)` exists. There will always be circumstances where some things
aren't/can't be wrapped in objects.
You might say that you could use `scope_guard` or similar constructs. And
that might be adequate, if not for one problem: the above code works *right
now*. By creating this construct, you are now *forcing* people to consider
an eventuality that they never considered before: that calling what by all
appearances is a function may cause their function to exit without an
exception.
A function can only terminate in 3 ways: `std::terminate` and its ilk,
`throw`, and `return`. Until now, `return` has always been *local*; unlike
the other two, someone cannot `return` for you. So any code written with
the expectation that a function cannot return for them is now potentially
broken.
I consider it conceptually *rude* to be able to *impose* a `return` on a
function. If that function *asks* to allow you to return for it, that's
fine. But it should be something the function explicitly is written to
permit. It should never be hidden and it should never be imposed upon you
without your will, knowledge, or consent.
Note that having an explicit syntax at the cite of the call would give you
a chance to solve the `accumulate` problem. If the function knows that
something could be a named statement, then there could be "passthrough"
syntax which means "if a named statement invoked `return`, then invoke it
on my caller instead". Therefore, standard library functions could be
redefined such that they will call their functors using that passthrough
syntax.
>
> *Viacheslav Usov> Your example used std::accumulate(). The latter
> definitely does not know anything about your PSE and the context it was
> defined in,*It does not know the context, similarly that it does not know
> the context of a lambda. std::accumulate() accepts a template type. That
> template type has a (possibly new kind of) *template *operator(), which
> is resolved in std:accumulate() automatically by its `return'. Thus it does
> know about my PSE, at least to the level that it knows that it has to
> resolve the template return. Naturally this also means that PSEs are inline.
>
>
>
> *Nicol Bolas> If you call a named statement, and that named statement does
> a `for` loop in which it calls another named statement, then the inner
> statement ought to be able to `break` from the outer named statement, not
> into the ultimate calling function. So there very much are stack frames
> here.*This is the same for SE, PSE and NSE. Stack frames are
> implementation, not standard, therefore - so far - I've tried to avoid them
> in the explanation. If it's easier to discuss in terms of implementations,
> then a function / functor receives an implicit return continuation (=return
> address) on the stack; a PSE might receive up to a return, break, continue
> and produce continuation. I do look at normal SEs as function-like objects
> that take these - this might be a difference in our p.o.v. - i.e., in my
> model *any* SE is CALLed and uses RET for returning. Then the optimizer
> can remove these if unnecessary. But that's just implementation.
>
What you call them is irrelevant: function-like objects, "CALLed and RET"
whatever. What matters is behavior. And that *behavior* is very much the
same as exception resolution: keep going up the graph of function calls
until you find the right place.
The only difference seems to be how "the right place" is defined. With
exceptions, it's defined explicitly. With named statements, it happens a
different way.
>
> *Nicol Bolas> If the inner statement issues a `return`, then it must
> terminate both the inner and outer named statements. Exactly like exception
> handling.*Not exactly: the exception might propagate out of any number of
> functions.
>
And the `return` may propagate out of any number of named statement
functions. What's the difference?
> Inline return propagates only to the caller of the function that called
> the SE/PSE/NSE.
>
An exception only propagates to the caller who has a matching `catch`
statement. So again, what's the difference? `try/catch` blocks are even a
static property of a function.
> Thus a caling *function* can still be noexcept, even if we consider
> non-local return as an exception-like entity *from the PSE*. It might be
> exception-like from that point, but from the calling *function*, it's a
> normal return (with the same return type). So I wouldn't consider that as
> breaking the noexcept contract: the PSE-calling function's *caller* will
> continue and can't distinguish (if not by value) if the callee or the inner
> PSE returned.
>
You may be confusing the two arguments here. Viacheslav Usov is the one who
believes that this feature "breaks the noexcept contract". I do not. I
didn't say anything about `noexcept`.
>
> *Nicol Bolas> This code strongly suggests that you can force another
> function to execute a statement expression. That is, the functor passed to
> `accumulate` isn't a lambda; it's a statement expression object of some
> kind.*Yep, in my model it's passed similarly as a lambda (Note: I say
> 'passed', not 'called'). Sorry that I took this evident, that's one more
> point I should explain in the text. To me, a PSE is defined at a point
> (where it might have captures, but it doesn't capture continuations there);
> then it can be passed around as an object of a specific type. It's
> presumably non-copiable, it *might* be movable.
>
Then perhaps you should take another look at `std::accumulate`'s
definition; it takes `BinaryOp` by *value*. So copying/moving is gonna
happen. Most standard library functors work in this fashion.
It has a *template* operator(), which is special. Had `return' (and the
> other control flow statements) been a [[noreturn]] functor, it might have
> been just an ordinary template parameter. Since it's not (and since we want
> auto-resolve to avoid ugly syntax), it's *part of* the template
> specification, but *not* a type parameter. This is similar to `...' being
> part of the argument list, but not being a function argument. Thus it can
> only be resolved in a context where that given keyword is actually allowed.
> Technical implementation might require a stack frame - or just inlining.
>
>
> *Nicol Bolas> Once you can pass a statement expression around, once you
> can make a function execute a statement expression without knowing that it
> is doing so*
> Good point. If you think it's preferable, I might come up with a solution
> to detect if `T' is a PSE/NSE. Note however that you (or your compiler)
> still have the static ability to decide what's going on: all PSEs/NSEs must
> be inlined and can't be hidden in a library or behind a virtual ptr.
>
>
>
> *Nicol Bolas> Not to mention the potential behavior with regard to return
> type deduction. If a parameter to a function can affect return type
> deduction (by issuing a return from a statement expression early), then
> figuring out what the function's return type will be becomes untenable*I
> understand your concern, but in my model it works the other way around.
> Assume a function f calling a PSE e.
>
Stop. The situation we're talking about is that you have a function `f`
which has been *given* a function object `e`. You, as the writer of `f`, *have
no clue* that `e` is a named statement. `f` just so happens to be using
return type deduction.
Then the return type of f is decided first (name it RET); then the
> compiler, at each point of call with args..., tries
> decltype(e)::operator<RET>()(args...). If it's invalid, then that's a
> compile-time error. Thus you can't have a PSE that produces int but might
> return nullopt in a function that would otherwise (read: w/o the PSE's
> `return') return int. Return types are not affected - not conforming them
> means invalid code.
>
Things like this are why I say that named statements and statement
expressions are really separate features. You clearly want them to have
different behavior in some circumstances.
If I issue a `return` as part of a statement expression, I expect that
return to be treated exactly like any other `return` in the code. That is,
it will define the function's return type if return type deduction is being
used. So if the only `return` call just so happens to be in a statement
expression, everything is fine.
But you seem to want named statements to operate differently. Which is
fine, but that is also why they are distinct features.
> *Nicol Bolas> Not to mention, `std::accumulate` itself doesn't have to
> directly call the functor. It can call a sub-function which calls the
> functor. Or a sub-function of a sub-function calls the functor. It may even
> have an internal lambda that does the calling. Who knows?*
> Specification. I'm okay with any number of nestings in `std::accumulate'
> as long as returning from the innermost nest allows me to have identical
> behaviour as the flat version. In other words, a PSE can only be used if
> you have (valid, specified) assumptions about the internals of the function
> you call. If you don't, you don't pass a PSE.
>
It's just a feature.
>
So what good is a feature that's completely unreliable for any code that
you didn't personally write yourself? This feature is looking more and more
like P0057 continuations: a limited hack that only works well under certain
very specific circumstances. Which only encourages the writing of limited
code.
You can't even use it in standard library algorithms, because the standard
library makes no guarantees about this sort of thing. And that's a *good
thing*.
It's useful when you're responsible for both the function and the PSE
> (which is very oft) or when there's a clear specification of what early
> return does.
>
The latter pretty much never happens. Nobody goes specifies how many
function calls are nested between where a function is taken and where it is
called. It's an implementation detail that's none of the outer code's
business.
Note that you need to have specifications about how your lambda is called
> as well.
>
That is a different thing. With lambdas, the only real question is "will it
store the function or not?" And that is usually well-defined by the nature
of the function you're using. If the interface is a signal/slot callback,
then obviously it will store that function. If it's `std::accumulate`, then
obviously it will not store that function.
Some lambdas that try to have mutable state may wonder if the lambda will
be copied. But other than that? No.
Contrast this with your limitations here. This is the only C++ feature I
know of where the number of function calls in a call graph actually changes
its behavior. Indeed, this is exactly why exceptions work the way they do:
to be able to give implementations the freedom to be implemented however
they want, while still propagating exceptions up to the code that actually
knows how to resolve them.
So I see this as a limited and limiting feature. It will encourage people
to write their own private implementations of standard library algorithms
(potentially inefficient ones), just so that they can have known named
statement behavior. It actively discourages splitting functions into
logical units. And so forth.
If you wanted the other kind of guarantee, namely across several function
> calls, then I'm considering inline catch as a separate proposal (which is
> akin to take_return in the other thread; that *is* an exception, albeit a
> quick one, resolved in compile-time, but still non-local).
>
--
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/1c9ed685-fb3b-412d-9b54-2c6be93c61d4%40isocpp.org.
------=_Part_1330_41595006.1486950082892
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, February 12, 2017 at 4:47:36 PM UTC-5, szollos.=
...@gmail.com 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">Hi,<br><br>Thanks again for the feedback.<br><br><i><b><span><span st=
yle=3D"color:rgb(34,34,34)">Viacheslav Usov> </span></span>The code call=
ing a functor that is actually a PSE has no idea=C2=A0where
the control is transferred to. As I said just above, that code may well
expect that the control may not be transferred anywhere at all.</b></i><br=
><br>Currently we don't have noexcept for PSEs and it's not clear w=
hat it'd mean to have that, given you consider non-local transfer as an=
exception from this point-of-view.. If you have a <i>function</i> that cal=
ls a <i>PSE</i> that calls a <i>PSE</i>, then we have the guarantee that (u=
nless by an actual throw) both the inner and the outer PSE can at most caus=
e the outer function to return. Therefore I think that the function might s=
till be noexcept. This is different from an exception which might propagate=
outside that function.<br></div></blockquote><div><br>Here's a simple =
function:<br><br>template<typename F><br>int caller(F f)<br>{<br>=C2=
=A0 T *t =3D new T(...);<br>=C2=A0 f();<br>=C2=A0 delete t;<br>=C2=A0 retur=
n 5;<br>}<br><br>Now, this has an obvious hole: if `f` throws, then you lea=
k memory. So, we do this:<br><br>template<typename F><br>int caller(F=
f)<br>{<br>=C2=A0 T *t =3D new T(...);<br>=C2=A0 try{<br>=C2=A0 =C2=A0 f()=
;<br>=C2=A0 }<br>=C2=A0 catch(...)<br>=C2=A0 {<br>=C2=A0=C2=A0=C2=A0 delete=
t;<br>=C2=A0=C2=A0=C2=A0 throw;<br>=C2=A0 }<br>=C2=A0 delete t;<br>=C2=A0 =
return 5;<br>}<br><br>That code is now perfectly fine. <i>Stupid</i> obviou=
sly, but perfectly fine.<br><br>Named statements break this code. If `f` fo=
rces a `return` on `caller` early, `caller` becomes broken.<br><br>Your res=
ponse might be to say, "Just use RAII". And while that might fix =
this simple example, that's not a guarantee. There's a reason why `=
catch(...)` exists. There will always be circumstances where some things ar=
en't/can't be wrapped in objects.<br><br>You might say that you cou=
ld use `scope_guard` or similar constructs. And that might be adequate, if =
not for one problem: the above code works <i>right now</i>. By creating thi=
s construct, you are now <i>forcing</i> people to consider an eventuality t=
hat they never considered before: that calling what by all appearances is a=
function may cause their function to exit without an exception.<br><br>A f=
unction can only terminate in 3 ways: `std::terminate` and its ilk, `throw`=
, and `return`. Until now, `return` has always been <i>local</i>; unlike th=
e other two, someone cannot `return` for you. So any code written with the =
expectation that a function cannot return for them is now potentially broke=
n.<br><br>I consider it conceptually <i>rude</i> to be able to <i>impose</i=
> a `return` on a function. If that function <i>asks</i> to allow you to re=
turn for it, that's fine. But it should be something the function expli=
citly is written to permit. It should never be hidden and it should never b=
e imposed upon you without your will, knowledge, or consent.<br><br>Note th=
at having an explicit syntax at the cite of the call would give you a chanc=
e to solve the `accumulate` problem. If the function knows that something c=
ould be a named statement, then there could be "passthrough" synt=
ax which means "if a named statement invoked `return`, then invoke it =
on my caller instead". Therefore, standard library functions could be =
redefined such that they will call their functors using that passthrough sy=
ntax.<br><br></div><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"><i><b><span><span style=3D"color:rgb(34,34,34)">Viacheslav Usov> <=
/span></span>Your example used std::accumulate(). The latter definitely doe=
s not know
anything about your PSE and the context it was defined in,</b><b><br><br><=
/b></i>It does not know the context, similarly that it does not know the co=
ntext of a lambda. std::accumulate() accepts a template type. That template=
type has a (possibly new kind of) <i>template </i>operator(), which is res=
olved in std:accumulate() automatically by its `return'. Thus it does k=
now about my PSE, at least to the level that it knows that it has to resolv=
e the template return. Naturally this also means that PSEs are inline.<br><=
br><i><b>Nicol Bolas> If you call a named statement, and that named stat=
ement does a `for`=20
loop in which it calls another named statement, then the inner statement
ought to be able to `break` from the outer named statement, not into=20
the ultimate calling function. So there very much are stack frames here.<br=
><br></b></i>This is the same for SE, PSE and NSE. Stack frames are impleme=
ntation, not standard, therefore - so far - I've tried to avoid them in=
the explanation. If it's easier to discuss in terms of implementations=
, then a function / functor receives an implicit return continuation (=3Dre=
turn address) on the stack; a PSE might receive up to a return, break, cont=
inue and produce continuation. I do look at normal SEs as function-like obj=
ects that take these - this might be a difference in our p.o.v. - i.e., in =
my model <i>any</i> SE is CALLed and uses RET for returning. Then the optim=
izer can remove these if unnecessary. But that's just implementation.<b=
r></div></blockquote><div><br>What you call them is irrelevant: function-li=
ke objects, "CALLed and RET" whatever. What matters is behavior. =
And that <i>behavior</i> is very much the same as exception resolution: kee=
p going up the graph of function calls until you find the right place.<br><=
br>The only difference seems to be how "the right place" is defin=
ed. With exceptions, it's defined explicitly. With named statements, it=
happens a different way.<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><i><b>Nicol Bolas> If the inner statement issu=
es a `return`, then it must terminate both=20
the inner and outer named statements. Exactly like exception handling.<br><=
br></b></i>Not exactly: the exception might propagate out of any number of =
functions.</div></blockquote><div><br>And the `return` may propagate out of=
any number of named statement functions. What's the difference?<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"> Inl=
ine return propagates only to the caller of the function that called the SE=
/PSE/NSE.</div></blockquote><div><br>An exception only propagates to the ca=
ller who has a matching `catch` statement. So again, what's the differe=
nce? `try/catch` blocks are even a static property of a function.<br>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Thus a =
caling <i>function</i> can still be noexcept, even if we consider non-local=
return as an exception-like entity <i>from the PSE</i>. It might be except=
ion-like from that point, but from the calling <i>function</i>, it's a =
normal return (with the same return type). So I wouldn't consider that =
as breaking the noexcept contract: the PSE-calling function's <i>caller=
</i> will continue and can't distinguish (if not by value) if the calle=
e or the inner PSE returned.<br></div></blockquote><div><br>You may be conf=
using the two arguments here. Viacheslav Usov is the one who believes that =
this feature "breaks the noexcept contract". I do not. I didn'=
;t say anything about `noexcept`.<br><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><i><b>Nicol Bolas> This code strongly =
suggests that you can force another=20
function to execute a statement expression. That is, the functor passed=20
to `accumulate` isn't a lambda; it's a statement expression object =
of=20
some kind.<br><br></b></i>Yep, in my model it's passed similarly as a l=
ambda (Note: I say 'passed', not 'called'). Sorry that I to=
ok this evident, that's one more point I should explain in the text. To=
me, a PSE is defined at a point (where it might have captures, but it does=
n't capture continuations there); then it can be passed around as an ob=
ject of a specific type. It's presumably non-copiable, it <i>might</i> =
be movable.</div></blockquote><div><br>Then perhaps you should take another=
look at `std::accumulate`'s definition; it takes `BinaryOp` by <i>valu=
e</i>. So copying/moving is gonna happen. Most standard library functors wo=
rk in this fashion.<br><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"> It has a <i>template</i> operator(), which is special.=
Had `return' (and the other control flow statements) been a [[noreturn=
]] functor, it might have been just an ordinary template parameter. Since i=
t's not (and since we want auto-resolve to avoid ugly syntax), it's=
<i>part of</i> the template specification, but <i>not</i> a type parameter=
.. This is similar to `...' being part of the argument list, but not bei=
ng a function argument. Thus it can only be resolved in a context where tha=
t given keyword is actually allowed. Technical implementation might require=
a stack frame - or just inlining.<br></div></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid=
rgb(204, 204, 204); padding-left: 1ex;"><div><br></div></blockquote><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><i><b>Nicol Bolas&g=
t; Once you can pass a statement expression around, once you can make a fun=
ction execute a statement expression without knowing that it is doing so<br=
></b></i><br>Good point. If you think it's preferable, I might come up =
with a solution to detect if `T' is a PSE/NSE. Note however that you (o=
r your compiler) still have the static ability to decide what's going o=
n: all PSEs/NSEs must be inlined and can't be hidden in a library or be=
hind a virtual ptr.<br><br><i><b>Nicol Bolas> Not to mention the potenti=
al behavior with regard to return type=20
deduction. If a parameter to a function can affect return type deduction
(by issuing a return from a statement expression early), then figuring=20
out what the function's return type will be becomes untenable<br><br></=
b></i>I understand your concern, but in my model it works the other way aro=
und. Assume a function f calling a PSE e.</div></blockquote><div><br>Stop. =
The situation we're talking about is that you have a function `f` which=
has been <i>given</i> a function object `e`. You, as the writer of `f`, <i=
>have no clue</i> that `e` is a named statement. `f` just so happens to be =
using return type deduction.<br><br></div><blockquote class=3D"gmail_quote"=
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr">Then the return type of f is decided first (na=
me it RET); then the compiler, at each point of call with args..., tries de=
cltype(e)::operator<RET>()(args...).
If it's invalid, then that's a compile-time error. Thus you can=
9;t have a
PSE that produces int but might return nullopt in a function that would
otherwise (read: w/o the PSE's `return') return int. Return types =
are=20
not affected - not conforming them means invalid code.</div></blockquote><d=
iv><br>Things like this are why I say that named statements and statement e=
xpressions are really separate features. You clearly want them to have diff=
erent behavior in some circumstances.<br><br>If I issue a `return` as part =
of a statement expression, I expect that return to be treated exactly like =
any other `return` in the code. That is, it will define the function's =
return type if return type deduction is being used. So if the only `return`=
call just so happens to be in a statement expression, everything is fine.<=
br><br>But you seem to want named statements to operate differently. Which =
is fine, but that is also why they are distinct features.<br><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div><i><b>Nicol Bolas> Not to =
mention, `std::accumulate` itself doesn't have to directly call=20
the functor. It can call a sub-function which calls the functor. Or a=20
sub-function of a sub-function calls the functor. It may even have an=20
internal lambda that does the calling. Who knows?<br></b></i><br>Specificat=
ion. I'm okay with any number of nestings in `std::accumulate' as l=
ong as returning from the innermost nest allows me to have identical behavi=
our as the flat version. In other words, a PSE can only be used if you have=
(valid, specified) assumptions about the internals of the function you cal=
l. If you don't, you don't pass a PSE. <br></div></blockquote><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">It's just a fe=
ature.</div></blockquote><div><br>So what good is a feature that's comp=
letely unreliable for any code that you didn't personally write yoursel=
f? This feature is looking more and more like P0057 continuations: a limite=
d hack that only works well under certain very specific circumstances. Whic=
h only encourages the writing of limited code.<br><br>You can't even us=
e it in standard library algorithms, because the standard library makes no =
guarantees about this sort of thing. And that's a <i>good thing</i>.<br=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">It=
's useful when you're responsible for both the function and the PSE=
(which is very oft) or when there's a clear specification of what earl=
y return does.</div></blockquote><div><br>The latter pretty much never happ=
ens. Nobody goes specifies how many function calls are nested between where=
a function is taken and where it is called. It's an implementation det=
ail that's none of the outer code's business.<br><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Note that you need to=
have specifications about how your lambda is called as well.<br></div></bl=
ockquote><div><br>That is a different thing. With lambdas, the only real qu=
estion is "will it store the function or not?" And that is usuall=
y well-defined by the nature of the function you're using. If the inter=
face is a signal/slot callback, then obviously it will store that function.=
If it's `std::accumulate`, then obviously it will not store that funct=
ion.<br><br>Some lambdas that try to have mutable state may wonder if the l=
ambda will be copied. But other than that? No.<br><br>Contrast this with yo=
ur limitations here. This is the only C++ feature I know of where the numbe=
r of function calls in a call graph actually changes its behavior. Indeed, =
this is exactly why exceptions work the way they do: to be able to give imp=
lementations the freedom to be implemented however they want, while still p=
ropagating exceptions up to the code that actually knows how to resolve the=
m.<br><br>So I see this as a limited and limiting feature. It will encourag=
e people to write their own private implementations of standard library alg=
orithms (potentially inefficient ones), just so that they can have known na=
med statement behavior. It actively discourages splitting functions into lo=
gical units. And so forth.<br><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr">If you wanted the other kind of guarantee, namel=
y across several function calls, then I'm considering inline catch as a=
separate proposal (which is akin to take_return in the other thread; that =
<i>is</i> an exception, albeit a quick one, resolved in compile-time, but s=
till non-local).<br></div></blockquote></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/1c9ed685-fb3b-412d-9b54-2c6be93c61d4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1c9ed685-fb3b-412d-9b54-2c6be93c61d4=
%40isocpp.org</a>.<br />
------=_Part_1330_41595006.1486950082892--
------=_Part_1329_109723457.1486950082891--
.
Author: Viacheslav Usov <via.usov@gmail.com>
Date: Mon, 13 Feb 2017 11:15:40 +0100
Raw View
--001a1135b526c5daaa054866ba45
Content-Type: text/plain; charset=UTF-8
On Sun, Feb 12, 2017 at 10:47 PM, <szollosi.lorand@gmail.com> wrote:
> *Viacheslav Usov> The code calling a functor that is actually a PSE has no
> idea where the control is transferred to. As I said just above, that code
> may well expect that the control may not be transferred anywhere at all.*
>
> Currently we don't have noexcept for PSEs and it's not clear what it'd
> mean to have that, given you consider non-local transfer as an exception
> from this point-of-view.. If you have a *function* that calls a *PSE*
> that calls a *PSE*, then we have the guarantee that (unless by an actual
> throw) both the inner and the outer PSE can at most cause the outer
> function to return. Therefore I think that the function might still be
> noexcept. This is different from an exception which might propagate outside
> that function.
>
The point of noexcept is not that the 'outer' function can be marked as
noexcept. The point is that the 'outer' function can call some other
functions marked as noexcept, passing those PSE objects to them. And what
is the effect of the PSE's return on those nested calls?
>
> *Viacheslav Usov> Your example used std::accumulate(). The latter
> definitely does not know anything about your PSE and the context it was
> defined in,*It does not know the context, similarly that it does not know
> the context of a lambda. std::accumulate() accepts a template type. That
> template type has a (possibly new kind of) *template *operator(), which
> is resolved in std:accumulate() automatically by its `return'. Thus it does
> know about my PSE, at least to the level that it knows that it has to
> resolve the template return. Naturally this also means that PSEs are inline.
>
Are you saying that both the PSE and the function, which is called with the
PSE, shall be defined in the same translation unit?
Cheers,
V.
--
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/CAA7YVg1itbqbRnghw0aOPuKSt4Ki4JDSQNZtCPBTuY%2BrxE7ZrQ%40mail.gmail.com.
--001a1135b526c5daaa054866ba45
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Feb 12, 2017 at 10:47 PM, <span dir=3D"ltr"><<a href=3D"mailto:szol=
losi.lorand@gmail.com" target=3D"_blank">szollosi.lorand@gmail.com</a>><=
/span> wrote:<br><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><i><b><span class=3D"gmail-m_556041341874013645=
8_username"><span class=3D"gmail-m_5560413418740136458IVILX2C-D-a" style=3D=
"color:rgb(34,34,34)">Viacheslav Usov> </span></span>The code calling a =
functor that is actually a PSE has no idea=C2=A0where
the control is transferred to. As I said just above, that code may well
expect that the control may not be transferred anywhere at all.</b></i><br=
><br>Currently we don't have noexcept for PSEs and it's not clear w=
hat it'd mean to have that, given you consider non-local transfer as an=
exception from this point-of-view.. If you have a <i>function</i> that cal=
ls a <i>PSE</i> that calls a <i>PSE</i>, then we have the guarantee that (u=
nless by an actual throw) both the inner and the outer PSE can at most caus=
e the outer function to return. Therefore I think that the function might s=
till be noexcept. This is different from an exception which might propagate=
outside that function.<br></div></blockquote><div><br></div><div>The point=
of noexcept is not that the 'outer' function can be marked as noex=
cept. The point is that the 'outer' function can call some other fu=
nctions marked as noexcept, passing those PSE objects to=C2=A0them. And wha=
t is the effect of the PSE's return on those nested calls?</div><div><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
<i><b><span class=3D"gmail-m_5560413418740136458_username"><span class=3D"g=
mail-m_5560413418740136458IVILX2C-D-a" style=3D"color:rgb(34,34,34)">Viache=
slav Usov> </span></span>Your example used std::accumulate(). The latter=
definitely does not know
anything about your PSE and the context it was defined in,</b><b><br><br><=
/b></i>It does not know the context, similarly that it does not know the co=
ntext of a lambda. std::accumulate() accepts a template type. That template=
type has a (possibly new kind of) <i>template </i>operator(), which is res=
olved in std:accumulate() automatically by its `return'. Thus it does k=
now about my PSE, at least to the level that it knows that it has to resolv=
e the template return. Naturally this also means that PSEs are inline.<br><=
/div></blockquote><div><br></div><div>Are you saying that both the PSE and =
the function, which is called with the PSE, shall be defined in the same tr=
anslation unit?</div><div><br></div><div>Cheers,</div><div>V.</div><div><br=
></div></div></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/CAA7YVg1itbqbRnghw0aOPuKSt4Ki4JDSQNZt=
CPBTuY%2BrxE7ZrQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg1itbqbRn=
ghw0aOPuKSt4Ki4JDSQNZtCPBTuY%2BrxE7ZrQ%40mail.gmail.com</a>.<br />
--001a1135b526c5daaa054866ba45--
.
Author: szollosi.lorand@gmail.com
Date: Mon, 13 Feb 2017 14:54:56 -0800 (PST)
Raw View
------=_Part_1643_710585454.1487026496575
Content-Type: multipart/alternative;
boundary="----=_Part_1644_609742163.1487026496576"
------=_Part_1644_609742163.1487026496576
Content-Type: text/plain; charset=UTF-8
Hi,
*Nicol Bolas> Now, this has an obvious hole: if `f` throws, then you leak
memory.*
Yes, it does. If you throw, it does - there's a workaround for that, as you
correctly described. If you call a PSE/NSE, it *might* leak - there's still
a workaround for that, as you described. If `f' is a [[noreturn]] function,
then we actually leak - and there's no workaround, correct me if I'm wrong.
*Nicol Bolas> And the `return` may propagate out of any number of named
statement functions. What's the difference?*
It can only propagate out of NSEs/PSEs. It cannot propagate out of
functions. A code which itself doesn't use exception handling might call
into a throwing function and receive an 'alternative return type' in an
'alternative return path'. A code that itself doesn't call PSEs will never
receive an alternative return type or get returned to an alternative
location even if it passes a PSE. I see this as a difference.
*Nicol Bolas> I consider it conceptually rude to be able to impose a
`return` on a function. If that function asks to allow you to return for
it, that's fine. But it should be something the function explicitly is
written to permit. It should never be hidden and it should never be imposed
upon you without your will, knowledge, or consent.*I'm okay with that
restriction. I originally omitted explicit `take_return` to keep it brief,
but there are multiple options here: (where `op` might be a PSE)
//option 1 - explicitly name the continuations that can be taken
template< class InputIt, class T, class BinaryOperation >
T accumulate(InputIt first, InputIt last, T init, BinaryOperation op)
{
for (; first != last; ++first)
init = op<return>(init, *first);
}
//option 2 - `allow taking here`
template< class InputIt, class T, class BinaryOperation >
T accumulate(InputIt first, InputIt last, T init, BinaryOperation op)
{
for (; first != last; ++first)
init = `op(init, *first)`;
}
//option 3 - allow PSE only if inside a SE
template< class InputIt, class T, class BinaryOperation >
T accumulate(InputIt first, InputIt last, T init, BinaryOperation op)
{
for (; first != last; ++first)
init = ({ op(init, *first) });
}
//option 4 - convert control flow statement to [[noreturn]] void fn
template< class InputIt, class T, class BinaryOperationWithReturn >
T accumulate(InputIt first, InputIt last, T init, BinaryOperationWithReturn
op)
{
for (; first != last; ++first)
init = op(`return`, init, *first);
}
Depending on how we define them, option 1 and 4 might require separate
specialization / overload of the function being implemented. Option 2 is a
new char (digraphs :) and, since symmetric, might be problematic to nest.
Option 3 is either confusing or logical depending on how you approach it;
it definitely needs explanation. Do you find any of these ok, or should we
try more alternatives?
Also note that, when I originally started working on this, I didn't even
consider allowing to forward a PSE/NSE, as it's not required in most common
use cases. Passing it is necessary but - if you find it a good idea - I'm
okay with explicitly disabling std::forward<>() on these.
*Nicol Bolas> Nobody goes specifies how many function calls are nested
between where a function is taken and where it is called.*
Nobody used to specify if a variable is going to be reassigned / destructed
after a call, as that was the caller's business. Then we started to realize
the benefits of move. We don't use move everywhere, only where it's
reasonable.
I'm not saying everyone will use it - I don't even want everyone to use it.
I see a limited scope for control flow-like statements, of which we tend to
have many proposals. NSEs could bring you for..else, for..break,
if_optional, accumulate with shortcut, and maybe some others that we don't
yet foresee: that's the scope. Instead of separate proposals for these I
suggest a language feature that moves these to the library.
Also note, a function that's aware of PSEs and need to delegate internally
might as well use delegation to PSEs / NSEs. I think it's reasonable to
expect the above to specify if the PSE is called directly.
*Viacheslav Usov> The point is that the 'outer' function can call some
other functions marked as noexcept, passing those PSE objects to them. And
what is the effect of the PSE's return on those nested calls?*IF - and only
if - we want to allow forwarding a PSE, then the PSE will return from the
innermost function caling it - in this case, the inner function. Hence the
outer function should be aware of this. Note that PSEs are not really
designed or expected to be passed around this way. If you need an inner
function-like object within a function that gets PSE and you want to pass
the inner one the PSE, use a PSE/NSE for the inner function-like object as
well.
*Viacheslav Usov> Are you saying that both the PSE and the function, which
is called with the PSE, shall be defined in the same translation unit?*Definitely.
PSE body should be visible to the compiler when compiling the function that
takes it (to avoid overhead from multiple return addresses); I'm okay if we
want to make it visible to the calling function. To me, a PSE's operator()
is basically a template.
Thanks,
-lorro
--
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/b0a11696-e77b-4a1f-ad73-b3984ce315ff%40isocpp.org.
------=_Part_1644_609742163.1487026496576
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br><i><b>Nicol Bolas> Now, this has an obvious =
hole: if `f` throws, then you leak memory.</b></i><br>Yes, it does. If you =
throw, it does - there's a workaround for that, as you correctly descri=
bed. If you call a PSE/NSE, it *might* leak - there's still a workaroun=
d for that, as you described. If `f' is a [[noreturn]] function, then w=
e actually leak - and there's no workaround, correct me if I'm wron=
g.<br><br><i><b>Nicol Bolas> And the `return` may propagate out of any n=
umber of named statement functions. What's the difference?</b></i><br>I=
t can only propagate out of NSEs/PSEs. It cannot propagate out of functions=
.. A code which itself doesn't use exception handling might call into a =
throwing function and receive an 'alternative return type' in an &#=
39;alternative return path'. A code that itself doesn't call PSEs w=
ill never receive an alternative return type or get returned to an alternat=
ive location even if it passes a PSE. I see this as a difference.<br><br><i=
><b>Nicol Bolas> I consider it conceptually rude to be able to impose a =
`return` on a function. If that function asks
to allow you to return for it, that's fine. But it should be something=
=20
the function explicitly is written to permit. It should never be hidden=20
and it should never be imposed upon you without your will, knowledge, or
consent.<br></b></i>I'm okay with that restriction. I originally omitt=
ed explicit `take_return` to keep it brief, but there are multiple options =
here: (where `op` might be a PSE)<br><div style=3D"background-color: rgb(25=
0, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border=
-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #800;"=
class=3D"styled-by-prettify">//option 1</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> - explicitly name the continuations that can=
be taken<br></span><span class=3D"mw-geshi cpp source-cpp"><span class=3D"=
kw1"><span style=3D"color: #008;" class=3D"styled-by-prettify">template</sp=
an></span><span class=3D"sy1"><span style=3D"color: #660;" class=3D"styled-=
by-prettify"><</span></span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span class=3D"kw1"><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">class</span></span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">InputIt</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span class=3D"kw1"><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">class</span></span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span class=3D"kw1"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">class</span></span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pret=
tify">BinaryOperation</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span class=3D"sy1"><span style=3D"color: #660;" class=
=3D"styled-by-prettify">></span></span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span><p><span style=3D"color: #000;" class=
=3D"styled-by-prettify">T accumulate</span><span class=3D"br0"><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span></span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">InputIt</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> first</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">InputIt</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">last</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T =
init</span><span class=3D"mw-geshi cpp source-cpp"><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">BinaryOperation</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> op</span><span class=3D"br0"><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">)</span></span><span class=3D"sy4"></span=
></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">for</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"styled-by-prettify"> first </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">!=3D</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">last</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">++</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">first</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 init </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> op</sp=
an><span style=3D"color: #080;" class=3D"styled-by-prettify"><return>=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">init</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #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"styled-by-prettify">first</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span></p><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">/</span></sp=
an><span class=3D"mw-geshi cpp source-cpp"><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><code class=3D"prettyprint"><span style=3D"color:=
#800;" class=3D"styled-by-prettify">/option 2</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> - `allow taking here`<br></span><span =
class=3D"mw-geshi cpp source-cpp"><span class=3D"kw1"><span style=3D"color:=
#008;" class=3D"styled-by-prettify">template</span></span><span class=3D"s=
y1"><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span></=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n class=3D"kw1"><span style=3D"color: #008;" class=3D"styled-by-prettify">c=
lass</span></span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">InputIt<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span class=
=3D"kw1"><span style=3D"color: #008;" class=3D"styled-by-prettify">class</s=
pan></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span class=3D"=
kw1"><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span>=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">BinaryOperation</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
class=3D"sy1"><span style=3D"color: #660;" class=3D"styled-by-prettify">>=
;</span></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><p><span style=3D"color: #000;" class=3D"styled-by-prettify">T acc=
umulate</span><span class=3D"br0"><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span></span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">InputIt</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> first</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">InputIt</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #008;" class=3D"styled-by-prettify">last</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> T init</span><span class=3D"mw-geshi=
cpp source-cpp"><span style=3D"color: #660;" class=3D"styled-by-prettify">=
,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">BinaryOperation</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> op</span><sp=
an class=3D"br0"><span style=3D"color: #660;" class=3D"styled-by-prettify">=
)</span></span><span class=3D"sy4"></span></span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">for</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> first </span><span style=3D"color: #660;" class=3D"styled-by-prettify">!=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">last</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">;</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;" cl=
ass=3D"styled-by-prettify">first</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 init </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> `op</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">init</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">first</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)`;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span></p></span></code></span></sp=
an><br><code class=3D"prettyprint"><span class=3D"mw-geshi cpp source-cpp">=
<span style=3D"color: #660;" class=3D"styled-by-prettify">/</span></span><s=
pan class=3D"mw-geshi cpp source-cpp"><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #800=
;" class=3D"styled-by-prettify">/option 3</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> - allow PSE only if inside a SE<br></span><=
span class=3D"mw-geshi cpp source-cpp"><span class=3D"kw1"><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">template</span></span><span class=
=3D"sy1"><span style=3D"color: #660;" class=3D"styled-by-prettify"><</sp=
an></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span class=3D"kw1"><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">class</span></span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Inp=
utIt</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span c=
lass=3D"kw1"><span style=3D"color: #008;" class=3D"styled-by-prettify">clas=
s</span></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span class=
=3D"kw1"><span style=3D"color: #008;" class=3D"styled-by-prettify">class</s=
pan></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #606;" class=3D"styled-by-prettify">BinaryOperation=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan class=3D"sy1"><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>></span></span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><p><span style=3D"color: #000;" class=3D"styled-by-prettify">T=
accumulate</span><span class=3D"br0"><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span></span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">InputIt</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> first</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">InputI=
t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">last</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> T init</span><span class=3D"mw-g=
eshi cpp source-cpp"><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">BinaryOperatio=
n</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> op</span=
><span class=3D"br0"><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)</span></span><span class=3D"sy4"></span></span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">for</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> first </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">!=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">last</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">++</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">first</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 init </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> ({ op</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">init</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">first<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">) });</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><br><code class=3D"p=
rettyprint"></code></p><div class=3D"subprettyprint"><code class=3D"prettyp=
rint"><code class=3D"prettyprint"><span class=3D"mw-geshi cpp source-cpp"><=
span style=3D"color: #660;" class=3D"styled-by-prettify">/</span></span><sp=
an class=3D"mw-geshi cpp source-cpp"><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><code class=3D"prettyprint"><span style=3D"color: #800;=
" class=3D"styled-by-prettify">/option 4</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> - convert control flow statement to [[noretu=
rn]] void fn<br></span><span class=3D"mw-geshi cpp source-cpp"><span class=
=3D"kw1"><span style=3D"color: #008;" class=3D"styled-by-prettify">template=
</span></span><span class=3D"sy1"><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><</span></span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span class=3D"kw1"><span style=3D"color: #008;" =
class=3D"styled-by-prettify">class</span></span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">InputIt</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span class=3D"kw1"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">class</span></span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span class=3D"kw1"><span style=3D"color: #008;" class=3D"=
styled-by-prettify">class</span></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">BinaryOperationWithReturn</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span class=3D"sy1"><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">></span></span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><p><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">T accumulate</span><span class=3D"br=
0"><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span></span=
><span style=3D"color: #606;" class=3D"styled-by-prettify">InputIt</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> first</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">InputIt</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">last</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> T init</span><span class=3D"mw-geshi cpp source-cpp"><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" =
class=3D"styled-by-prettify">BinaryOperation</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">WithReturn op</span><span class=3D"br0"><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span></span><sp=
an class=3D"sy4"></span></span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">for</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"styled-by-prettify"> first </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">!=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">last</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">++</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">first</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 init </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> op</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>`return`, init</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">first</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br></span></p></span></code></span></span></code>=
</code></div><p></p></span></code></span></span></code></div></code></div><=
br>Depending on how we define them, option 1 and 4 might require separate s=
pecialization / overload of the function being implemented. Option 2 is a n=
ew char (digraphs :) and, since symmetric, might be problematic to nest. Op=
tion 3 is either confusing or logical depending on how you approach it; it =
definitely needs explanation. Do you find any of these ok, or should we try=
more alternatives?<br>Also note that, when I originally started working on=
this, I didn't even consider allowing to forward a PSE/NSE, as it'=
s not required in most common use cases. Passing it is necessary but - if y=
ou find it a good idea - I'm okay with explicitly disabling std::forwar=
d<>() on these.<br><br><i><b>Nicol Bolas> Nobody goes specifies ho=
w many function calls are nested between where a function is taken and wher=
e it is called.</b></i><br>Nobody used to specify if a variable is going to=
be reassigned / destructed after a call, as that was the caller's busi=
ness. Then we started to realize the benefits of move. We don't use mov=
e everywhere, only where it's reasonable.<br>I'm not saying everyon=
e will use it - I don't even want everyone to use it. I see a limited s=
cope for control flow-like statements, of which we tend to have many propos=
als. NSEs could bring you for..else, for..break, if_optional, accumulate wi=
th shortcut, and maybe some others that we don't yet foresee: that'=
s the scope. Instead of separate proposals for these I suggest a language f=
eature that moves these to the library.<br>Also note, a function that's=
aware of PSEs and need to delegate internally might as well use delegation=
to PSEs / NSEs. I think it's reasonable to expect the above to specify=
if the PSE is called directly.<br><br><i><b><span class=3D"_username"><spa=
n class=3D"IVILX2C-D-a" style=3D"color: rgb(34, 34, 34);">Viacheslav </span=
></span>Usov> The point is that the 'outer' function can call so=
me other functions=20
marked as noexcept, passing those PSE objects to=C2=A0them. And what is the=
=20
effect of the PSE's return on those nested calls?<br></b></i>IF - and o=
nly if - we want to allow forwarding a PSE, then the PSE will return from t=
he innermost function caling it - in this case, the inner function. Hence t=
he outer function should be aware of this. Note that PSEs are not really de=
signed or expected to be passed around this way. If you need an inner funct=
ion-like object within a function that gets PSE and you want to pass the in=
ner one the PSE, use a PSE/NSE for the inner function-like object as well.<=
br><br><i><b><span class=3D"_username"><span class=3D"IVILX2C-D-a" style=3D=
"color: rgb(34, 34, 34);">Viacheslav </span></span>Usov> Are you saying =
that both the PSE and the function, which is called with the PSE, shall be =
defined in the same translation unit?<br></b></i>Definitely. PSE body shoul=
d be visible to the compiler when compiling the function that takes it (to =
avoid overhead from multiple return addresses); I'm okay if we want to =
make it visible to the calling function. To me, a PSE's operator() is b=
asically a template.<br><br>Thanks,<br>-lorro<br><br></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/b0a11696-e77b-4a1f-ad73-b3984ce315ff%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b0a11696-e77b-4a1f-ad73-b3984ce315ff=
%40isocpp.org</a>.<br />
------=_Part_1644_609742163.1487026496576--
------=_Part_1643_710585454.1487026496575--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 13 Feb 2017 18:10:21 -0800 (PST)
Raw View
------=_Part_2545_1431843424.1487038221168
Content-Type: multipart/alternative;
boundary="----=_Part_2546_1056738794.1487038221169"
------=_Part_2546_1056738794.1487038221169
Content-Type: text/plain; charset=UTF-8
On Monday, February 13, 2017 at 5:54:56 PM UTC-5, szollos...@gmail.com
wrote:
>
> Hi,
>
> *Nicol Bolas> Now, this has an obvious hole: if `f` throws, then you leak
> memory.*
> Yes, it does. If you throw, it does - there's a workaround for that, as
> you correctly described. If you call a PSE/NSE, it *might* leak - there's
> still a workaround for that, as you described.
>
You mean the workaround I said couldn't be used everywhere?
If `f' is a [[noreturn]] function, then we actually leak - and there's no
> workaround, correct me if I'm wrong.
>
No, there is no "actual leak". Returning from a `[[noreturn]]` function is
UB. And being undefined means that it is not defined whether it will leak
or not.
If the function transfers control elsewhere or terminates or whatever, then
even the RAII version would "leak". But nobody cares because the
application is being terminated or whatever.
*Nicol Bolas> And the `return` may propagate out of any number of named
> statement functions. What's the difference?*
> It can only propagate out of NSEs/PSEs. It cannot propagate out of
> functions.
>
But since they can nest, the locality of exactly where a "return" codes is
not immediately obvious.
Just like exceptions.
I don't know why you're so fundamentally against treating this as a
specialized exception. It would solve *so many* of the problems with your
idea: the inability of code between the two points to interfere in the
skipping process, the inability to have it `return` through arbitrary
numbers of functions, the specific nature of these constructs (are they
functions, if not, then what are they, are they objects, etc). The feature
becomes *far* more useful once you use exception resolution as the
foundation of it.
If performance is a concern, then for the cases you're most concerned about
(everything is inline and visible), I'm sure compilers can be smart enough
to optimize it down to triviality. The syntax for such code can also be
made more reasonable.
The only real problem with doing it this way is how to deal with the case
of someone throwing one return type to a function which returns a
different, incompatible one. Since the circumstance is (nominally) a
runtime construct, it would need to be a runtime error (like `terminate`).
A code which itself doesn't use exception handling might call into a
> throwing function and receive an 'alternative return type' in an
> 'alternative return path'. A code that itself doesn't call PSEs will never
> receive an alternative return type or get returned to an alternative
> location even if it passes a PSE. I see this as a difference.
>
But whether code calls a named statement or not is not necessarily up to
that function. So whether a function calls a named statement is not
necessarily known to the writer of that function.
> *Nicol Bolas> I consider it conceptually rude to be able to impose a
> `return` on a function. If that function asks to allow you to return for
> it, that's fine. But it should be something the function explicitly is
> written to permit. It should never be hidden and it should never be imposed
> upon you without your will, knowledge, or consent.*I'm okay with that
> restriction. I originally omitted explicit `take_return` to keep it brief,
> but there are multiple options here: (where `op` might be a PSE)
> //option 1 - explicitly name the continuations that can be taken
> template< class InputIt, class T, class BinaryOperation >
>
> T accumulate(InputIt first, InputIt last, T init, BinaryOperation op)
> {
> for (; first != last; ++first)
> init = op<return>(init, *first);
> }
>
> //option 2 - `allow taking here`
> template< class InputIt, class T, class BinaryOperation >
>
> T accumulate(InputIt first, InputIt last, T init, BinaryOperation op)
> {
> for (; first != last; ++first)
> init = `op(init, *first)`;
> }
>
> //option 3 - allow PSE only if inside a SE
> template< class InputIt, class T, class BinaryOperation >
>
> T accumulate(InputIt first, InputIt last, T init, BinaryOperation op)
> {
> for (; first != last; ++first)
> init = ({ op(init, *first) });
> }
>
> //option 4 - convert control flow statement to [[noreturn]] void fn
> template< class InputIt, class T, class BinaryOperationWithReturn >
>
> T accumulate(InputIt first, InputIt last, T init, BinaryOperationWithReturn
> op)
> {
> for (; first != last; ++first)
> init = op(`return`, init, *first);
> }
>
>
> Depending on how we define them, option 1 and 4 might require separate
> specialization / overload of the function being implemented. Option 2 is a
> new char (digraphs :) and, since symmetric, might be problematic to nest.
> Option 3 is either confusing or logical depending on how you approach it;
> it definitely needs explanation. Do you find any of these ok, or should we
> try more alternatives?
>
You're too caught up on the form of this stuff and not enough on the
functionality in question. It doesn't matter what syntax you use at this
point. The question is what behaviors are you trying to accomplish here?
The minimum necessary behavior is very simple: you cannot call a named
statement in the same way as a regular function. The syntax which invokes a
function call must not be able to invoke a named statement. And conversely,
the syntax which invokes a named statement must not also be able to be used
on a callable function.
The details of how that happens are less important than precisely what the
behavior will be.
Also note that, when I originally started working on this, I didn't even
> consider allowing to forward a PSE/NSE, as it's not required in most common
> use cases. Passing it is necessary but - if you find it a good idea - I'm
> okay with explicitly disabling std::forward<>() on these.
>
.... what would that mean? I mean, are these things even objects? What you
call a "PSE" looks like a lambda, which is an object. So I have the right
to get a pointer to it, right? Or pass it via `const&`.
So how exactly do you plan to forbid function A from passing it to function
B if you could pass it to function A to begin with?
*Nicol Bolas> Nobody goes specifies how many function calls are nested
> between where a function is taken and where it is called.*
> Nobody used to specify if a variable is going to be reassigned /
> destructed after a call, as that was the caller's business. Then we started
> to realize the benefits of move. We don't use move everywhere, only where
> it's reasonable.
>
No, the number of times you copy an object has usually been of some
importance to C++ programs. That's why `const&` exists; so that you don't
copy the object unless you need to. This was always something that was part
of API design; C++11 just added a few extra tricks.
I'm not saying everyone will use it - I don't even want everyone to use it.
> I see a limited scope for control flow-like statements, of which we tend to
> have many proposals. NSEs could bring you for..else, for..break,
> if_optional, accumulate with shortcut, and maybe some others that we don't
> yet foresee: that's the scope. Instead of separate proposals for these I
> suggest a language feature that moves these to the library.
>
So instead of having good, readable, easily digestible syntax like
`for/else` or whatever, we have difficult to comprehend syntax that
involves creating lambdas and other spurious syntax.
Generality has its place, but not at the cost of readability and such.
Lambdas exist to allow us to make simple functors. That's the purpose of
the feature. They are *not* for manipulating the control flow of a program
and they *certainly* are not for manipulating the control flow of non-local
code. My general feeling about lambdas is this: if you're grafting features
onto lambdas as a means to solve some deficiency in the language, then the
problem either is not worth solving or is best solved with a targeted
language feature.
And your `accumulate with shortcut` could be done *right now*, simply by
adding a new algorithm (`accumulate_until` or whatever), where the
predicate returns a product type of the new value and a boolean. And you'd
need a new algorithm *anyway*, since you don't want implementations of the
regular `std::accumulate` to be limited to the requirements of this
feature. So why go through the pain of this for something as simple as that?
Also note, a function that's aware of PSEs and need to delegate internally
> might as well use delegation to PSEs / NSEs. I think it's reasonable to
> expect the above to specify if the PSE is called directly.
>
>
> *Viacheslav Usov> The point is that the 'outer' function can call some
> other functions marked as noexcept, passing those PSE objects to them. And
> what is the effect of the PSE's return on those nested calls?*IF - and
> only if - we want to allow forwarding a PSE, then the PSE will return from
> the innermost function caling it - in this case, the inner function. Hence
> the outer function should be aware of this. Note that PSEs are not really
> designed or expected to be passed around this way. If you need an inner
> function-like object within a function that gets PSE and you want to pass
> the inner one the PSE, use a PSE/NSE for the inner function-like object as
> well.
>
>
> *Viacheslav Usov> Are you saying that both the PSE and the function, which
> is called with the PSE, shall be defined in the same translation unit?*Definitely.
> PSE body should be visible to the compiler when compiling the function that
> takes it (to avoid overhead from multiple return addresses); I'm okay if we
> want to make it visible to the calling function. To me, a PSE's operator()
> is basically a template.
>
> Thanks,
> -lorro
>
>
--
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/cacdb380-1062-4d0f-afe1-c65cea4494ae%40isocpp.org.
------=_Part_2546_1056738794.1487038221169
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, February 13, 2017 at 5:54:56 PM UTC-5, szollos.=
...@gmail.com 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">Hi,<br><br><i><b>Nicol Bolas> Now, this has an obvious hole: if `f=
` throws, then you leak memory.</b></i><br>Yes, it does. If you throw, it d=
oes - there's a workaround for that, as you correctly described. If you=
call a PSE/NSE, it *might* leak - there's still a workaround for that,=
as you described.</div></blockquote><div><br>You mean the workaround I sai=
d couldn't be used everywhere?<br><br></div><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">If `f' is a [[noreturn]] function, t=
hen we actually leak - and there's no workaround, correct me if I'm=
wrong.<br></div></blockquote><div><br>No, there is no "actual leak&qu=
ot;. Returning from a `[[noreturn]]` function is UB. And being undefined me=
ans that it is not defined whether it will leak or not.<br><br>If the funct=
ion transfers control elsewhere or terminates or whatever, then even the RA=
II version would "leak". But nobody cares because the application=
is being terminated or whatever.<br><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><i><b>Nicol Bolas> And the `return` ma=
y propagate out of any number of named statement functions. What's the =
difference?</b></i><br>It can only propagate out of NSEs/PSEs. It cannot pr=
opagate out of functions.</div></blockquote><div><br>But since they can nes=
t, the locality of exactly where a "return" codes is not immediat=
ely obvious.<br><br>Just like exceptions.<br><br>I don't know why you&#=
39;re so fundamentally against treating this as a specialized exception. It=
would solve <i>so many</i> of the problems with your idea: the inability o=
f code between the two points to interfere in the skipping process, the ina=
bility to have it `return` through arbitrary numbers of functions, the spec=
ific nature of these constructs (are they functions, if not, then what are =
they, are they objects, etc). The feature becomes <i>far</i> more useful on=
ce you use exception resolution as the foundation of it.<br><br>If performa=
nce is a concern, then for the cases you're most concerned about (every=
thing is inline and visible), I'm sure compilers can be smart enough to=
optimize it down to triviality. The syntax for such code can also be made =
more reasonable.<br><br>The only real problem with doing it this way is how=
to deal with the case of someone throwing one return type to a function wh=
ich returns a different, incompatible one. Since the circumstance is (nomin=
ally) a runtime construct, it would need to be a runtime error (like `termi=
nate`).<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">A code which itself doesn't use exception handling might call =
into a throwing function and receive an 'alternative return type' i=
n an 'alternative return path'. A code that itself doesn't call=
PSEs will never receive an alternative return type or get returned to an a=
lternative location even if it passes a PSE. I see this as a difference.<br=
></div></blockquote><div><br>But whether code calls a named statement or no=
t is not necessarily up to that function. So whether a function calls a nam=
ed statement is not necessarily known to the writer of that function.<br><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><i><b=
>Nicol Bolas> I consider it conceptually rude to be able to impose a `re=
turn` on a function. If that function asks
to allow you to return for it, that's fine. But it should be something=
=20
the function explicitly is written to permit. It should never be hidden=20
and it should never be imposed upon you without your will, knowledge, or
consent.<br></b></i>I'm okay with that restriction. I originally omitt=
ed explicit `take_return` to keep it brief, but there are multiple options =
here: (where `op` might be a PSE)<br><div style=3D"background-color:rgb(250=
,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1px=
"><code><div><span style=3D"color:#800">//option 1</span><span style=3D"col=
or:#000"> - explicitly name the continuations that can be taken<br></span><=
span><span><span style=3D"color:#008">template</span></span><span><span sty=
le=3D"color:#660"><</span></span><span style=3D"color:#000"> </span><spa=
n><span style=3D"color:#008">class</span></span><span style=3D"color:#000">=
</span><span style=3D"color:#606">InputIt</span><span style=3D"color:#660"=
>,</span><span style=3D"color:#000"> </span><span><span style=3D"color:#008=
">class</span></span><span style=3D"color:#000"> T</span><span style=3D"col=
or:#660">,</span><span style=3D"color:#000"> </span><span><span style=3D"co=
lor:#008">class</span></span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">BinaryOperation</span><span style=3D"color:#000"> </span><s=
pan><span style=3D"color:#660">></span></span><span style=3D"color:#000"=
><br></span><p><span style=3D"color:#000">T accumulate</span><span><span st=
yle=3D"color:#660">(</span></span><span style=3D"color:#606">InputIt</span>=
<span style=3D"color:#000"> first</span><span style=3D"color:#660">,</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#606">InputIt</span=
><span style=3D"color:#000"> </span><span style=3D"color:#008">last</span><=
span style=3D"color:#660">,</span><span style=3D"color:#000"> T init</span>=
<span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span=
><span style=3D"color:#606">BinaryOperation</span><span style=3D"color:#000=
"> op</span><span><span style=3D"color:#660">)</span></span><span></span></=
span><span style=3D"color:#000"><br></span><span style=3D"color:#660">{</sp=
an><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color=
:#008">for</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
60">(;</span><span style=3D"color:#000"> first </span><span style=3D"color:=
#660">!=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#0=
08">last</span><span style=3D"color:#660">;</span><span style=3D"color:#000=
"> </span><span style=3D"color:#660">++</span><span style=3D"color:#000">fi=
rst</span><span style=3D"color:#660">)</span><span style=3D"color:#000"><br=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 init </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> op</span><span style=3D"color:#080"><retu=
rn></span><span style=3D"color:#660">(</span><span style=3D"color:#000">=
init</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660">*</span><span style=3D"color:#000">first</=
span><span style=3D"color:#660">);</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#660">}</span><span style=3D"color:#000"><br></spa=
n></p><span style=3D"color:#000"><br></span><span style=3D"color:#660">/</s=
pan></span><span><span style=3D"color:#000"><code><span style=3D"color:#800=
">/option 2</span><span style=3D"color:#000"> - `allow taking here`<br></sp=
an><span><span><span style=3D"color:#008">template</span></span><span><span=
style=3D"color:#660"><</span></span><span style=3D"color:#000"> </span>=
<span><span style=3D"color:#008">class</span></span><span style=3D"color:#0=
00"> </span><span style=3D"color:#606">InputIt</span><span style=3D"color:#=
660">,</span><span style=3D"color:#000"> </span><span><span style=3D"color:=
#008">class</span></span><span style=3D"color:#000"> T</span><span style=3D=
"color:#660">,</span><span style=3D"color:#000"> </span><span><span style=
=3D"color:#008">class</span></span><span style=3D"color:#000"> </span><span=
style=3D"color:#606">BinaryOperation</span><span style=3D"color:#000"> </s=
pan><span><span style=3D"color:#660">></span></span><span style=3D"color=
:#000"><br></span><p><span style=3D"color:#000">T accumulate</span><span><s=
pan style=3D"color:#660">(</span></span><span style=3D"color:#606">InputIt<=
/span><span style=3D"color:#000"> first</span><span style=3D"color:#660">,<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#606">InputIt=
</span><span style=3D"color:#000"> </span><span style=3D"color:#008">last</=
span><span style=3D"color:#660">,</span><span style=3D"color:#000"> T init<=
/span><span><span style=3D"color:#660">,</span><span style=3D"color:#000"> =
</span><span style=3D"color:#606">BinaryOperation</span><span style=3D"colo=
r:#000"> op</span><span><span style=3D"color:#660">)</span></span><span></s=
pan></span><span style=3D"color:#000"><br></span><span style=3D"color:#660"=
>{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D=
"color:#008">for</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#660">(;</span><span style=3D"color:#000"> first </span><span style=3D"=
color:#660">!=3D</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#008">last</span><span style=3D"color:#660">;</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#660">++</span><span style=3D"color:#0=
00">first</span><span style=3D"color:#660">)</span><span style=3D"color:#00=
0"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 init </span><span style=3D"color:#660">=
=3D</span><span style=3D"color:#000"> `op</span><span style=3D"color:#660">=
(</span><span style=3D"color:#000">init</span><span style=3D"color:#660">,<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">*</span=
><span style=3D"color:#000">first</span><span style=3D"color:#660">)`;</spa=
n><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</span>=
<span style=3D"color:#000"><br></span></p></span></code></span></span><br><=
code><span><span style=3D"color:#660">/</span></span><span><span style=3D"c=
olor:#000"><code><span style=3D"color:#800">/option 3</span><span style=3D"=
color:#000"> - allow PSE only if inside a SE<br></span><span><span><span st=
yle=3D"color:#008">template</span></span><span><span style=3D"color:#660">&=
lt;</span></span><span style=3D"color:#000"> </span><span><span style=3D"co=
lor:#008">class</span></span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">InputIt</span><span style=3D"color:#660">,</span><span styl=
e=3D"color:#000"> </span><span><span style=3D"color:#008">class</span></spa=
n><span style=3D"color:#000"> T</span><span style=3D"color:#660">,</span><s=
pan style=3D"color:#000"> </span><span><span style=3D"color:#008">class</sp=
an></span><span style=3D"color:#000"> </span><span style=3D"color:#606">Bin=
aryOperation</span><span style=3D"color:#000"> </span><span><span style=3D"=
color:#660">></span></span><span style=3D"color:#000"><br></span><p><spa=
n style=3D"color:#000">T accumulate</span><span><span style=3D"color:#660">=
(</span></span><span style=3D"color:#606">InputIt</span><span style=3D"colo=
r:#000"> first</span><span style=3D"color:#660">,</span><span style=3D"colo=
r:#000"> </span><span style=3D"color:#606">InputIt</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#008">last</span><span style=3D"color=
:#660">,</span><span style=3D"color:#000"> T init</span><span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#606">BinaryOperation</span><span style=3D"color:#000"> op</span><span=
><span style=3D"color:#660">)</span></span><span></span></span><span style=
=3D"color:#000"><br></span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008">for</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#660">(;</span><=
span style=3D"color:#000"> first </span><span style=3D"color:#660">!=3D</sp=
an><span style=3D"color:#000"> </span><span style=3D"color:#008">last</span=
><span style=3D"color:#660">;</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#660">++</span><span style=3D"color:#000">first</span><spa=
n style=3D"color:#660">)</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0=
=C2=A0 =C2=A0 init </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> ({ op</span><span style=3D"color:#660">(</span><span style=
=3D"color:#000">init</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">*</span><span style=3D"c=
olor:#000">first</span><span style=3D"color:#660">) });</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#660">}</span><span style=
=3D"color:#000"><br></span><br><code></code></p><div><code><code><span><spa=
n style=3D"color:#660">/</span></span><span><span style=3D"color:#000"><cod=
e><span style=3D"color:#800">/option 4</span><span style=3D"color:#000"> - =
convert control flow statement to [[noreturn]] void fn<br></span><span><spa=
n><span style=3D"color:#008">template</span></span><span><span style=3D"col=
or:#660"><</span></span><span style=3D"color:#000"> </span><span><span s=
tyle=3D"color:#008">class</span></span><span style=3D"color:#000"> </span><=
span style=3D"color:#606">InputIt</span><span style=3D"color:#660">,</span>=
<span style=3D"color:#000"> </span><span><span style=3D"color:#008">class</=
span></span><span style=3D"color:#000"> T</span><span style=3D"color:#660">=
,</span><span style=3D"color:#000"> </span><span><span style=3D"color:#008"=
>class</span></span><span style=3D"color:#000"> </span><span style=3D"color=
:#606">BinaryOperationWithReturn</span><span style=3D"color:#000"> </span><=
span><span style=3D"color:#660">></span></span><span style=3D"color:#000=
"><br></span><p><span style=3D"color:#000">T accumulate</span><span><span s=
tyle=3D"color:#660">(</span></span><span style=3D"color:#606">InputIt</span=
><span style=3D"color:#000"> first</span><span style=3D"color:#660">,</span=
><span style=3D"color:#000"> </span><span style=3D"color:#606">InputIt</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#008">last</span>=
<span style=3D"color:#660">,</span><span style=3D"color:#000"> T init</span=
><span><span style=3D"color:#660">,</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#606">BinaryOperation</span><span style=3D"color:#00=
0">WithReturn op</span><span><span style=3D"color:#660">)</span></span><spa=
n></span></span><span style=3D"color:#000"><br></span><span style=3D"color:=
#660">{</span><span style=3D"color:#000"><br>=C2=A0 =C2=A0 </span><span sty=
le=3D"color:#008">for</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">(;</span><span style=3D"color:#000"> first </span><span sty=
le=3D"color:#660">!=3D</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">last</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">++</span><span style=3D"=
color:#000">first</span><span style=3D"color:#660">)</span><span style=3D"c=
olor:#000"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 init </span><span style=3D"color=
:#660">=3D</span><span style=3D"color:#000"> op</span><span style=3D"color:=
#660">(</span><span style=3D"color:#000">`return`, init</span><span style=
=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">*</span><span style=3D"color:#000">first</span><span style=3D"co=
lor:#660">);</span><span style=3D"color:#000"><br></span><span style=3D"col=
or:#660">}</span><span style=3D"color:#000"><br></span></p></span></code></=
span></span></code></code></div><p></p></span></code></span></span></code><=
/div></code></div><br>Depending on how we define them, option 1 and 4 might=
require separate specialization / overload of the function being implement=
ed. Option 2 is a new char (digraphs :) and, since symmetric, might be prob=
lematic to nest. Option 3 is either confusing or logical depending on how y=
ou approach it; it definitely needs explanation. Do you find any of these o=
k, or should we try more alternatives?<br></div></blockquote><div><br>You&#=
39;re too caught up on the form of this stuff and not enough on the functio=
nality in question. It doesn't matter what syntax you use at this point=
.. The question is what behaviors are you trying to accomplish here?<br><br>=
The minimum necessary behavior is very simple: you cannot call a named stat=
ement in the same way as a regular function. The syntax which invokes a fun=
ction call must not be able to invoke a named statement. And conversely, th=
e syntax which invokes a named statement must not also be able to be used o=
n a callable function.<br><br>The details of how that happens are less impo=
rtant than precisely what the behavior will be.<br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Also note that, when I orig=
inally started working on this, I didn't even consider allowing to forw=
ard a PSE/NSE, as it's not required in most common use cases. Passing i=
t is necessary but - if you find it a good idea - I'm okay with explici=
tly disabling std::forward<>() on these.<br></div></blockquote><div><=
br>... what would that mean? I mean, are these things even objects? What yo=
u call a "PSE" looks like a lambda, which is an object. So I have=
the right to get a pointer to it, right? Or pass it via `const&`.<br><=
br>So how exactly do you plan to forbid function A from passing it to funct=
ion B if you could pass it to function A to begin with?<br><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><i><b>Nicol Bolas&g=
t; Nobody goes specifies how many function calls are nested between where a=
function is taken and where it is called.</b></i><br>Nobody used to specif=
y if a variable is going to be reassigned / destructed after a call, as tha=
t was the caller's business. Then we started to realize the benefits of=
move. We don't use move everywhere, only where it's reasonable.<br=
></div></blockquote><div><br>No, the number of times you copy an object has=
usually been of some importance to C++ programs. That's why `const&=
;` exists; so that you don't copy the object unless you need to. This w=
as always something that was part of API design; C++11 just added a few ext=
ra tricks.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">I'm not saying everyone will use it - I don't even want =
everyone to use it. I see a limited scope for control flow-like statements,=
of which we tend to have many proposals. NSEs could bring you for..else, f=
or..break, if_optional, accumulate with shortcut, and maybe some others tha=
t we don't yet foresee: that's the scope. Instead of separate propo=
sals for these I suggest a language feature that moves these to the library=
..</div></blockquote><div><br>So instead of having good, readable, easily di=
gestible syntax like `for/else` or=20
whatever, we have difficult to comprehend syntax that involves creating=20
lambdas and other spurious syntax.<br><br>Generality has its place, but not=
at the cost of readability and such.<br><br>Lambdas exist to allow us to m=
ake simple functors. That's the purpose of the feature. They are <i>not=
</i> for manipulating the control flow of a program and they <i>certainly</=
i> are not for manipulating the control flow of non-local code. My general =
feeling about lambdas is this: if you're grafting features onto lambdas=
as a means to solve some deficiency in the language, then the problem eith=
er is not worth solving or is best solved with a targeted language feature.=
<br><br>And your `accumulate with shortcut` could be done <i>right now</i>,=
simply by adding a new algorithm (`accumulate_until` or whatever), where t=
he predicate returns a product type of the new value and a boolean. And you=
'd need a new algorithm <i>anyway</i>, since you don't want impleme=
ntations of the regular `std::accumulate` to be limited to the requirements=
of this feature. So why go through the pain of this for something as simpl=
e as that?<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">Also note, a function that's aware of PSEs and need to deleg=
ate internally might as well use delegation to PSEs / NSEs. I think it'=
s reasonable to expect the above to specify if the PSE is called directly.<=
br><br><i><b><span><span style=3D"color:rgb(34,34,34)">Viacheslav </span></=
span>Usov> The point is that the 'outer' function can call some =
other functions=20
marked as noexcept, passing those PSE objects to=C2=A0them. And what is the=
=20
effect of the PSE's return on those nested calls?<br></b></i>IF - and o=
nly if - we want to allow forwarding a PSE, then the PSE will return from t=
he innermost function caling it - in this case, the inner function. Hence t=
he outer function should be aware of this. Note that PSEs are not really de=
signed or expected to be passed around this way. If you need an inner funct=
ion-like object within a function that gets PSE and you want to pass the in=
ner one the PSE, use a PSE/NSE for the inner function-like object as well.<=
br><br><i><b><span><span style=3D"color:rgb(34,34,34)">Viacheslav </span></=
span>Usov> Are you saying that both the PSE and the function, which is c=
alled with the PSE, shall be defined in the same translation unit?<br></b><=
/i>Definitely. PSE body should be visible to the compiler when compiling th=
e function that takes it (to avoid overhead from multiple return addresses)=
; I'm okay if we want to make it visible to the calling function. To me=
, a PSE's operator() is basically a template.<br><br>Thanks,<br>-lorro<=
br><br></div></blockquote></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/cacdb380-1062-4d0f-afe1-c65cea4494ae%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cacdb380-1062-4d0f-afe1-c65cea4494ae=
%40isocpp.org</a>.<br />
------=_Part_2546_1056738794.1487038221169--
------=_Part_2545_1431843424.1487038221168--
.
Author: 3dw4rd@verizon.net
Date: Wed, 22 Feb 2017 15:26:08 -0800 (PST)
Raw View
------=_Part_1677_1887550995.1487805968851
Content-Type: multipart/alternative;
boundary="----=_Part_1678_1414692608.1487805968853"
------=_Part_1678_1414692608.1487805968853
Content-Type: text/plain; charset=UTF-8
On Monday, February 6, 2017 at 10:46:06 PM UTC-5, Tony V E wrote:
>
> I highly recommend, for almost any proposal, to include "before and after
> tables" (I think the committee has a some nick name for these), showing
> what you would currently need to write using C++17 on the left, and how it
> could be rewritten in C++20 using your proposal on the right.
>
> Just focusing on the aspect of statement expressions now existing in
various implementations (no params or templates)
and highlighting the real use case: initialization without scope leak.
I think this has a real chance of being useful and accepted.
Note that C++17 just put in initialization in if and switch for this reason.
In that light, this should work well with that feature and really be a
natural extension of it.
OLD:
{
Tp s{};
for (int k = 0; k < 3; ++k)
s += v[k];
if (s.useable())
do_a_thing(s);
}
NEW:
if (foo = ({Tp s{}; for(int k = 0; k < 3; ++k) s += v[k]; s}); foo.useable
())
do_a_thing(foo);
Decisions and creations of things are limited to the scope of the if.
Also consider selection:
OLD:
auto Ls_nint = Tp{0};
if (x != Tp{0})
{
auto w = std::log(std::complex<Tp>(x));
std::real(polylog_exp_neg_int(n, w));
Ls_nint = Tp{0};
}
NEW:
auto Ls_nint = x == Tp{0}
? Tp{0}
: ({auto w = std::log(std::complex<Tp>(x));
std::real(polylog_exp_neg_int(n, w));});
The latter only defines w if needed. Ls_nint only gets initialized once.
Consider construction:
OLD:
Matrix(const Matrix& a, const Matrix& b)
m_A() // Might be expensive.
{
if (!valid(a))
throw badmatrix("A");
else if (!valid(b))
throw badmatrix("B");
else
{
auto tmp = a * b;
if (!valid(b))
throw badmatrix("B");
this->m_A = tmp;
}
}
NEW:
Matrix(const Matrix& a, const Matrix& b)
: m_A(!valid(a) ? throw badmatrix("A")
: !valid(b) ? throw badmatrix("B")
: ({auto tmp(a);
tmp *= b;
valid(tmp) ? tmp : throw badmatrix("A*B"
);})
{ }
Maybe that's not as big a big win.
--
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/c1b3fd23-9a0b-449f-9cd7-c87f64558e58%40isocpp.org.
------=_Part_1678_1414692608.1487805968853
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, February 6, 2017 at 10:46:06 PM UTC-5, =
Tony V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"b=
ackground-color:rgb(255,255,255);line-height:initial" lang=3D"en-US"> =
=
<div style=3D"width:100%;font-size:initial;font-family:Calibri,'Sl=
ate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;=
background-color:rgb(255,255,255)">I highly recommend, for almost any propo=
sal, to include "before and after tables" (I think the committee =
has a some nick name for these), showing what you would currently need to w=
rite using C++17 on the left, and how it could be rewritten in C++20 using =
your proposal on the right. </div><table style=3D"background-color:white;bo=
rder-spacing:0px" width=3D"100%"><tbody><tr><td colspan=3D"2" style=3D"font=
-size:initial;text-align:initial;background-color:rgb(255,255,255)"><br></t=
d></tr></tbody></table></div></blockquote><div>Just focusing on the aspect =
of statement expressions now existing in various implementations (no params=
or templates)<br>and highlighting the real use case: initialization withou=
t scope leak.<br>I think this has a real chance of being useful and accepte=
d.<br>Note that C++17 just put in initialization in if and switch for this =
reason.<br>In that light, this should work well with that feature and reall=
y be a natural extension of it.<br><br>OLD:<br><div style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">=C2=A0 </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #=
606;" class=3D"styled-by-prettify">Tp</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> s</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">{};</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">for</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> k </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> k </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">3</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">++</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">k</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 s </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">+=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> v</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">[</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">k</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">];</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">if</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"styled-by-prettify">s</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">useable</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">())</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 do_a_thing</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">s</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br></span></div></code></div><br><br>NEW:<br><=
div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 1=
87, 187); border-style: solid; border-width: 1px; overflow-wrap: break-word=
;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprett=
yprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0 </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><sp=
an 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"styled-by-prettify">foo </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">({</span><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">Tp</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
s</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{};</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">for</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> k </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prett=
ify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> k </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #066;" class=3D"styled-by-prettify">3</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">++</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">k</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">+=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> v</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">k</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">];</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> s</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">});</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">useable</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">())</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 do_a_=
thing</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">foo</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span></div></code>=
</div><br><br>Decisions and creations of things are limited to the scope of=
the if.<br><br>Also consider selection:<br>OLD:<br><div style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprin=
t"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #000;" class=3D"styled-by-prettify">=C2=A0 </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Ls_nint</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">T=
p</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><=
span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">x </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">!=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Tp</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">})</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> w </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">l=
og</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">complex</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">Tp</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">>(</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">x</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">));</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">real</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">polylog=
_exp_neg_int</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">n</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> w</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">));</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">Ls_nint</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Tp</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><s=
pan 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 styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span></div></code=
></div><br><br>NEW:<br><div style=3D"background-color: rgb(250, 250, 250); =
border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; o=
verflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint=
"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"style=
d-by-prettify">=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ls_=
nint</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> x </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">Tp</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #066;" class=3D"sty=
led-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">?</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;"=
class=3D"styled-by-prettify">Tp</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</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: #008;" class=3D=
"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> w </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">log</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">complex</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify"><</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Tp</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">>(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">x</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">));</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">real</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">polylog_exp_neg_int</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">n</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> w</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">));});</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br></span></div></code></div><br><br>The latter only defines =
w if needed. Ls_nint only gets initialized once.<br><br>Consider constructi=
on:<br>OLD:<br><div style=3D"background-color: rgb(250, 250, 250); border-c=
olor: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-=
wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">=C2=A0 </span><span style=3D"color: #606;" class=3D"styled-by-pretti=
fy">Matrix</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">Matrix</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">const</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">Matrix</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 m_A</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #800;" class=3D"styled-by-prettify">// Might be expensive.</span><span s=
tyle=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"><br>=C2=A0 =C2=A0 </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(!</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">valid</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">a</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">))</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">throw</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> badmatrix</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #080;" class=3D"styled-by-prettify">&qu=
ot;A"</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>else</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">if</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"styled-by-prettify">valid</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">b</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">))</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">throw</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> badmatrix</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-=
prettify">"B"</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">else</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> tmp </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> a </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(!</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">valid</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">b</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">))</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">throw</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> badmatrix</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #080;" class=3D"styl=
ed-by-prettify">"B"</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">this</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">-></span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">m_A </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> tmp</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span></div=
></code></div><br><br>NEW:<br><div style=3D"background-color: rgb(250, 250,=
250); border-color: rgb(187, 187, 187); border-style: solid; border-width:=
1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=3D"pret=
typrint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">=C2=A0 </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Matrix</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Matrix=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Matrix</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">&</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> b</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</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"> m_A</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(!</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">valid</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">a</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">?</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">throw</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> badmatrix</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #080;" class=3D"styled-by-prettify">"A"</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">:</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"styled-by-prettify=
">valid</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">b</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)</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"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">throw</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> badmatrix</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #080;" class=3D"styled-by-pret=
tify">"B"</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">({</span><span style=3D"color: #008;" class=3D"styled-by-prettify">a=
uto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> tmp</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">a</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 tmp </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">*=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 valid</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">tmp</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">)</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"styled-by-prettify"> tmp </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">throw</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> badmatrix</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">"A*B"</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">);})</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r><br></span></div></code></div><br><br>Maybe that's not as big a big w=
in.<br>=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/c1b3fd23-9a0b-449f-9cd7-c87f64558e58%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c1b3fd23-9a0b-449f-9cd7-c87f64558e58=
%40isocpp.org</a>.<br />
------=_Part_1678_1414692608.1487805968853--
------=_Part_1677_1887550995.1487805968851--
.
Author: =?UTF-8?Q?Micha=C5=82_Dominiak?= <griwes@griwes.info>
Date: Wed, 22 Feb 2017 23:33:07 +0000
Raw View
--94eb2c05ae02d99d71054926eb5b
Content-Type: text/plain; charset=UTF-8
How is any of those cases not solved naturally by just using an IIFE?
There's exactly one problem with IIFEs and that's returning from an outer
function, but that has nothing to do with any of the above examples.
On Thu, Feb 23, 2017 at 12:26 AM <3dw4rd@verizon.net> wrote:
>
>
> On Monday, February 6, 2017 at 10:46:06 PM UTC-5, Tony V E wrote:
>
> I highly recommend, for almost any proposal, to include "before and after
> tables" (I think the committee has a some nick name for these), showing
> what you would currently need to write using C++17 on the left, and how it
> could be rewritten in C++20 using your proposal on the right.
>
> Just focusing on the aspect of statement expressions now existing in
> various implementations (no params or templates)
> and highlighting the real use case: initialization without scope leak.
> I think this has a real chance of being useful and accepted.
> Note that C++17 just put in initialization in if and switch for this
> reason.
> In that light, this should work well with that feature and really be a
> natural extension of it.
>
> OLD:
> {
> Tp s{};
> for (int k = 0; k < 3; ++k)
> s += v[k];
> if (s.useable())
> do_a_thing(s);
> }
>
>
>
> NEW:
> if (foo = ({Tp s{}; for(int k = 0; k < 3; ++k) s += v[k]; s}); foo.
> useable())
> do_a_thing(foo);
>
>
>
> Decisions and creations of things are limited to the scope of the if.
>
> Also consider selection:
> OLD:
> auto Ls_nint = Tp{0};
> if (x != Tp{0})
> {
> auto w = std::log(std::complex<Tp>(x));
> std::real(polylog_exp_neg_int(n, w));
> Ls_nint = Tp{0};
> }
>
>
>
> NEW:
> auto Ls_nint = x == Tp{0}
> ? Tp{0}
> : ({auto w = std::log(std::complex<Tp>(x));
> std::real(polylog_exp_neg_int(n, w));});
>
>
>
> The latter only defines w if needed. Ls_nint only gets initialized once.
>
> Consider construction:
> OLD:
> Matrix(const Matrix& a, const Matrix& b)
> m_A() // Might be expensive.
> {
> if (!valid(a))
> throw badmatrix("A");
> else if (!valid(b))
> throw badmatrix("B");
> else
> {
> auto tmp = a * b;
> if (!valid(b))
> throw badmatrix("B");
> this->m_A = tmp;
> }
> }
>
>
>
> NEW:
> Matrix(const Matrix& a, const Matrix& b)
> : m_A(!valid(a) ? throw badmatrix("A")
> : !valid(b) ? throw badmatrix("B")
> : ({auto tmp(a);
> tmp *= b;
> valid(tmp) ? tmp : throw badmatrix("A*B"
> );})
> { }
>
>
>
> Maybe that's not as big a big win.
>
>
> --
> 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/c1b3fd23-9a0b-449f-9cd7-c87f64558e58%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c1b3fd23-9a0b-449f-9cd7-c87f64558e58%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
--
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/CAPCFJdQsC%3D4KMesOeDv5vJ6UQs0W7-23tx%3DSLVaTjrASGxK6zg%40mail.gmail.com.
--94eb2c05ae02d99d71054926eb5b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">How is any of those cases not solved naturally by just usi=
ng an IIFE? There's exactly one problem with IIFEs and that's retur=
ning from an outer function, but that has nothing to do with any of the abo=
ve examples.</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, F=
eb 23, 2017 at 12:26 AM <<a href=3D"mailto:3dw4rd@verizon.net">3dw4rd@ve=
rizon.net</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr" class=3D"gmail_msg"><br class=3D"gmail_msg"><br class=3D"gmail_msg=
">On Monday, February 6, 2017 at 10:46:06 PM UTC-5, Tony V E wrote:<blockqu=
ote class=3D"gmail_quote gmail_msg" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div style=3D"background-color:rg=
b(255,255,255);line-height:initial" lang=3D"en-US" class=3D"gmail_msg"> =
=
<div style=3D"width:100%;font-size:initial;font-family:Calibri,'=
Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initia=
l;background-color:rgb(255,255,255)" class=3D"gmail_msg">I highly recommend=
, for almost any proposal, to include "before and after tables" (=
I think the committee has a some nick name for these), showing what you wou=
ld currently need to write using C++17 on the left, and how it could be rew=
ritten in C++20 using your proposal on the right. </div><table style=3D"bac=
kground-color:white;border-spacing:0px" width=3D"100%" class=3D"gmail_msg">=
<tbody class=3D"gmail_msg"><tr class=3D"gmail_msg"><td colspan=3D"2" style=
=3D"font-size:initial;text-align:initial;background-color:rgb(255,255,255)"=
class=3D"gmail_msg"><br class=3D"gmail_msg"></td></tr></tbody></table></di=
v></blockquote></div><div dir=3D"ltr" class=3D"gmail_msg"><div class=3D"gma=
il_msg">Just focusing on the aspect of statement expressions now existing i=
n various implementations (no params or templates)<br class=3D"gmail_msg">a=
nd highlighting the real use case: initialization without scope leak.<br cl=
ass=3D"gmail_msg">I think this has a real chance of being useful and accept=
ed.<br class=3D"gmail_msg">Note that C++17 just put in initialization in if=
and switch for this reason.<br class=3D"gmail_msg">In that light, this sho=
uld work well with that feature and really be a natural extension of it.<br=
class=3D"gmail_msg"><br class=3D"gmail_msg">OLD:<br class=3D"gmail_msg"><d=
iv style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187)=
;border-style:solid;border-width:1px" class=3D"m_-7631491069799626584pretty=
print gmail_msg"><code class=3D"m_-7631491069799626584prettyprint gmail_msg=
"><div class=3D"m_-7631491069799626584subprettyprint gmail_msg"><span style=
=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg=
">=C2=A0 </span><span style=3D"color:#660" class=3D"m_-7631491069799626584s=
tyled-by-prettify gmail_msg">{</span><span style=3D"color:#000" class=3D"m_=
-7631491069799626584styled-by-prettify gmail_msg"><br class=3D"gmail_msg">=
=C2=A0 =C2=A0 </span><span style=3D"color:#606" class=3D"m_-763149106979962=
6584styled-by-prettify gmail_msg">Tp</span><span style=3D"color:#000" class=
=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> s</span><span styl=
e=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_ms=
g">{};</span><span style=3D"color:#000" class=3D"m_-7631491069799626584styl=
ed-by-prettify gmail_msg"><br class=3D"gmail_msg">=C2=A0 =C2=A0 </span><spa=
n style=3D"color:#008" class=3D"m_-7631491069799626584styled-by-prettify gm=
ail_msg">for</span><span style=3D"color:#000" class=3D"m_-76314910697996265=
84styled-by-prettify gmail_msg"> </span><span style=3D"color:#660" class=3D=
"m_-7631491069799626584styled-by-prettify gmail_msg">(</span><span style=3D=
"color:#008" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">i=
nt</span><span style=3D"color:#000" class=3D"m_-7631491069799626584styled-b=
y-prettify gmail_msg"> k </span><span style=3D"color:#660" class=3D"m_-7631=
491069799626584styled-by-prettify gmail_msg">=3D</span><span style=3D"color=
:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> </span=
><span style=3D"color:#066" class=3D"m_-7631491069799626584styled-by-pretti=
fy gmail_msg">0</span><span style=3D"color:#660" class=3D"m_-76314910697996=
26584styled-by-prettify gmail_msg">;</span><span style=3D"color:#000" class=
=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> k </span><span sty=
le=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_m=
sg"><</span><span style=3D"color:#000" class=3D"m_-7631491069799626584st=
yled-by-prettify gmail_msg"> </span><span style=3D"color:#066" class=3D"m_-=
7631491069799626584styled-by-prettify gmail_msg">3</span><span style=3D"col=
or:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">;</sp=
an><span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-pret=
tify gmail_msg"> </span><span style=3D"color:#660" class=3D"m_-763149106979=
9626584styled-by-prettify gmail_msg">++</span><span style=3D"color:#000" cl=
ass=3D"m_-7631491069799626584styled-by-prettify gmail_msg">k</span><span st=
yle=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_=
msg">)</span><span style=3D"color:#000" class=3D"m_-7631491069799626584styl=
ed-by-prettify gmail_msg"><br class=3D"gmail_msg">=C2=A0 =C2=A0 =C2=A0 s </=
span><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-pr=
ettify gmail_msg">+=3D</span><span style=3D"color:#000" class=3D"m_-7631491=
069799626584styled-by-prettify gmail_msg"> v</span><span style=3D"color:#66=
0" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">[</span><sp=
an style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify g=
mail_msg">k</span><span style=3D"color:#660" class=3D"m_-763149106979962658=
4styled-by-prettify gmail_msg">];</span><span style=3D"color:#000" class=3D=
"m_-7631491069799626584styled-by-prettify gmail_msg"><br class=3D"gmail_msg=
">=C2=A0 =C2=A0 </span><span style=3D"color:#008" class=3D"m_-7631491069799=
626584styled-by-prettify gmail_msg">if</span><span style=3D"color:#000" cla=
ss=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> </span><span sty=
le=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_m=
sg">(</span><span style=3D"color:#000" class=3D"m_-7631491069799626584style=
d-by-prettify gmail_msg">s</span><span style=3D"color:#660" class=3D"m_-763=
1491069799626584styled-by-prettify gmail_msg">.</span><span style=3D"color:=
#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">useable<=
/span><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-p=
rettify gmail_msg">())</span><span style=3D"color:#000" class=3D"m_-7631491=
069799626584styled-by-prettify gmail_msg"><br class=3D"gmail_msg">=C2=A0 =
=C2=A0 =C2=A0 do_a_thing</span><span style=3D"color:#660" class=3D"m_-76314=
91069799626584styled-by-prettify gmail_msg">(</span><span style=3D"color:#0=
00" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">s</span><s=
pan style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify =
gmail_msg">);</span><span style=3D"color:#000" class=3D"m_-7631491069799626=
584styled-by-prettify gmail_msg"><br class=3D"gmail_msg">=C2=A0 </span><spa=
n style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gm=
ail_msg">}</span><span style=3D"color:#000" class=3D"m_-7631491069799626584=
styled-by-prettify gmail_msg"><br class=3D"gmail_msg"><br class=3D"gmail_ms=
g"></span></div></code></div><br class=3D"gmail_msg"><br class=3D"gmail_msg=
">NEW:<br class=3D"gmail_msg"><div style=3D"background-color:rgb(250,250,25=
0);border-color:rgb(187,187,187);border-style:solid;border-width:1px" class=
=3D"m_-7631491069799626584prettyprint gmail_msg"><code class=3D"m_-76314910=
69799626584prettyprint gmail_msg"><div class=3D"m_-7631491069799626584subpr=
ettyprint gmail_msg"><span style=3D"color:#000" class=3D"m_-763149106979962=
6584styled-by-prettify gmail_msg">=C2=A0 </span><span style=3D"color:#008" =
class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">if</span><span=
style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gma=
il_msg"> </span><span style=3D"color:#660" class=3D"m_-7631491069799626584s=
tyled-by-prettify gmail_msg">(</span><span style=3D"color:#000" class=3D"m_=
-7631491069799626584styled-by-prettify gmail_msg">foo </span><span style=3D=
"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">=
=3D</span><span style=3D"color:#000" class=3D"m_-7631491069799626584styled-=
by-prettify gmail_msg"> </span><span style=3D"color:#660" class=3D"m_-76314=
91069799626584styled-by-prettify gmail_msg">({</span><span style=3D"color:#=
606" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">Tp</span>=
<span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettif=
y gmail_msg"> s</span><span style=3D"color:#660" class=3D"m_-76314910697996=
26584styled-by-prettify gmail_msg">{};</span><span style=3D"color:#000" cla=
ss=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> </span><span sty=
le=3D"color:#008" class=3D"m_-7631491069799626584styled-by-prettify gmail_m=
sg">for</span><span style=3D"color:#660" class=3D"m_-7631491069799626584sty=
led-by-prettify gmail_msg">(</span><span style=3D"color:#008" class=3D"m_-7=
631491069799626584styled-by-prettify gmail_msg">int</span><span style=3D"co=
lor:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> k <=
/span><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-p=
rettify gmail_msg">=3D</span><span style=3D"color:#000" class=3D"m_-7631491=
069799626584styled-by-prettify gmail_msg"> </span><span style=3D"color:#066=
" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">0</span><spa=
n style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gm=
ail_msg">;</span><span style=3D"color:#000" class=3D"m_-7631491069799626584=
styled-by-prettify gmail_msg"> k </span><span style=3D"color:#660" class=3D=
"m_-7631491069799626584styled-by-prettify gmail_msg"><</span><span style=
=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg=
"> </span><span style=3D"color:#066" class=3D"m_-7631491069799626584styled-=
by-prettify gmail_msg">3</span><span style=3D"color:#660" class=3D"m_-76314=
91069799626584styled-by-prettify gmail_msg">;</span><span style=3D"color:#0=
00" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> </span><s=
pan style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify =
gmail_msg">++</span><span style=3D"color:#000" class=3D"m_-7631491069799626=
584styled-by-prettify gmail_msg">k</span><span style=3D"color:#660" class=
=3D"m_-7631491069799626584styled-by-prettify gmail_msg">)</span><span style=
=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg=
"> s </span><span style=3D"color:#660" class=3D"m_-7631491069799626584style=
d-by-prettify gmail_msg">+=3D</span><span style=3D"color:#000" class=3D"m_-=
7631491069799626584styled-by-prettify gmail_msg"> v</span><span style=3D"co=
lor:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">[</s=
pan><span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-pre=
ttify gmail_msg">k</span><span style=3D"color:#660" class=3D"m_-76314910697=
99626584styled-by-prettify gmail_msg">];</span><span style=3D"color:#000" c=
lass=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> s</span><span =
style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmai=
l_msg">});</span><span style=3D"color:#000" class=3D"m_-7631491069799626584=
styled-by-prettify gmail_msg"> foo</span><span style=3D"color:#660" class=
=3D"m_-7631491069799626584styled-by-prettify gmail_msg">.</span><span style=
=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg=
">useable</span><span style=3D"color:#660" class=3D"m_-7631491069799626584s=
tyled-by-prettify gmail_msg">())</span><span style=3D"color:#000" class=3D"=
m_-7631491069799626584styled-by-prettify gmail_msg"><br class=3D"gmail_msg"=
>=C2=A0 =C2=A0 do_a_thing</span><span style=3D"color:#660" class=3D"m_-7631=
491069799626584styled-by-prettify gmail_msg">(</span><span style=3D"color:#=
000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">foo</span=
><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-pretti=
fy gmail_msg">);</span><span style=3D"color:#000" class=3D"m_-7631491069799=
626584styled-by-prettify gmail_msg"><br class=3D"gmail_msg"><br class=3D"gm=
ail_msg"></span></div></code></div><br class=3D"gmail_msg"><br class=3D"gma=
il_msg">Decisions and creations of things are limited to the scope of the i=
f.<br class=3D"gmail_msg"><br class=3D"gmail_msg">Also consider selection:<=
br class=3D"gmail_msg">OLD:<br class=3D"gmail_msg"><div style=3D"background=
-color:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;bo=
rder-width:1px" class=3D"m_-7631491069799626584prettyprint gmail_msg"><code=
class=3D"m_-7631491069799626584prettyprint gmail_msg"><div class=3D"m_-763=
1491069799626584subprettyprint gmail_msg"><span style=3D"color:#000" class=
=3D"m_-7631491069799626584styled-by-prettify gmail_msg">=C2=A0 </span><span=
style=3D"color:#008" class=3D"m_-7631491069799626584styled-by-prettify gma=
il_msg">auto</span><span style=3D"color:#000" class=3D"m_-76314910697996265=
84styled-by-prettify gmail_msg"> </span><span style=3D"color:#606" class=3D=
"m_-7631491069799626584styled-by-prettify gmail_msg">Ls_nint</span><span st=
yle=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_=
msg"> </span><span style=3D"color:#660" class=3D"m_-7631491069799626584styl=
ed-by-prettify gmail_msg">=3D</span><span style=3D"color:#000" class=3D"m_-=
7631491069799626584styled-by-prettify gmail_msg"> </span><span style=3D"col=
or:#606" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">Tp</s=
pan><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-pre=
ttify gmail_msg">{</span><span style=3D"color:#066" class=3D"m_-76314910697=
99626584styled-by-prettify gmail_msg">0</span><span style=3D"color:#660" cl=
ass=3D"m_-7631491069799626584styled-by-prettify gmail_msg">};</span><span s=
tyle=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail=
_msg"><br class=3D"gmail_msg">=C2=A0 </span><span style=3D"color:#008" clas=
s=3D"m_-7631491069799626584styled-by-prettify gmail_msg">if</span><span sty=
le=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_m=
sg"> </span><span style=3D"color:#660" class=3D"m_-7631491069799626584style=
d-by-prettify gmail_msg">(</span><span style=3D"color:#000" class=3D"m_-763=
1491069799626584styled-by-prettify gmail_msg">x </span><span style=3D"color=
:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">!=3D</s=
pan><span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-pre=
ttify gmail_msg"> </span><span style=3D"color:#606" class=3D"m_-76314910697=
99626584styled-by-prettify gmail_msg">Tp</span><span style=3D"color:#660" c=
lass=3D"m_-7631491069799626584styled-by-prettify gmail_msg">{</span><span s=
tyle=3D"color:#066" class=3D"m_-7631491069799626584styled-by-prettify gmail=
_msg">0</span><span style=3D"color:#660" class=3D"m_-7631491069799626584sty=
led-by-prettify gmail_msg">})</span><span style=3D"color:#000" class=3D"m_-=
7631491069799626584styled-by-prettify gmail_msg"><br class=3D"gmail_msg">=
=C2=A0 </span><span style=3D"color:#660" class=3D"m_-7631491069799626584sty=
led-by-prettify gmail_msg">{</span><span style=3D"color:#000" class=3D"m_-7=
631491069799626584styled-by-prettify gmail_msg"><br class=3D"gmail_msg">=C2=
=A0 =C2=A0 </span><span style=3D"color:#008" class=3D"m_-763149106979962658=
4styled-by-prettify gmail_msg">auto</span><span style=3D"color:#000" class=
=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> w </span><span sty=
le=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_m=
sg">=3D</span><span style=3D"color:#000" class=3D"m_-7631491069799626584sty=
led-by-prettify gmail_msg"> std</span><span style=3D"color:#660" class=3D"m=
_-7631491069799626584styled-by-prettify gmail_msg">::</span><span style=3D"=
color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">lo=
g</span><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by=
-prettify gmail_msg">(</span><span style=3D"color:#000" class=3D"m_-7631491=
069799626584styled-by-prettify gmail_msg">std</span><span style=3D"color:#6=
60" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">::</span><=
span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify=
gmail_msg">complex</span><span style=3D"color:#660" class=3D"m_-7631491069=
799626584styled-by-prettify gmail_msg"><</span><span style=3D"color:#606=
" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">Tp</span><sp=
an style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify g=
mail_msg">>(</span><span style=3D"color:#000" class=3D"m_-76314910697996=
26584styled-by-prettify gmail_msg">x</span><span style=3D"color:#660" class=
=3D"m_-7631491069799626584styled-by-prettify gmail_msg">));</span><span sty=
le=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_m=
sg"><br class=3D"gmail_msg">=C2=A0 =C2=A0 std</span><span style=3D"color:#6=
60" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">::</span><=
span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify=
gmail_msg">real</span><span style=3D"color:#660" class=3D"m_-7631491069799=
626584styled-by-prettify gmail_msg">(</span><span style=3D"color:#000" clas=
s=3D"m_-7631491069799626584styled-by-prettify gmail_msg">polylog_exp_neg_in=
t</span><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by=
-prettify gmail_msg">(</span><span style=3D"color:#000" class=3D"m_-7631491=
069799626584styled-by-prettify gmail_msg">n</span><span style=3D"color:#660=
" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">,</span><spa=
n style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gm=
ail_msg"> w</span><span style=3D"color:#660" class=3D"m_-763149106979962658=
4styled-by-prettify gmail_msg">));</span><span style=3D"color:#000" class=
=3D"m_-7631491069799626584styled-by-prettify gmail_msg"><br class=3D"gmail_=
msg">=C2=A0 =C2=A0 </span><span style=3D"color:#606" class=3D"m_-7631491069=
799626584styled-by-prettify gmail_msg">Ls_nint</span><span style=3D"color:#=
000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> </span><=
span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify=
gmail_msg">=3D</span><span style=3D"color:#000" class=3D"m_-76314910697996=
26584styled-by-prettify gmail_msg"> </span><span style=3D"color:#606" class=
=3D"m_-7631491069799626584styled-by-prettify gmail_msg">Tp</span><span styl=
e=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_ms=
g">{</span><span style=3D"color:#066" class=3D"m_-7631491069799626584styled=
-by-prettify gmail_msg">0</span><span style=3D"color:#660" class=3D"m_-7631=
491069799626584styled-by-prettify gmail_msg">};</span><span style=3D"color:=
#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"><br clas=
s=3D"gmail_msg">=C2=A0 </span><span style=3D"color:#660" class=3D"m_-763149=
1069799626584styled-by-prettify gmail_msg">}</span><span style=3D"color:#00=
0" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"><br class=
=3D"gmail_msg"><br class=3D"gmail_msg"></span></div></code></div><br class=
=3D"gmail_msg"><br class=3D"gmail_msg">NEW:<br class=3D"gmail_msg"><div sty=
le=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);borde=
r-style:solid;border-width:1px" class=3D"m_-7631491069799626584prettyprint =
gmail_msg"><code class=3D"m_-7631491069799626584prettyprint gmail_msg"><div=
class=3D"m_-7631491069799626584subprettyprint gmail_msg"><span style=3D"co=
lor:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">=C2=
=A0 </span><span style=3D"color:#008" class=3D"m_-7631491069799626584styled=
-by-prettify gmail_msg">auto</span><span style=3D"color:#000" class=3D"m_-7=
631491069799626584styled-by-prettify gmail_msg"> </span><span style=3D"colo=
r:#606" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">Ls_nin=
t</span><span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by=
-prettify gmail_msg"> </span><span style=3D"color:#660" class=3D"m_-7631491=
069799626584styled-by-prettify gmail_msg">=3D</span><span style=3D"color:#0=
00" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> x </span>=
<span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettif=
y gmail_msg">=3D=3D</span><span style=3D"color:#000" class=3D"m_-7631491069=
799626584styled-by-prettify gmail_msg"> </span><span style=3D"color:#606" c=
lass=3D"m_-7631491069799626584styled-by-prettify gmail_msg">Tp</span><span =
style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmai=
l_msg">{</span><span style=3D"color:#066" class=3D"m_-7631491069799626584st=
yled-by-prettify gmail_msg">0</span><span style=3D"color:#660" class=3D"m_-=
7631491069799626584styled-by-prettify gmail_msg">}</span><span style=3D"col=
or:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"><br c=
lass=3D"gmail_msg">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<=
/span><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-p=
rettify gmail_msg">?</span><span style=3D"color:#000" class=3D"m_-763149106=
9799626584styled-by-prettify gmail_msg"> </span><span style=3D"color:#606" =
class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">Tp</span><span=
style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gma=
il_msg">{</span><span style=3D"color:#066" class=3D"m_-7631491069799626584s=
tyled-by-prettify gmail_msg">0</span><span style=3D"color:#660" class=3D"m_=
-7631491069799626584styled-by-prettify gmail_msg">}</span><span style=3D"co=
lor:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"><br =
class=3D"gmail_msg">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
</span><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-=
prettify gmail_msg">:</span><span style=3D"color:#000" class=3D"m_-76314910=
69799626584styled-by-prettify gmail_msg"> </span><span style=3D"color:#660"=
class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">({</span><spa=
n style=3D"color:#008" class=3D"m_-7631491069799626584styled-by-prettify gm=
ail_msg">auto</span><span style=3D"color:#000" class=3D"m_-7631491069799626=
584styled-by-prettify gmail_msg"> w </span><span style=3D"color:#660" class=
=3D"m_-7631491069799626584styled-by-prettify gmail_msg">=3D</span><span sty=
le=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_m=
sg"> std</span><span style=3D"color:#660" class=3D"m_-7631491069799626584st=
yled-by-prettify gmail_msg">::</span><span style=3D"color:#000" class=3D"m_=
-7631491069799626584styled-by-prettify gmail_msg">log</span><span style=3D"=
color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">(<=
/span><span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-p=
rettify gmail_msg">std</span><span style=3D"color:#660" class=3D"m_-7631491=
069799626584styled-by-prettify gmail_msg">::</span><span style=3D"color:#00=
0" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">complex</sp=
an><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-pret=
tify gmail_msg"><</span><span style=3D"color:#606" class=3D"m_-763149106=
9799626584styled-by-prettify gmail_msg">Tp</span><span style=3D"color:#660"=
class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">>(</span><=
span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify=
gmail_msg">x</span><span style=3D"color:#660" class=3D"m_-7631491069799626=
584styled-by-prettify gmail_msg">));</span><span style=3D"color:#000" class=
=3D"m_-7631491069799626584styled-by-prettify gmail_msg"><br class=3D"gmail_=
msg">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0s=
td</span><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-b=
y-prettify gmail_msg">::</span><span style=3D"color:#000" class=3D"m_-76314=
91069799626584styled-by-prettify gmail_msg">real</span><span style=3D"color=
:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">(</span=
><span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-pretti=
fy gmail_msg">polylog_exp_neg_int</span><span style=3D"color:#660" class=3D=
"m_-7631491069799626584styled-by-prettify gmail_msg">(</span><span style=3D=
"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">n=
</span><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-=
prettify gmail_msg">,</span><span style=3D"color:#000" class=3D"m_-76314910=
69799626584styled-by-prettify gmail_msg"> w</span><span style=3D"color:#660=
" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">));});</span=
><span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-pretti=
fy gmail_msg"><br class=3D"gmail_msg"><br class=3D"gmail_msg"></span></div>=
</code></div><br class=3D"gmail_msg"><br class=3D"gmail_msg">The latter onl=
y defines w if needed. Ls_nint only gets initialized once.<br class=3D"gmai=
l_msg"><br class=3D"gmail_msg">Consider construction:<br class=3D"gmail_msg=
">OLD:<br class=3D"gmail_msg"><div style=3D"background-color:rgb(250,250,25=
0);border-color:rgb(187,187,187);border-style:solid;border-width:1px" class=
=3D"m_-7631491069799626584prettyprint gmail_msg"><code class=3D"m_-76314910=
69799626584prettyprint gmail_msg"><div class=3D"m_-7631491069799626584subpr=
ettyprint gmail_msg"><span style=3D"color:#000" class=3D"m_-763149106979962=
6584styled-by-prettify gmail_msg">=C2=A0 </span><span style=3D"color:#606" =
class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">Matrix</span><=
span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify=
gmail_msg">(</span><span style=3D"color:#008" class=3D"m_-7631491069799626=
584styled-by-prettify gmail_msg">const</span><span style=3D"color:#000" cla=
ss=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> </span><span sty=
le=3D"color:#606" class=3D"m_-7631491069799626584styled-by-prettify gmail_m=
sg">Matrix</span><span style=3D"color:#660" class=3D"m_-7631491069799626584=
styled-by-prettify gmail_msg">&</span><span style=3D"color:#000" class=
=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> a</span><span styl=
e=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_ms=
g">,</span><span style=3D"color:#000" class=3D"m_-7631491069799626584styled=
-by-prettify gmail_msg"> </span><span style=3D"color:#008" class=3D"m_-7631=
491069799626584styled-by-prettify gmail_msg">const</span><span style=3D"col=
or:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> </sp=
an><span style=3D"color:#606" class=3D"m_-7631491069799626584styled-by-pret=
tify gmail_msg">Matrix</span><span style=3D"color:#660" class=3D"m_-7631491=
069799626584styled-by-prettify gmail_msg">&</span><span style=3D"color:=
#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> b</span=
><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-pretti=
fy gmail_msg">)</span><span style=3D"color:#000" class=3D"m_-76314910697996=
26584styled-by-prettify gmail_msg"><br class=3D"gmail_msg">=C2=A0 m_A</span=
><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-pretti=
fy gmail_msg">()</span><span style=3D"color:#000" class=3D"m_-7631491069799=
626584styled-by-prettify gmail_msg"> </span><span style=3D"color:#800" clas=
s=3D"m_-7631491069799626584styled-by-prettify gmail_msg">// Might be expens=
ive.</span><span style=3D"color:#000" class=3D"m_-7631491069799626584styled=
-by-prettify gmail_msg"><br class=3D"gmail_msg">=C2=A0 </span><span style=
=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg=
">{</span><span style=3D"color:#000" class=3D"m_-7631491069799626584styled-=
by-prettify gmail_msg"><br class=3D"gmail_msg">=C2=A0 =C2=A0 </span><span s=
tyle=3D"color:#008" class=3D"m_-7631491069799626584styled-by-prettify gmail=
_msg">if</span><span style=3D"color:#000" class=3D"m_-7631491069799626584st=
yled-by-prettify gmail_msg"> </span><span style=3D"color:#660" class=3D"m_-=
7631491069799626584styled-by-prettify gmail_msg">(!</span><span style=3D"co=
lor:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">vali=
d</span><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by=
-prettify gmail_msg">(</span><span style=3D"color:#000" class=3D"m_-7631491=
069799626584styled-by-prettify gmail_msg">a</span><span style=3D"color:#660=
" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">))</span><sp=
an style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify g=
mail_msg"><br class=3D"gmail_msg">=C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color:#008" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg=
">throw</span><span style=3D"color:#000" class=3D"m_-7631491069799626584sty=
led-by-prettify gmail_msg"> badmatrix</span><span style=3D"color:#660" clas=
s=3D"m_-7631491069799626584styled-by-prettify gmail_msg">(</span><span styl=
e=3D"color:#080" class=3D"m_-7631491069799626584styled-by-prettify gmail_ms=
g">"A"</span><span style=3D"color:#660" class=3D"m_-7631491069799=
626584styled-by-prettify gmail_msg">);</span><span style=3D"color:#000" cla=
ss=3D"m_-7631491069799626584styled-by-prettify gmail_msg"><br class=3D"gmai=
l_msg">=C2=A0 =C2=A0 </span><span style=3D"color:#008" class=3D"m_-76314910=
69799626584styled-by-prettify gmail_msg">else</span><span style=3D"color:#0=
00" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> </span><s=
pan style=3D"color:#008" class=3D"m_-7631491069799626584styled-by-prettify =
gmail_msg">if</span><span style=3D"color:#000" class=3D"m_-7631491069799626=
584styled-by-prettify gmail_msg"> </span><span style=3D"color:#660" class=
=3D"m_-7631491069799626584styled-by-prettify gmail_msg">(!</span><span styl=
e=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_ms=
g">valid</span><span style=3D"color:#660" class=3D"m_-7631491069799626584st=
yled-by-prettify gmail_msg">(</span><span style=3D"color:#000" class=3D"m_-=
7631491069799626584styled-by-prettify gmail_msg">b</span><span style=3D"col=
or:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">))</s=
pan><span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-pre=
ttify gmail_msg"><br class=3D"gmail_msg">=C2=A0 =C2=A0 =C2=A0 </span><span =
style=3D"color:#008" class=3D"m_-7631491069799626584styled-by-prettify gmai=
l_msg">throw</span><span style=3D"color:#000" class=3D"m_-76314910697996265=
84styled-by-prettify gmail_msg"> badmatrix</span><span style=3D"color:#660"=
class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">(</span><span=
style=3D"color:#080" class=3D"m_-7631491069799626584styled-by-prettify gma=
il_msg">"B"</span><span style=3D"color:#660" class=3D"m_-76314910=
69799626584styled-by-prettify gmail_msg">);</span><span style=3D"color:#000=
" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"><br class=3D=
"gmail_msg">=C2=A0 =C2=A0 </span><span style=3D"color:#008" class=3D"m_-763=
1491069799626584styled-by-prettify gmail_msg">else</span><span style=3D"col=
or:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"><br c=
lass=3D"gmail_msg">=C2=A0 =C2=A0 </span><span style=3D"color:#660" class=3D=
"m_-7631491069799626584styled-by-prettify gmail_msg">{</span><span style=3D=
"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"><=
br class=3D"gmail_msg">=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#00=
8" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">auto</span>=
<span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettif=
y gmail_msg"> tmp </span><span style=3D"color:#660" class=3D"m_-76314910697=
99626584styled-by-prettify gmail_msg">=3D</span><span style=3D"color:#000" =
class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> a </span><spa=
n style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gm=
ail_msg">*</span><span style=3D"color:#000" class=3D"m_-7631491069799626584=
styled-by-prettify gmail_msg"> b</span><span style=3D"color:#660" class=3D"=
m_-7631491069799626584styled-by-prettify gmail_msg">;</span><span style=3D"=
color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"><b=
r class=3D"gmail_msg">=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008=
" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">if</span><sp=
an style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify g=
mail_msg"> </span><span style=3D"color:#660" class=3D"m_-763149106979962658=
4styled-by-prettify gmail_msg">(!</span><span style=3D"color:#000" class=3D=
"m_-7631491069799626584styled-by-prettify gmail_msg">valid</span><span styl=
e=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_ms=
g">(</span><span style=3D"color:#000" class=3D"m_-7631491069799626584styled=
-by-prettify gmail_msg">b</span><span style=3D"color:#660" class=3D"m_-7631=
491069799626584styled-by-prettify gmail_msg">))</span><span style=3D"color:=
#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"><br clas=
s=3D"gmail_msg">=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#00=
8" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">throw</span=
><span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-pretti=
fy gmail_msg"> badmatrix</span><span style=3D"color:#660" class=3D"m_-76314=
91069799626584styled-by-prettify gmail_msg">(</span><span style=3D"color:#0=
80" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">"B&qu=
ot;</span><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-=
by-prettify gmail_msg">);</span><span style=3D"color:#000" class=3D"m_-7631=
491069799626584styled-by-prettify gmail_msg"><br class=3D"gmail_msg">=C2=A0=
=C2=A0 =C2=A0 </span><span style=3D"color:#008" class=3D"m_-76314910697996=
26584styled-by-prettify gmail_msg">this</span><span style=3D"color:#660" cl=
ass=3D"m_-7631491069799626584styled-by-prettify gmail_msg">-></span><spa=
n style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gm=
ail_msg">m_A </span><span style=3D"color:#660" class=3D"m_-7631491069799626=
584styled-by-prettify gmail_msg">=3D</span><span style=3D"color:#000" class=
=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> tmp</span><span st=
yle=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_=
msg">;</span><span style=3D"color:#000" class=3D"m_-7631491069799626584styl=
ed-by-prettify gmail_msg"><br class=3D"gmail_msg">=C2=A0 =C2=A0 </span><spa=
n style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gm=
ail_msg">}</span><span style=3D"color:#000" class=3D"m_-7631491069799626584=
styled-by-prettify gmail_msg"><br class=3D"gmail_msg">=C2=A0 </span><span s=
tyle=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail=
_msg">}</span><span style=3D"color:#000" class=3D"m_-7631491069799626584sty=
led-by-prettify gmail_msg"><br class=3D"gmail_msg"><br class=3D"gmail_msg">=
</span></div></code></div><br class=3D"gmail_msg"><br class=3D"gmail_msg">N=
EW:<br class=3D"gmail_msg"><div style=3D"background-color:rgb(250,250,250);=
border-color:rgb(187,187,187);border-style:solid;border-width:1px" class=3D=
"m_-7631491069799626584prettyprint gmail_msg"><code class=3D"m_-76314910697=
99626584prettyprint gmail_msg"><div class=3D"m_-7631491069799626584subprett=
yprint gmail_msg"><span style=3D"color:#000" class=3D"m_-763149106979962658=
4styled-by-prettify gmail_msg">=C2=A0 </span><span style=3D"color:#606" cla=
ss=3D"m_-7631491069799626584styled-by-prettify gmail_msg">Matrix</span><spa=
n style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gm=
ail_msg">(</span><span style=3D"color:#008" class=3D"m_-7631491069799626584=
styled-by-prettify gmail_msg">const</span><span style=3D"color:#000" class=
=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> </span><span style=
=3D"color:#606" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg=
">Matrix</span><span style=3D"color:#660" class=3D"m_-7631491069799626584st=
yled-by-prettify gmail_msg">&</span><span style=3D"color:#000" class=3D=
"m_-7631491069799626584styled-by-prettify gmail_msg"> a</span><span style=
=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg=
">,</span><span style=3D"color:#000" class=3D"m_-7631491069799626584styled-=
by-prettify gmail_msg"> </span><span style=3D"color:#008" class=3D"m_-76314=
91069799626584styled-by-prettify gmail_msg">const</span><span style=3D"colo=
r:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> </spa=
n><span style=3D"color:#606" class=3D"m_-7631491069799626584styled-by-prett=
ify gmail_msg">Matrix</span><span style=3D"color:#660" class=3D"m_-76314910=
69799626584styled-by-prettify gmail_msg">&</span><span style=3D"color:#=
000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> b</span>=
<span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettif=
y gmail_msg">)</span><span style=3D"color:#000" class=3D"m_-763149106979962=
6584styled-by-prettify gmail_msg"><br class=3D"gmail_msg">=C2=A0 </span><sp=
an style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify g=
mail_msg">:</span><span style=3D"color:#000" class=3D"m_-763149106979962658=
4styled-by-prettify gmail_msg"> m_A</span><span style=3D"color:#660" class=
=3D"m_-7631491069799626584styled-by-prettify gmail_msg">(!</span><span styl=
e=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_ms=
g">valid</span><span style=3D"color:#660" class=3D"m_-7631491069799626584st=
yled-by-prettify gmail_msg">(</span><span style=3D"color:#000" class=3D"m_-=
7631491069799626584styled-by-prettify gmail_msg">a</span><span style=3D"col=
or:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">)</sp=
an><span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-pret=
tify gmail_msg"> </span><span style=3D"color:#660" class=3D"m_-763149106979=
9626584styled-by-prettify gmail_msg">?</span><span style=3D"color:#000" cla=
ss=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> </span><span sty=
le=3D"color:#008" class=3D"m_-7631491069799626584styled-by-prettify gmail_m=
sg">throw</span><span style=3D"color:#000" class=3D"m_-7631491069799626584s=
tyled-by-prettify gmail_msg"> badmatrix</span><span style=3D"color:#660" cl=
ass=3D"m_-7631491069799626584styled-by-prettify gmail_msg">(</span><span st=
yle=3D"color:#080" class=3D"m_-7631491069799626584styled-by-prettify gmail_=
msg">"A"</span><span style=3D"color:#660" class=3D"m_-76314910697=
99626584styled-by-prettify gmail_msg">)</span><span style=3D"color:#000" cl=
ass=3D"m_-7631491069799626584styled-by-prettify gmail_msg"><br class=3D"gma=
il_msg">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </sp=
an><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-pret=
tify gmail_msg">:</span><span style=3D"color:#000" class=3D"m_-763149106979=
9626584styled-by-prettify gmail_msg"> </span><span style=3D"color:#660" cla=
ss=3D"m_-7631491069799626584styled-by-prettify gmail_msg">!</span><span sty=
le=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_m=
sg">valid</span><span style=3D"color:#660" class=3D"m_-7631491069799626584s=
tyled-by-prettify gmail_msg">(</span><span style=3D"color:#000" class=3D"m_=
-7631491069799626584styled-by-prettify gmail_msg">b</span><span style=3D"co=
lor:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">)</s=
pan><span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-pre=
ttify gmail_msg"> </span><span style=3D"color:#660" class=3D"m_-76314910697=
99626584styled-by-prettify gmail_msg">?</span><span style=3D"color:#000" cl=
ass=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> </span><span st=
yle=3D"color:#008" class=3D"m_-7631491069799626584styled-by-prettify gmail_=
msg">throw</span><span style=3D"color:#000" class=3D"m_-7631491069799626584=
styled-by-prettify gmail_msg"> badmatrix</span><span style=3D"color:#660" c=
lass=3D"m_-7631491069799626584styled-by-prettify gmail_msg">(</span><span s=
tyle=3D"color:#080" class=3D"m_-7631491069799626584styled-by-prettify gmail=
_msg">"B"</span><span style=3D"color:#660" class=3D"m_-7631491069=
799626584styled-by-prettify gmail_msg">)</span><span style=3D"color:#000" c=
lass=3D"m_-7631491069799626584styled-by-prettify gmail_msg"><br class=3D"gm=
ail_msg">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#660" cl=
ass=3D"m_-7631491069799626584styled-by-prettify gmail_msg">:</span><span st=
yle=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_=
msg"> </span><span style=3D"color:#660" class=3D"m_-7631491069799626584styl=
ed-by-prettify gmail_msg">({</span><span style=3D"color:#008" class=3D"m_-7=
631491069799626584styled-by-prettify gmail_msg">auto</span><span style=3D"c=
olor:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> tm=
p</span><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by=
-prettify gmail_msg">(</span><span style=3D"color:#000" class=3D"m_-7631491=
069799626584styled-by-prettify gmail_msg">a</span><span style=3D"color:#660=
" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">);</span><sp=
an style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify g=
mail_msg"><br class=3D"gmail_msg">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 tmp </span><span style=3D"color:#660" class=3D"m_-7631491069799626584st=
yled-by-prettify gmail_msg">*=3D</span><span style=3D"color:#000" class=3D"=
m_-7631491069799626584styled-by-prettify gmail_msg"> b</span><span style=3D=
"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">;=
</span><span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-=
prettify gmail_msg"><br class=3D"gmail_msg">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 valid</span><span style=3D"color:#660" class=3D"m_-7631491069=
799626584styled-by-prettify gmail_msg">(</span><span style=3D"color:#000" c=
lass=3D"m_-7631491069799626584styled-by-prettify gmail_msg">tmp</span><span=
style=3D"color:#660" class=3D"m_-7631491069799626584styled-by-prettify gma=
il_msg">)</span><span style=3D"color:#000" class=3D"m_-7631491069799626584s=
tyled-by-prettify gmail_msg"> </span><span style=3D"color:#660" class=3D"m_=
-7631491069799626584styled-by-prettify gmail_msg">?</span><span style=3D"co=
lor:#000" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg"> tmp=
</span><span style=3D"color:#660" class=3D"m_-7631491069799626584styled-by=
-prettify gmail_msg">:</span><span style=3D"color:#000" class=3D"m_-7631491=
069799626584styled-by-prettify gmail_msg"> </span><span style=3D"color:#008=
" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">throw</span>=
<span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettif=
y gmail_msg"> badmatrix</span><span style=3D"color:#660" class=3D"m_-763149=
1069799626584styled-by-prettify gmail_msg">(</span><span style=3D"color:#08=
0" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">"A*B&q=
uot;</span><span style=3D"color:#660" class=3D"m_-7631491069799626584styled=
-by-prettify gmail_msg">);})</span><span style=3D"color:#000" class=3D"m_-7=
631491069799626584styled-by-prettify gmail_msg"><br class=3D"gmail_msg">=C2=
=A0 </span><span style=3D"color:#660" class=3D"m_-7631491069799626584styled=
-by-prettify gmail_msg">{</span><span style=3D"color:#000" class=3D"m_-7631=
491069799626584styled-by-prettify gmail_msg"> </span><span style=3D"color:#=
660" class=3D"m_-7631491069799626584styled-by-prettify gmail_msg">}</span><=
span style=3D"color:#000" class=3D"m_-7631491069799626584styled-by-prettify=
gmail_msg"><br class=3D"gmail_msg"><br class=3D"gmail_msg"></span></div></=
code></div><br class=3D"gmail_msg"><br class=3D"gmail_msg">Maybe that's=
not as big a big win.<br class=3D"gmail_msg">=C2=A0</div></div>
<p class=3D"gmail_msg"></p>
-- <br class=3D"gmail_msg">
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br class=3D"gmail_msg=
">
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" class=3D"gm=
ail_msg" target=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br cla=
ss=3D"gmail_msg">
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" class=3D"gmail_msg" target=3D"_blank">std-proposals@isocpp.org</a>.<b=
r class=3D"gmail_msg">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c1b3fd23-9a0b-449f-9cd7-c87f64558e58%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter" class=3D"gmail_msg=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-prop=
osals/c1b3fd23-9a0b-449f-9cd7-c87f64558e58%40isocpp.org</a>.<br class=3D"gm=
ail_msg">
</blockquote></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/CAPCFJdQsC%3D4KMesOeDv5vJ6UQs0W7-23tx=
%3DSLVaTjrASGxK6zg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAPCFJdQsC%3D=
4KMesOeDv5vJ6UQs0W7-23tx%3DSLVaTjrASGxK6zg%40mail.gmail.com</a>.<br />
--94eb2c05ae02d99d71054926eb5b--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 23 Feb 2017 01:34:06 +0200
Raw View
--001a113cd862d078f6054926ee4e
Content-Type: text/plain; charset=UTF-8
On 23 February 2017 at 01:26, <3dw4rd@verizon.net> wrote:
>
>
> On Monday, February 6, 2017 at 10:46:06 PM UTC-5, Tony V E wrote:
>>
>> I highly recommend, for almost any proposal, to include "before and after
>> tables" (I think the committee has a some nick name for these), showing
>> what you would currently need to write using C++17 on the left, and how it
>> could be rewritten in C++20 using your proposal on the right.
>>
>> Just focusing on the aspect of statement expressions now existing in
> various implementations (no params or templates)
> and highlighting the real use case: initialization without scope leak.
> I think this has a real chance of being useful and accepted.
> Note that C++17 just put in initialization in if and switch for this
> reason.
> In that light, this should work well with that feature and really be a
> natural extension of it.
>
> OLD:
> {
> Tp s{};
> for (int k = 0; k < 3; ++k)
> s += v[k];
> if (s.useable())
> do_a_thing(s);
> }
>
>
>
> NEW:
> if (foo = ({Tp s{}; for(int k = 0; k < 3; ++k) s += v[k]; s}); foo.
> useable())
> do_a_thing(foo);
>
>
>
>
Why isn't OLD then
if (foo = [] {Tp s{}; for(int k = 0; k < 3; ++k) s += v[k]; return s;}();
foo.useable())
do_a_thing(foo);
--
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/CAFk2RUZ1Rkviy%2BUcPCKgC6k%2BK6uEC4ELcxn%3Dpg74Q2W4x47FPQ%40mail.gmail.com.
--001a113cd862d078f6054926ee4e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 23 February 2017 at 01:26, <span dir=3D"ltr"><<a href=3D"mailto:=
3dw4rd@verizon.net" target=3D"_blank">3dw4rd@verizon.net</a>></span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><=
span class=3D"gmail-"><br><br>On Monday, February 6, 2017 at 10:46:06 PM UT=
C-5, Tony V E wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
style=3D"background-color:rgb(255,255,255);line-height:initial" lang=3D"en-=
US"> =
<div style=3D"width:100%;font-size:initial;font-family:calib=
ri,"slate pro",sans-serif,sans-serif;color:rgb(31,73,125);text-al=
ign:initial;background-color:rgb(255,255,255)">I highly recommend, for almo=
st any proposal, to include "before and after tables" (I think th=
e committee has a some nick name for these), showing what you would current=
ly need to write using C++17 on the left, and how it could be rewritten in =
C++20 using your proposal on the right. </div><table style=3D"background-co=
lor:white;border-spacing:0px" width=3D"100%"><tbody><tr><td colspan=3D"2" s=
tyle=3D"font-size:initial;text-align:initial;background-color:rgb(255,255,2=
55)"><br></td></tr></tbody></table></div></blockquote></span><div>Just focu=
sing on the aspect of statement expressions now existing in various impleme=
ntations (no params or templates)<br>and highlighting the real use case: in=
itialization without scope leak.<br>I think this has a real chance of being=
useful and accepted.<br>Note that C++17 just put in initialization in if a=
nd switch for this reason.<br>In that light, this should work well with tha=
t feature and really be a natural extension of it.<br><br>OLD:<br><div styl=
e=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);border=
-style:solid;border-width:1px" class=3D"gmail-m_-6784268834570373642prettyp=
rint"><code class=3D"gmail-m_-6784268834570373642prettyprint"><div class=3D=
"gmail-m_-6784268834570373642subprettyprint"><span style=3D"color:rgb(0,0,0=
)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">=C2=A0 </span><=
span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642st=
yled-by-prettify">{</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m=
_-6784268834570373642styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span sty=
le=3D"color:rgb(102,0,102)" class=3D"gmail-m_-6784268834570373642styled-by-=
prettify">Tp</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-67842=
68834570373642styled-by-prettify"> s</span><span style=3D"color:rgb(102,102=
,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">{};</span><sp=
an style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-b=
y-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color:rgb(0,0,136)" cla=
ss=3D"gmail-m_-6784268834570373642styled-by-prettify">for</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-pretti=
fy"> </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-67842688=
34570373642styled-by-prettify">(</span><span style=3D"color:rgb(0,0,136)" c=
lass=3D"gmail-m_-6784268834570373642styled-by-prettify">int</span><span sty=
le=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-pret=
tify"> k </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784=
268834570373642styled-by-prettify">=3D</span><span style=3D"color:rgb(0,0,0=
)" class=3D"gmail-m_-6784268834570373642styled-by-prettify"> </span><span s=
tyle=3D"color:rgb(0,102,102)" class=3D"gmail-m_-6784268834570373642styled-b=
y-prettify">0</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-=
6784268834570373642styled-by-prettify">;</span><span style=3D"color:rgb(0,0=
,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify"> k </span><sp=
an style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642styl=
ed-by-prettify"><</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-=
m_-6784268834570373642styled-by-prettify"> </span><span style=3D"color:rgb(=
0,102,102)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">3</spa=
n><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-678426883457037364=
2styled-by-prettify">;</span><span style=3D"color:rgb(0,0,0)" class=3D"gmai=
l-m_-6784268834570373642styled-by-prettify"> </span><span style=3D"color:rg=
b(102,102,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">++</=
span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642=
styled-by-prettify">k</span><span style=3D"color:rgb(102,102,0)" class=3D"g=
mail-m_-6784268834570373642styled-by-prettify">)</span><span style=3D"color=
:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify"><br>=
=C2=A0 =C2=A0 =C2=A0 s </span><span style=3D"color:rgb(102,102,0)" class=3D=
"gmail-m_-6784268834570373642styled-by-prettify">+=3D</span><span style=3D"=
color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">=
v</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-67842688345=
70373642styled-by-prettify">[</span><span style=3D"color:rgb(0,0,0)" class=
=3D"gmail-m_-6784268834570373642styled-by-prettify">k</span><span style=3D"=
color:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642styled-by-pretti=
fy">];</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-67842688345=
70373642styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color:r=
gb(0,0,136)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">if</s=
pan><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642s=
tyled-by-prettify"> </span><span style=3D"color:rgb(102,102,0)" class=3D"gm=
ail-m_-6784268834570373642styled-by-prettify">(</span><span style=3D"color:=
rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">s</spa=
n><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-678426883457037364=
2styled-by-prettify">.</span><span style=3D"color:rgb(0,0,0)" class=3D"gmai=
l-m_-6784268834570373642styled-by-prettify">useable</span><span style=3D"co=
lor:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify=
">())</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-678426883457=
0373642styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 do_a_thing</span><span =
style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642styled-=
by-prettify">(</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-678=
4268834570373642styled-by-prettify">s</span><span style=3D"color:rgb(102,10=
2,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">);</span><sp=
an style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-b=
y-prettify"><br>=C2=A0 </span><span style=3D"color:rgb(102,102,0)" class=3D=
"gmail-m_-6784268834570373642styled-by-prettify">}</span><span style=3D"col=
or:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify"><br=
><br></span></div></code></div><br><br>NEW:<br><div style=3D"background-col=
or:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border=
-width:1px" class=3D"gmail-m_-6784268834570373642prettyprint"><code class=
=3D"gmail-m_-6784268834570373642prettyprint"><div class=3D"gmail-m_-6784268=
834570373642subprettyprint"><span style=3D"color:rgb(0,0,0)" class=3D"gmail=
-m_-6784268834570373642styled-by-prettify">=C2=A0 </span><span style=3D"col=
or:rgb(0,0,136)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">i=
f</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373=
642styled-by-prettify"> </span><span style=3D"color:rgb(102,102,0)" class=
=3D"gmail-m_-6784268834570373642styled-by-prettify">(</span><span style=3D"=
color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">=
foo </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-678426883=
4570373642styled-by-prettify">=3D</span><span style=3D"color:rgb(0,0,0)" cl=
ass=3D"gmail-m_-6784268834570373642styled-by-prettify"> </span><span style=
=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642styled-by-pr=
ettify">({</span><span style=3D"color:rgb(102,0,102)" class=3D"gmail-m_-678=
4268834570373642styled-by-prettify">Tp</span><span style=3D"color:rgb(0,0,0=
)" class=3D"gmail-m_-6784268834570373642styled-by-prettify"> s</span><span =
style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642styled-=
by-prettify">{};</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6=
784268834570373642styled-by-prettify"> </span><span style=3D"color:rgb(0,0,=
136)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">for</span><s=
pan style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642sty=
led-by-prettify">(</span><span style=3D"color:rgb(0,0,136)" class=3D"gmail-=
m_-6784268834570373642styled-by-prettify">int</span><span style=3D"color:rg=
b(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify"> k </spa=
n><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-678426883457037364=
2styled-by-prettify">=3D</span><span style=3D"color:rgb(0,0,0)" class=3D"gm=
ail-m_-6784268834570373642styled-by-prettify"> </span><span style=3D"color:=
rgb(0,102,102)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">0<=
/span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-67842688345703=
73642styled-by-prettify">;</span><span style=3D"color:rgb(0,0,0)" class=3D"=
gmail-m_-6784268834570373642styled-by-prettify"> k </span><span style=3D"co=
lor:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify=
"><</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-67842688345=
70373642styled-by-prettify"> </span><span style=3D"color:rgb(0,102,102)" cl=
ass=3D"gmail-m_-6784268834570373642styled-by-prettify">3</span><span style=
=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642styled-by-pr=
ettify">;</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-67842688=
34570373642styled-by-prettify"> </span><span style=3D"color:rgb(102,102,0)"=
class=3D"gmail-m_-6784268834570373642styled-by-prettify">++</span><span st=
yle=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-pre=
ttify">k</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-67842=
68834570373642styled-by-prettify">)</span><span style=3D"color:rgb(0,0,0)" =
class=3D"gmail-m_-6784268834570373642styled-by-prettify"> s </span><span st=
yle=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642styled-by=
-prettify">+=3D</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-67=
84268834570373642styled-by-prettify"> v</span><span style=3D"color:rgb(102,=
102,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">[</span><s=
pan style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-=
by-prettify">k</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_=
-6784268834570373642styled-by-prettify">];</span><span style=3D"color:rgb(0=
,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify"> s</span><s=
pan style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642sty=
led-by-prettify">});</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-=
m_-6784268834570373642styled-by-prettify"> foo</span><span style=3D"color:r=
gb(102,102,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">.</=
span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642=
styled-by-prettify">useable</span><span style=3D"color:rgb(102,102,0)" clas=
s=3D"gmail-m_-6784268834570373642styled-by-prettify">())</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-pretti=
fy"><br>=C2=A0 =C2=A0 do_a_thing</span><span style=3D"color:rgb(102,102,0)"=
class=3D"gmail-m_-6784268834570373642styled-by-prettify">(</span><span sty=
le=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-pret=
tify">foo</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784=
268834570373642styled-by-prettify">);</span><span style=3D"color:rgb(0,0,0)=
" class=3D"gmail-m_-6784268834570373642styled-by-prettify"><br><br></span><=
/div></code></div><br><br></div></div></blockquote><div><br></div><div>Why =
isn't OLD then <br><br><code class=3D"gmail-m_-6784268834570373642prett=
yprint"><span style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-67842688345703=
73642styled-by-prettify">if</span><span style=3D"color:rgb(0,0,0)" class=3D=
"gmail-m_-6784268834570373642styled-by-prettify"> </span><span style=3D"col=
or:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify"=
>(</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-678426883457037=
3642styled-by-prettify">foo </span><span style=3D"color:rgb(102,102,0)" cla=
ss=3D"gmail-m_-6784268834570373642styled-by-prettify">=3D</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-pretti=
fy"> </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-67842688=
34570373642styled-by-prettify">[] {</span><span style=3D"color:rgb(102,0,10=
2)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">Tp</span><span=
style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-=
prettify"> s</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6=
784268834570373642styled-by-prettify">{};</span><span style=3D"color:rgb(0,=
0,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify"> </span><spa=
n style=3D"color:rgb(0,0,136)" class=3D"gmail-m_-6784268834570373642styled-=
by-prettify">for</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-=
m_-6784268834570373642styled-by-prettify">(</span><span style=3D"color:rgb(=
0,0,136)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">int</spa=
n><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642sty=
led-by-prettify"> k </span><span style=3D"color:rgb(102,102,0)" class=3D"gm=
ail-m_-6784268834570373642styled-by-prettify">=3D</span><span style=3D"colo=
r:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify"> </s=
pan><span style=3D"color:rgb(0,102,102)" class=3D"gmail-m_-6784268834570373=
642styled-by-prettify">0</span><span style=3D"color:rgb(102,102,0)" class=
=3D"gmail-m_-6784268834570373642styled-by-prettify">;</span><span style=3D"=
color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">=
k </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784268834=
570373642styled-by-prettify"><</span><span style=3D"color:rgb(0,0,0)" cl=
ass=3D"gmail-m_-6784268834570373642styled-by-prettify"> </span><span style=
=3D"color:rgb(0,102,102)" class=3D"gmail-m_-6784268834570373642styled-by-pr=
ettify">3</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784=
268834570373642styled-by-prettify">;</span><span style=3D"color:rgb(0,0,0)"=
class=3D"gmail-m_-6784268834570373642styled-by-prettify"> </span><span sty=
le=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642styled-by-=
prettify">++</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-67842=
68834570373642styled-by-prettify">k</span><span style=3D"color:rgb(102,102,=
0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">)</span><span =
style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-p=
rettify"> s </span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6=
784268834570373642styled-by-prettify">+=3D</span><span style=3D"color:rgb(0=
,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify"> v</span><s=
pan style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642sty=
led-by-prettify">[</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_=
-6784268834570373642styled-by-prettify">k</span><span style=3D"color:rgb(10=
2,102,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">];</span=
><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styl=
ed-by-prettify"> return s;</span><span style=3D"color:rgb(102,102,0)" class=
=3D"gmail-m_-6784268834570373642styled-by-prettify">}();</span><span style=
=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642styled-by-pretti=
fy"> foo</span><span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-67842=
68834570373642styled-by-prettify">.</span><span style=3D"color:rgb(0,0,0)" =
class=3D"gmail-m_-6784268834570373642styled-by-prettify">useable</span><spa=
n style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642style=
d-by-prettify">())</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_=
-6784268834570373642styled-by-prettify"><br>=C2=A0 =C2=A0 do_a_thing</span>=
<span style=3D"color:rgb(102,102,0)" class=3D"gmail-m_-6784268834570373642s=
tyled-by-prettify">(</span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-=
m_-6784268834570373642styled-by-prettify">foo</span><span style=3D"color:rg=
b(102,102,0)" class=3D"gmail-m_-6784268834570373642styled-by-prettify">);</=
span><span style=3D"color:rgb(0,0,0)" class=3D"gmail-m_-6784268834570373642=
styled-by-prettify"><br></span></code><br></div></div></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/CAFk2RUZ1Rkviy%2BUcPCKgC6k%2BK6uEC4EL=
cxn%3Dpg74Q2W4x47FPQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZ1Rk=
viy%2BUcPCKgC6k%2BK6uEC4ELcxn%3Dpg74Q2W4x47FPQ%40mail.gmail.com</a>.<br />
--001a113cd862d078f6054926ee4e--
.
Author: 3dw4rd@verizon.net
Date: Thu, 23 Feb 2017 08:36:04 -0800 (PST)
Raw View
------=_Part_2293_313947523.1487867764193
Content-Type: multipart/alternative;
boundary="----=_Part_2294_1554662816.1487867764194"
------=_Part_2294_1554662816.1487867764194
Content-Type: text/plain; charset=UTF-8
On Wednesday, February 22, 2017 at 6:34:09 PM UTC-5, Ville Voutilainen
wrote:
>
>
>
> On 23 February 2017 at 01:26, <3dw...@verizon.net <javascript:>> wrote:
>
>>
>>
>> On Monday, February 6, 2017 at 10:46:06 PM UTC-5, Tony V E wrote:
>>>
>>> I highly recommend, for almost any proposal, to include "before and
>>> after tables" (I think the committee has a some nick name for these),
>>> showing what you would currently need to write using C++17 on the left, and
>>> how it could be rewritten in C++20 using your proposal on the right.
>>>
>>> Just focusing on the aspect of statement expressions now existing in
>> various implementations (no params or templates)
>> and highlighting the real use case: initialization without scope leak.
>> I think this has a real chance of being useful and accepted.
>> Note that C++17 just put in initialization in if and switch for this
>> reason.
>> In that light, this should work well with that feature and really be a
>> natural extension of it.
>>
>> OLD:
>> {
>> Tp s{};
>> for (int k = 0; k < 3; ++k)
>> s += v[k];
>> if (s.useable())
>> do_a_thing(s);
>> }
>>
>>
>>
>> NEW:
>> if (foo = ({Tp s{}; for(int k = 0; k < 3; ++k) s += v[k]; s}); foo.
>> useable())
>> do_a_thing(foo);
>>
>>
>>
>>
> Why isn't OLD then
>
> if (foo = [] {Tp s{}; for(int k = 0; k < 3; ++k) s += v[k]; return s;}();
> foo.useable())
> do_a_thing(foo);
>
>
You're right. And with a special keyword like `xxx_yield` or `vomit` they
would be the same length.
Maybe all my examples could be done this way.
Question: what context does a lambda have in a ctor init list?
Ctor args, globals, ...?
--
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/cc8c8448-b0f1-4ae3-ad66-3d6ae25bb71e%40isocpp.org.
------=_Part_2294_1554662816.1487867764194
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, February 22, 2017 at 6:34:09 PM UTC-=
5, Ville Voutilainen wrote:<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"><br><div><br><div class=3D"gmail_quote">On 23 February 2017 a=
t 01:26, <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"mz11tHZkBwAJ" rel=3D"nofollow" onmousedown=3D"this.=
href=3D'javascript:';return true;" onclick=3D"this.href=3D'java=
script:';return true;">3dw...@verizon.net</a>></span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span><br><b=
r>On Monday, February 6, 2017 at 10:46:06 PM UTC-5, Tony V E wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex"><div style=3D"background-color:rg=
b(255,255,255);line-height:initial" lang=3D"en-US"> =
<div style=3D=
"width:100%;font-size:initial;font-family:calibri,"slate pro",san=
s-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color=
:rgb(255,255,255)">I highly recommend, for almost any proposal, to include =
"before and after tables" (I think the committee has a some nick =
name for these), showing what you would currently need to write using C++17=
on the left, and how it could be rewritten in C++20 using your proposal on=
the right. </div><table style=3D"background-color:white;border-spacing:0px=
" width=3D"100%"><tbody><tr><td colspan=3D"2" style=3D"font-size:initial;te=
xt-align:initial;background-color:rgb(255,255,255)"><br></td></tr></tbody><=
/table></div></blockquote></span><div>Just focusing on the aspect of statem=
ent expressions now existing in various implementations (no params or templ=
ates)<br>and highlighting the real use case: initialization without scope l=
eak.<br>I think this has a real chance of being useful and accepted.<br>Not=
e that C++17 just put in initialization in if and switch for this reason.<b=
r>In that light, this should work well with that feature and really be a na=
tural extension of it.<br><br>OLD:<br><div style=3D"background-color:rgb(25=
0,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:1p=
x"><code><div><span style=3D"color:rgb(0,0,0)">=C2=A0 </span><span style=3D=
"color:rgb(102,102,0)">{</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color:rgb(102,0,102)">Tp</span><span style=3D"=
color:rgb(0,0,0)"> s</span><span style=3D"color:rgb(102,102,0)">{};</span><=
span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><span style=3D"col=
or:rgb(0,0,136)">for</span><span style=3D"color:rgb(0,0,0)"> </span><span s=
tyle=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,136)">in=
t</span><span style=3D"color:rgb(0,0,0)"> k </span><span style=3D"color:rgb=
(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span style=
=3D"color:rgb(0,102,102)">0</span><span style=3D"color:rgb(102,102,0)">;</s=
pan><span style=3D"color:rgb(0,0,0)"> k </span><span style=3D"color:rgb(102=
,102,0)"><</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D=
"color:rgb(0,102,102)">3</span><span style=3D"color:rgb(102,102,0)">;</span=
><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,=
0)">++</span><span style=3D"color:rgb(0,0,0)">k</span><span style=3D"color:=
rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =
=C2=A0 s </span><span style=3D"color:rgb(102,102,0)">+=3D</span><span style=
=3D"color:rgb(0,0,0)"> v</span><span style=3D"color:rgb(102,102,0)">[</span=
><span style=3D"color:rgb(0,0,0)">k</span><span style=3D"color:rgb(102,102,=
0)">];</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 </span><spa=
n style=3D"color:rgb(0,0,136)">if</span><span style=3D"color:rgb(0,0,0)"> <=
/span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb=
(0,0,0)">s</span><span style=3D"color:rgb(102,102,0)">.</span><span style=
=3D"color:rgb(0,0,0)">useable</span><span style=3D"color:rgb(102,102,0)">()=
)</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 do_a_thin=
g</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:r=
gb(0,0,0)">s</span><span style=3D"color:rgb(102,102,0)">);</span><span styl=
e=3D"color:rgb(0,0,0)"><br>=C2=A0 </span><span style=3D"color:rgb(102,102,0=
)">}</span><span style=3D"color:rgb(0,0,0)"><br><br></span></div></code></d=
iv><br><br>NEW:<br><div style=3D"background-color:rgb(250,250,250);border-c=
olor:rgb(187,187,187);border-style:solid;border-width:1px"><code><div><span=
style=3D"color:rgb(0,0,0)">=C2=A0 </span><span style=3D"color:rgb(0,0,136)=
">if</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rg=
b(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">foo </span><span sty=
le=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </s=
pan><span style=3D"color:rgb(102,102,0)">({</span><span style=3D"color:rgb(=
102,0,102)">Tp</span><span style=3D"color:rgb(0,0,0)"> s</span><span style=
=3D"color:rgb(102,102,0)">{};</span><span style=3D"color:rgb(0,0,0)"> </spa=
n><span style=3D"color:rgb(0,0,136)">for</span><span style=3D"color:rgb(102=
,102,0)">(</span><span style=3D"color:rgb(0,0,136)">int</span><span style=
=3D"color:rgb(0,0,0)"> k </span><span style=3D"color:rgb(102,102,0)">=3D</s=
pan><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102=
,102)">0</span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"=
color:rgb(0,0,0)"> k </span><span style=3D"color:rgb(102,102,0)"><</span=
><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,102,10=
2)">3</span><span style=3D"color:rgb(102,102,0)">;</span><span style=3D"col=
or:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">++</span><span =
style=3D"color:rgb(0,0,0)">k</span><span style=3D"color:rgb(102,102,0)">)</=
span><span style=3D"color:rgb(0,0,0)"> s </span><span style=3D"color:rgb(10=
2,102,0)">+=3D</span><span style=3D"color:rgb(0,0,0)"> v</span><span style=
=3D"color:rgb(102,102,0)">[</span><span style=3D"color:rgb(0,0,0)">k</span>=
<span style=3D"color:rgb(102,102,0)">];</span><span style=3D"color:rgb(0,0,=
0)"> s</span><span style=3D"color:rgb(102,102,0)">});</span><span style=3D"=
color:rgb(0,0,0)"> foo</span><span style=3D"color:rgb(102,102,0)">.</span><=
span style=3D"color:rgb(0,0,0)">useable</span><span style=3D"color:rgb(102,=
102,0)">())</span><span style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 do_a_t=
hing</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"colo=
r:rgb(0,0,0)">foo</span><span style=3D"color:rgb(102,102,0)">);</span><span=
style=3D"color:rgb(0,0,0)"><br><br></span></div></code></div><br><br></div=
></div></blockquote><div><br></div><div>Why isn't OLD then <br><br><cod=
e><span style=3D"color:rgb(0,0,136)">if</span><span style=3D"color:rgb(0,0,=
0)"> </span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"col=
or:rgb(0,0,0)">foo </span><span style=3D"color:rgb(102,102,0)">=3D</span><s=
pan style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)"=
>[] {</span><span style=3D"color:rgb(102,0,102)">Tp</span><span style=3D"co=
lor:rgb(0,0,0)"> s</span><span style=3D"color:rgb(102,102,0)">{};</span><sp=
an style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">fo=
r</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:r=
gb(0,0,136)">int</span><span style=3D"color:rgb(0,0,0)"> k </span><span sty=
le=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </s=
pan><span style=3D"color:rgb(0,102,102)">0</span><span style=3D"color:rgb(1=
02,102,0)">;</span><span style=3D"color:rgb(0,0,0)"> k </span><span style=
=3D"color:rgb(102,102,0)"><</span><span style=3D"color:rgb(0,0,0)"> </sp=
an><span style=3D"color:rgb(0,102,102)">3</span><span style=3D"color:rgb(10=
2,102,0)">;</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"c=
olor:rgb(102,102,0)">++</span><span style=3D"color:rgb(0,0,0)">k</span><spa=
n style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> =
s </span><span style=3D"color:rgb(102,102,0)">+=3D</span><span style=3D"col=
or:rgb(0,0,0)"> v</span><span style=3D"color:rgb(102,102,0)">[</span><span =
style=3D"color:rgb(0,0,0)">k</span><span style=3D"color:rgb(102,102,0)">];<=
/span><span style=3D"color:rgb(0,0,0)"> return s;</span><span style=3D"colo=
r:rgb(102,102,0)">}();</span><span style=3D"color:rgb(0,0,0)"> foo</span><s=
pan style=3D"color:rgb(102,102,0)">.</span><span style=3D"color:rgb(0,0,0)"=
>useable</span><span style=3D"color:rgb(102,102,0)">())</span><span style=
=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 do_a_thing</span><span style=3D"col=
or:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">foo</span><span=
style=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"><=
br></span></code><br></div></div></div></div></blockquote><div><br>You'=
re right.=C2=A0 And with a special keyword like `xxx_yield` or `vomit` they=
would be the same length.<br>=C2=A0<br>Maybe all my examples could be done=
this way.<br><br>Question: what context does a lambda have in a ctor init =
list?<br>Ctor args, globals, ...?<br><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/cc8c8448-b0f1-4ae3-ad66-3d6ae25bb71e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cc8c8448-b0f1-4ae3-ad66-3d6ae25bb71e=
%40isocpp.org</a>.<br />
------=_Part_2294_1554662816.1487867764194--
------=_Part_2293_313947523.1487867764193--
.