Topic: Mid-expression statements


Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Thu, 4 Dec 2014 20:16:05 +0000
Raw View
Gcc uses the syntax ({ }) to embed statements within expressions.
Should this be standardised?

--

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

.


Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 5 Dec 2014 07:15:14 +0200
Raw View
On 4 December 2014 at 22:16, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> Gcc uses the syntax ({ }) to embed statements within expressions.
> Should this be standardised?


Why? If you want to embed statements into expressions, use a lambda.

--

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

.


Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Fri, 5 Dec 2014 06:44:51 -0800 (PST)
Raw View
------=_Part_383_208312145.1417790691294
Content-Type: multipart/alternative;
 boundary="----=_Part_384_703876405.1417790691294"

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

Since this is a duplicate of=20
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/JzuevNXg=
mqU,=20
I have decided to delete it.

Note, I=E2=80=99m not particularly in favour of statement expressions, just=
 wanted=20
to know what the consensus was ;)

--=20

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

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

<div dir=3D"ltr">Since this is a duplicate of https://groups.google.com/a/i=
socpp.org/forum/#!topic/std-proposals/JzuevNXgmqU, I have decided to delete=
 it.<br><br>Note, I=E2=80=99m not particularly in favour of statement expre=
ssions, just wanted to know what the consensus was ;)<br></div>

<p></p>

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

------=_Part_384_703876405.1417790691294--
------=_Part_383_208312145.1417790691294--

.


Author: Myriachan <myriachan@gmail.com>
Date: Mon, 8 Dec 2014 15:42:35 -0800 (PST)
Raw View
------=_Part_3376_46556685.1418082156140
Content-Type: multipart/alternative;
 boundary="----=_Part_3377_794157287.1418082156140"

------=_Part_3377_794157287.1418082156140
Content-Type: text/plain; charset=UTF-8

On Thursday, December 4, 2014 9:15:16 PM UTC-8, Ville Voutilainen wrote:
>
> On 4 December 2014 at 22:16, Douglas Boffey <douglas...@gmail.com
> <javascript:>> wrote:
> > Gcc uses the syntax ({ }) to embed statements within expressions.
> > Should this be standardised?
>
>
> Why? If you want to embed statements into expressions, use a lambda.
>

({...})  can be used inside a constant-expression that's never evaluated
(e.g. sizeof) and lambda calls explicitly cannot be.

Melissa

--

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

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

<div dir=3D"ltr">On Thursday, December 4, 2014 9:15:16 PM UTC-8, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 4 December 20=
14 at 22:16, Douglas Boffey &lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"wZBbpraNVnoJ" onmousedown=3D"this.href=3D'javascrip=
t:';return true;" onclick=3D"this.href=3D'javascript:';return true;">dougla=
s...@gmail.com</a>&gt; wrote:
<br>&gt; Gcc uses the syntax ({ }) to embed statements within expressions.
<br>&gt; Should this be standardised?
<br>
<br>
<br>Why? If you want to embed statements into expressions, use a lambda.
<br></blockquote><div><br>({...})&nbsp; can be used inside a constant-expre=
ssion that's never evaluated (e.g. <span style=3D"font-family: courier new,=
monospace;">sizeof</span>) and lambda calls explicitly cannot be.<br><br>Me=
lissa<br></div></div>

<p></p>

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

------=_Part_3377_794157287.1418082156140--
------=_Part_3376_46556685.1418082156140--

.


Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 8 Dec 2014 17:25:17 -0800
Raw View
--047d7b343e5c70ead10509be6aaa
Content-Type: text/plain; charset=UTF-8

On Mon, Dec 8, 2014 at 3:42 PM, Myriachan <myriachan@gmail.com> wrote:

> On Thursday, December 4, 2014 9:15:16 PM UTC-8, Ville Voutilainen wrote:
>>
>> On 4 December 2014 at 22:16, Douglas Boffey <douglas...@gmail.com>
>> wrote:
>> > Gcc uses the syntax ({ }) to embed statements within expressions.
>> > Should this be standardised?
>>
>>
>> Why? If you want to embed statements into expressions, use a lambda.
>>
>
> ({...})  can be used inside a constant-expression that's never evaluated
> (e.g. sizeof) and lambda calls explicitly cannot be.
>

Statement-expressions have the same properties that resulted in this
prohibition for lambda-expressions; there's no reason to expect a different
outcome from using a different syntax.

That said, this restriction is now unnecessary, since
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1607 has
introduced different rules that achieve the effect that the ban on
lambda-expressions in unevaluated operands was supposed to achieve. I
suggested we should remove this rule when 1607 was discussed, but it was
deemed to be best handled as a separate extension / defect.

--

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

--047d7b343e5c70ead10509be6aaa
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 M=
on, Dec 8, 2014 at 3:42 PM, Myriachan <span dir=3D"ltr">&lt;<a href=3D"mail=
to:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, December 4, 2014=
 9:15:16 PM UTC-8, Ville Voutilainen wrote:<span class=3D""><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex=
">On 4 December 2014 at 22:16, Douglas Boffey &lt;<a>douglas...@gmail.com</=
a>&gt; wrote:
<br>&gt; Gcc uses the syntax ({ }) to embed statements within expressions.
<br>&gt; Should this be standardised?
<br>
<br>
<br>Why? If you want to embed statements into expressions, use a lambda.
<br></blockquote></span><div><br>({...})=C2=A0 can be used inside a constan=
t-expression that&#39;s never evaluated (e.g. <span style=3D"font-family:&#=
39;courier new&#39;,monospace">sizeof</span>) and lambda calls explicitly c=
annot be.</div></div></blockquote><div><br></div><div>Statement-expressions=
 have the same properties that resulted in this prohibition for lambda-expr=
essions; there&#39;s no reason to expect a different outcome from using a d=
ifferent syntax.</div><div><br></div><div>That said, this restriction is no=
w unnecessary, since <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs=
/cwg_defects.html#1607">http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_def=
ects.html#1607</a> has introduced different rules that achieve the effect t=
hat the ban on lambda-expressions in unevaluated operands was supposed to a=
chieve. I suggested we should remove this rule when 1607 was discussed, but=
 it was deemed to be best handled as a separate extension / defect.</div></=
div></div></div>

<p></p>

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

--047d7b343e5c70ead10509be6aaa--

.