------=_Part_51_1908046581.1430425997819
Content-Type: multipart/alternative;
 boundary="----=_Part_52_165586216.1430425997819"

------=_Part_52_165586216.1430425997819
Content-Type: text/plain; charset=UTF-8

Just saw it in Rust and immediately thought of the same in C++. The idea is
simple: Adjust the definition of *compound-statement* to

*compound-statement*
> *:**    { statement-seq*opt *expression*opt* }*


The optional *expression* is only allowed in the outermost
*compound-statement* of a *function-definition* or a *lambda-expression*.
And specify that if that syntax is used, it is equivalent (in definedness
and in meaning) to a *compound-statement* that includes the *statement-seq*
and returns *expression*.

This doesn't break anything, AFAICS. But it would be neat. Some functions
are one-liners, e.g. lambdas, and this could make their definition more
readable - e.g. in simple everyday situations:

std::transform(std::begin(a), std::end(a), std::begin(a), [] (auto i) { 4 *
i });

I believe this would be unanimously rejected by the committee, since the
readability - which is the only argument - is probably not convincing
enough for a core language change,
similar to e.g. terse range-based for loops (and a lot of people will argue
that it is generally less readable).
But I felt that I should probably ask about the general opinion on this
anyway.

--

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

<div dir=3D"ltr">Just saw it in Rust and immediately thought of the same in=
 C++. The idea is simple: Adjust the definition of <i>compound-statement</i=
> to<div><div><br></div><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-style: solid; padding-left: 1ex;"><i>compound-statement<=
/i><i>:<br></i><i>&nbsp; &nbsp; { statement-seq</i><font size=3D"1">opt&nbs=
p;</font><i>expression</i><font size=3D"1">opt</font><i>&nbsp;}</i></blockq=
uote></div><div><br></div><div>The optional <i>expression</i> is only allow=
ed in the outermost <i>compound-statement</i>&nbsp;of a <i>function-definit=
ion</i> or a <i>lambda-expression</i>.</div><div>And specify that if that s=
yntax is used, it is equivalent (in definedness and in meaning) to a <i>com=
pound-statement</i> that includes the <i>statement-seq</i> and returns <i>e=
xpression</i>.</div><div><br></div><div>This doesn't break anything, AFAICS=
.. But it would be neat. Some functions are one-liners, e.g. lambdas, and th=
is could make their definition more readable - e.g. in simple everyday situ=
ations:</div><div><br></div><div class=3D"prettyprint" style=3D"border: 1px=
 solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250=
, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">transform</span><span style=3D"colo=
r: #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: #008;" class=3D"styl=
ed-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=
">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">),</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">end</span><span style=3D"col=
or: #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"styl=
ed-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=
">begin</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=
: #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-b=
y-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> i</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: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">4</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"> i </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">});</span></div></code></div><div><br></div><div>I believe this would b=
e unanimously rejected by the committee, since the readability - which is t=
he only argument - is probably not convincing enough for a core language ch=
ange,</div><div>similar to e.g. terse range-based for loops (and a lot of p=
eople will argue that it is generally less readable).</div><div>But I felt =
that I should probably ask about the general opinion on this anyway.</div><=
/div>

<p></p>

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

------=_Part_52_165586216.1430425997819--
------=_Part_51_1908046581.1430425997819--

.

--089e013c66685a6b950514f72422
Content-Type: text/plain; charset=UTF-8

Hey,
I like this change but I think it should be limited to lambdas. In regular
function definitions it's really easy to miss and looks like a typo, but in
a short lambda its quite concise and clear.

Columbo <r.hl@gmx.net> schrieb am Do., 30. Apr. 2015 22:33:

> Just saw it in Rust and immediately thought of the same in C++. The idea
> is simple: Adjust the definition of *compound-statement* to
>
> *compound-statement*
>> *:**    { statement-seq*opt *expression*opt* }*
>
>
> The optional *expression* is only allowed in the outermost
> *compound-statement* of a *function-definition* or a *lambda-expression*.
> And specify that if that syntax is used, it is equivalent (in definedness
> and in meaning) to a *compound-statement* that includes the
> *statement-seq* and returns *expression*.
>
> This doesn't break anything, AFAICS. But it would be neat. Some functions
> are one-liners, e.g. lambdas, and this could make their definition more
> readable - e.g. in simple everyday situations:
>
> std::transform(std::begin(a), std::end(a), std::begin(a), [] (auto i) { 4
> * i });
>
> I believe this would be unanimously rejected by the committee, since the
> readability - which is the only argument - is probably not convincing
> enough for a core language change,
> similar to e.g. terse range-based for loops (and a lot of people will
> argue that it is generally less readable).
> But I felt that I should probably ask about the general opinion on this
> anyway.
>
> --
>
> ---
> 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/.
>

--

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

--089e013c66685a6b950514f72422
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Hey,<br>
I like this change but I think it should be limited to lambdas. In regular =
function definitions it&#39;s really easy to miss and looks like a typo, bu=
t in a short lambda its quite concise and clear. </p>

<br><div class=3D"gmail_quote">Columbo &lt;<a href=3D"mailto:r.hl@gmx.net" =
target=3D"_blank">r.hl@gmx.net</a>&gt; schrieb am Do., 30. Apr. 2015 22:33:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Just saw it in Rust and=
 immediately thought of the same in C++. The idea is simple: Adjust the def=
inition of <i>compound-statement</i> to<div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><i>compound-statement</i><i>:<br></i><i>=C2=A0 =C2=A0 { statement-seq</i><=
font size=3D"1">opt=C2=A0</font><i>expression</i><font size=3D"1">opt</font=
><i>=C2=A0}</i></blockquote></div><div><br></div><div>The optional <i>expre=
ssion</i> is only allowed in the outermost <i>compound-statement</i>=C2=A0o=
f a <i>function-definition</i> or a <i>lambda-expression</i>.</div><div>And=
 specify that if that syntax is used, it is equivalent (in definedness and =
in meaning) to a <i>compound-statement</i> that includes the <i>statement-s=
eq</i> and returns <i>expression</i>.</div><div><br></div><div>This doesn&#=
39;t break anything, AFAICS. But it would be neat. Some functions are one-l=
iners, e.g. lambdas, and this could make their definition more readable - e=
..g. in simple everyday situations:</div><div><br></div><div style=3D"border=
:1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,2=
50,250)"><code><div><span style=3D"color:#000">std</span><span style=3D"col=
or:#660">::</span><span style=3D"color:#000">transform</span><span style=3D=
"color:#660">(</span><span style=3D"color:#000">std</span><span style=3D"co=
lor:#660">::</span><span style=3D"color:#008">begin</span><span style=3D"co=
lor:#660">(</span><span style=3D"color:#000">a</span><span style=3D"color:#=
660">),</span><span style=3D"color:#000"> std</span><span style=3D"color:#6=
60">::</span><span style=3D"color:#008">end</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"> std</span><span style=3D"color:#660">::</=
span><span style=3D"color:#008">begin</span><span style=3D"color:#660">(</s=
pan><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><spa=
n style=3D"color:#000"> </span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#008">auto</span><span style=3D"color:#000"> i</span><span styl=
e=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"=
color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"color=
:#066">4</span><span style=3D"color:#000"> </span><span style=3D"color:#660=
">*</span><span style=3D"color:#000"> i </span><span style=3D"color:#660">}=
);</span></div></code></div><div><br></div><div>I believe this would be una=
nimously rejected by the committee, since the readability - which is the on=
ly argument - is probably not convincing enough for a core language change,=
</div><div>similar to e.g. terse range-based for loops (and a lot of people=
 will argue that it is generally less readable).</div><div>But I felt that =
I should probably ask about the general opinion on this anyway.</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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

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

--089e013c66685a6b950514f72422--

.

------=_Part_305_1284573422.1430427077378
Content-Type: multipart/alternative;
 boundary="----=_Part_306_1172400263.1430427077378"

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

Good point! I noticed that when right after posting, I tried to come up=20
with a good example for functions,=E2=80=A6 and couldn't. The relative size=
=20
decrease is simply not that big of a deal.

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

<div dir=3D"ltr">Good point! I noticed that when right after posting, I tri=
ed to come up with a good example for functions,=E2=80=A6 and couldn't. The=
 relative size decrease is simply not that big of a deal.</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_306_1172400263.1430427077378--
------=_Part_305_1284573422.1430427077378--

.

--001a1137c846595c750514f7420b
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 30, 2015 at 1:33 PM, Columbo <r.hl@gmx.net> wrote:

> Just saw it in Rust and immediately thought of the same in C++. The idea
> is simple: Adjust the definition of *compound-statement* to
>
> *compound-statement*
>> *:**    { statement-seq*opt *expression*opt* }*
>
>
> The optional *expression* is only allowed in the outermost
> *compound-statement* of a *function-definition* or a *lambda-expression*.
> And specify that if that syntax is used, it is equivalent (in definedness
> and in meaning) to a *compound-statement* that includes the
> *statement-seq* and returns *expression*.
>
> This doesn't break anything, AFAICS. But it would be neat.
>

It breaks on one-liners that are non-copyable or not movable, can imply
copies that cannot be elided even in the cases where the existing code had
an accessible constructor, and it changes return types of existing
functions from void to non-void, which can also be a breaking change. IIRC,
there was talk of making expression lambdas possible by removing the curly
braces. In other words ([](auto i) r * i). I don't remember if it was ever
formally proposed.

--

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

--001a1137c846595c750514f7420b
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, Apr 30, 2015 at 1:33 PM, Columbo <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:r.hl@gmx.net" target=3D"_blank">r.hl@gmx.net</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr">Just saw it in Rust and immedi=
ately thought of the same in C++. The idea is simple: Adjust the definition=
 of <i>compound-statement</i> to<div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-l=
eft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><i>com=
pound-statement</i><i>:<br></i><i>=C2=A0 =C2=A0 { statement-seq</i><font si=
ze=3D"1">opt=C2=A0</font><i>expression</i><font size=3D"1">opt</font><i>=C2=
=A0}</i></blockquote></div><div><br></div><div>The optional <i>expression</=
i> is only allowed in the outermost <i>compound-statement</i>=C2=A0of a <i>=
function-definition</i> or a <i>lambda-expression</i>.</div><div>And specif=
y that if that syntax is used, it is equivalent (in definedness and in mean=
ing) to a <i>compound-statement</i> that includes the <i>statement-seq</i> =
and returns <i>expression</i>.</div><div><br></div><div>This doesn&#39;t br=
eak anything, AFAICS. But it would be neat.</div></div></blockquote><div><b=
r></div><div>It breaks on one-liners that are non-copyable or not movable, =
can imply copies that cannot be elided even in the cases where the existing=
 code had an accessible constructor, and it changes return types of existin=
g functions from void to non-void, which can also be a breaking change. IIR=
C, there was talk of making expression lambdas possible by removing the cur=
ly braces. In other words ([](auto i) r * i). I don&#39;t remember if it wa=
s ever formally proposed.</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 />

--001a1137c846595c750514f7420b--

.

On Thu, Apr 30, 2015 at 01:33:17PM -0700, Columbo wrote:
> Just saw it in Rust and immediately thought of the same in C++. The idea is
> simple: Adjust the definition of *compound-statement* to
>
> *compound-statement*
> > *:**    { statement-seq*opt *expression*opt* }*

But how do you disambiguate between your optional expression and an
expression statment?

Consider

void foo()
{
  int a;
  [&a] () {
    a = 1;
  } ();
}

does this now "return a = 1;"?

and then

void foo()
{
  int a;
  [&a] () {
    if (a) return;
    a = 1;
  } ();
}

Would this then become ill-formed because of differing return types?


Christof

--

http://cmeerw.org                              sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.org

--

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

.

On Thu, Apr 30, 2015 at 4:55 PM, Christof Meerwald <cmeerw@cmeerw.org> wrote:
>
> Consider
>
> void foo()
> {
>   int a;
>   [&a] () {
>     a = 1;
>   } ();
> }
>
> does this now "return a = 1;"?

  a = 1;

is a statement not an expression, so not converted by the
proposed syntax.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd

--

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

.

On Thursday 30 April 2015 17:03:42 Zhihao Yuan wrote:
> On Thu, Apr 30, 2015 at 4:55 PM, Christof Meerwald <cmeerw@cmeerw.org>
wrote:
> > Consider
> >
> > void foo()
> > {
> >
> >   int a;
> >   [&a] () {
> >
> >     a = 1;
> >
> >   } ();
> >
> > }
> >
> > does this now "return a = 1;"?
>
>   a = 1;
>
> is a statement not an expression, so not converted by the
> proposed syntax.

The difference is just that semicolon. Looks like a very easy way to shoot
oneself in a foot.

--

---
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_328_488099679.1430429127470
Content-Type: multipart/alternative;
 boundary="----=_Part_329_103773413.1430429127470"

------=_Part_329_103773413.1430429127470
Content-Type: text/plain; charset=UTF-8


>
> It breaks on one-liners that are non-copyable or not movable, can imply
> copies that cannot be elided even in the cases where the existing code had
> an accessible constructor, and it changes return types of existing
> functions from void to non-void, which can also be a breaking change.


.... how?

--

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

<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex;">It breaks on one-liners that are non-copyable =
or not movable, can imply copies that cannot be elided even in the cases wh=
ere the existing code had an accessible constructor, and it changes return =
types of existing functions from void to non-void, which can also be a brea=
king change.</blockquote><div><br></div><div>... how?</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_329_103773413.1430429127470--
------=_Part_328_488099679.1430429127470--

.

------=_Part_6_1754637275.1430429182796
Content-Type: multipart/alternative;
 boundary="----=_Part_7_943240321.1430429182796"

------=_Part_7_943240321.1430429182796
Content-Type: text/plain; charset=UTF-8

Am Donnerstag, 30. April 2015 21:51:27 UTC+1 schrieb Matt Calabrese:
>
> It breaks on one-liners that are non-copyable or not movable, can imply
> copies that cannot be elided even in the cases where the existing code had
> an accessible constructor, and it changes return types of existing
> functions from void to non-void, which can also be a breaking change.
>

No, it doesn't. *expression* !=* expression-statement*.

--

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

<div dir=3D"ltr">Am Donnerstag, 30. April 2015 21:51:27 UTC+1 schrieb Matt =
Calabrese:<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 class=3D"gmail_quote"><div>It breaks on one-liners that are non-copy=
able or not movable, can imply copies that cannot be elided even in the cas=
es where the existing code had an accessible constructor, and it changes re=
turn types of existing functions from void to non-void, which can also be a=
 breaking change.</div></div></div></div></blockquote><div><br></div><div>N=
o, it doesn't. <i>expression</i> !=3D<i> expression-statement</i>.&nbsp;<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_7_943240321.1430429182796--
------=_Part_6_1754637275.1430429182796--

.

--001a11c2e64c296c9b0514f7c142
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 30, 2015 at 2:26 PM, Columbo <r.hl@gmx.net> wrote:

> Am Donnerstag, 30. April 2015 21:51:27 UTC+1 schrieb Matt Calabrese:
>>
>> It breaks on one-liners that are non-copyable or not movable, can imply
>> copies that cannot be elided even in the cases where the existing code had
>> an accessible constructor, and it changes return types of existing
>> functions from void to non-void, which can also be a breaking change.
>>
>
> No, it doesn't. *expression* !=* expression-statement*.
>

Ah, I missed the lack of semicolon!

--

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

--001a11c2e64c296c9b0514f7c142
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, Apr 30, 2015 at 2:26 PM, Columbo <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:r.hl@gmx.net" target=3D"_blank">r.hl@gmx.net</a>&gt;</span> wrote:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">Am Donnerstag=
, 30. April 2015 21:51:27 UTC+1 schrieb Matt Calabrese:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>I=
t breaks on one-liners that are non-copyable or not movable, can imply copi=
es that cannot be elided even in the cases where the existing code had an a=
ccessible constructor, and it changes return types of existing functions fr=
om void to non-void, which can also be a breaking change.</div></div></div>=
</div></blockquote><div><br></div></span><div>No, it doesn&#39;t. <i>expres=
sion</i> !=3D<i> expression-statement</i>.=C2=A0</div></div></blockquote><d=
iv><br></div><div>Ah, I missed the lack of semicolon!=C2=A0</div></div></di=
v></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 />

--001a11c2e64c296c9b0514f7c142--

.

------=_Part_201_1114343916.1430429770463
Content-Type: multipart/alternative;
 boundary="----=_Part_202_1471573997.1430429770469"

------=_Part_202_1471573997.1430429770469
Content-Type: text/plain; charset=UTF-8

I like allowing a single *expression *to be the body of a lambda;
permitting an arbitrary number of statements
before that seems too error-prone and doesn't really improve readability.
[](auto i) { i * 4 } looks nice,
[](auto i) { lots_of_stuff_here(); for(;;) { lots_of_stuff_here_too(); } i *
 4 }, not so much.


On Thursday, April 30, 2015 at 4:33:17 PM UTC-4, Columbo wrote:
>
> Just saw it in Rust and immediately thought of the same in C++. The idea
> is simple: Adjust the definition of *compound-statement* to
>
> *compound-statement*
>> *:**    { statement-seq*opt *expression*opt* }*
>
>
> The optional *expression* is only allowed in the outermost
> *compound-statement* of a *function-definition* or a *lambda-expression*.
> And specify that if that syntax is used, it is equivalent (in definedness
> and in meaning) to a *compound-statement* that includes the
> *statement-seq* and returns *expression*.
>
> This doesn't break anything, AFAICS. But it would be neat. Some functions
> are one-liners, e.g. lambdas, and this could make their definition more
> readable - e.g. in simple everyday situations:
>
> std::transform(std::begin(a), std::end(a), std::begin(a), [] (auto i) { 4
> * i });
>
> I believe this would be unanimously rejected by the committee, since the
> readability - which is the only argument - is probably not convincing
> enough for a core language change,
> similar to e.g. terse range-based for loops (and a lot of people will
> argue that it is generally less readable).
> But I felt that I should probably ask about the general opinion on this
> anyway.
>

--

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

<div dir=3D"ltr">I like allowing a single <i>expression </i>to be the body =
of a lambda; permitting an arbitrary number of statements&nbsp;<div>before =
that seems too error-prone and doesn't really improve readability. &nbsp;<s=
pan class=3D"styled-by-prettify" style=3D"font-family: monospace; color: rg=
b(102, 102, 0); background-color: rgb(250, 250, 250);">[](</span><span clas=
s=3D"styled-by-prettify" style=3D"font-family: monospace; color: rgb(0, 0, =
136); background-color: rgb(250, 250, 250);">auto</span><span class=3D"styl=
ed-by-prettify" style=3D"font-family: monospace; color: rgb(0, 0, 0); backg=
round-color: rgb(250, 250, 250);">&nbsp;i</span><span class=3D"styled-by-pr=
ettify" style=3D"font-family: monospace; color: rgb(102, 102, 0); backgroun=
d-color: rgb(250, 250, 250);">)</span><span class=3D"styled-by-prettify" st=
yle=3D"font-family: monospace; color: rgb(0, 0, 0); background-color: rgb(2=
50, 250, 250);">&nbsp;</span><span class=3D"styled-by-prettify" style=3D"fo=
nt-family: monospace; color: rgb(102, 102, 0); background-color: rgb(250, 2=
50, 250);">{</span><span class=3D"styled-by-prettify" style=3D"font-family:=
 monospace; color: rgb(0, 0, 0); background-color: rgb(250, 250, 250);">&nb=
sp;i&nbsp;</span><span class=3D"styled-by-prettify" style=3D"font-family: m=
onospace; color: rgb(102, 102, 0); background-color: rgb(250, 250, 250);">*=
</span><span class=3D"styled-by-prettify" style=3D"font-family: monospace; =
color: rgb(0, 0, 0); background-color: rgb(250, 250, 250);">&nbsp;</span><s=
pan class=3D"styled-by-prettify" style=3D"font-family: monospace; color: rg=
b(0, 102, 102); background-color: rgb(250, 250, 250);">4</span><span class=
=3D"styled-by-prettify" style=3D"font-family: monospace; color: rgb(0, 0, 0=
); background-color: rgb(250, 250, 250);">&nbsp;</span><span class=3D"style=
d-by-prettify" style=3D"font-family: monospace; color: rgb(102, 102, 0); ba=
ckground-color: rgb(250, 250, 250);">}</span>&nbsp;looks nice,</div><div><s=
pan class=3D"styled-by-prettify" style=3D"font-family: monospace; color: rg=
b(102, 102, 0); background-color: rgb(250, 250, 250);">[](</span><span clas=
s=3D"styled-by-prettify" style=3D"font-family: monospace; color: rgb(0, 0, =
136); background-color: rgb(250, 250, 250);">auto</span><span class=3D"styl=
ed-by-prettify" style=3D"font-family: monospace; color: rgb(0, 0, 0); backg=
round-color: rgb(250, 250, 250);">&nbsp;i</span><span class=3D"styled-by-pr=
ettify" style=3D"font-family: monospace; color: rgb(102, 102, 0); backgroun=
d-color: rgb(250, 250, 250);">)</span><span class=3D"styled-by-prettify" st=
yle=3D"font-family: monospace; color: rgb(0, 0, 0); background-color: rgb(2=
50, 250, 250);">&nbsp;</span><span class=3D"styled-by-prettify" style=3D"fo=
nt-family: monospace; color: rgb(102, 102, 0); background-color: rgb(250, 2=
50, 250);">{ lots_of_stuff_here(); for(;;) { lots_of_stuff_here_too(); }</s=
pan><span class=3D"styled-by-prettify" style=3D"font-family: monospace; col=
or: rgb(0, 0, 0); background-color: rgb(250, 250, 250);">&nbsp;i&nbsp;</spa=
n><span class=3D"styled-by-prettify" style=3D"font-family: monospace; color=
: rgb(102, 102, 0); background-color: rgb(250, 250, 250);">*</span><span cl=
ass=3D"styled-by-prettify" style=3D"font-family: monospace; color: rgb(0, 0=
, 0); background-color: rgb(250, 250, 250);">&nbsp;</span><span class=3D"st=
yled-by-prettify" style=3D"font-family: monospace; color: rgb(0, 102, 102);=
 background-color: rgb(250, 250, 250);">4</span><span class=3D"styled-by-pr=
ettify" style=3D"font-family: monospace; color: rgb(0, 0, 0); background-co=
lor: rgb(250, 250, 250);">&nbsp;</span><span class=3D"styled-by-prettify" s=
tyle=3D"font-family: monospace; color: rgb(102, 102, 0); background-color: =
rgb(250, 250, 250);">}</span>,&nbsp;not so much.<div><div><div><div><br></d=
iv><div><br>On Thursday, April 30, 2015 at 4:33:17 PM UTC-4, Columbo wrote:=
<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">Just saw it i=
n Rust and immediately thought of the same in C++. The idea is simple: Adju=
st the definition of <i>compound-statement</i> to<div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-w=
idth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding=
-left:1ex"><i>compound-statement</i><i>:<br></i><i>&nbsp; &nbsp; { statemen=
t-seq</i><font size=3D"1">opt&nbsp;</font><i>expression</i><font size=3D"1"=
>opt</font><i><wbr>&nbsp;}</i></blockquote></div><div><br></div><div>The op=
tional <i>expression</i> is only allowed in the outermost <i>compound-state=
ment</i>&nbsp;of a <i>function-definition</i> or a <i>lambda-expression</i>=
..</div><div>And specify that if that syntax is used, it is equivalent (in d=
efinedness and in meaning) to a <i>compound-statement</i> that includes the=
 <i>statement-seq</i> and returns <i>expression</i>.</div><div><br></div><d=
iv>This doesn't break anything, AFAICS. But it would be neat. Some function=
s are one-liners, e.g. lambdas, and this could make their definition more r=
eadable - e.g. in simple everyday situations:</div><div><br></div><div styl=
e=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-colo=
r:rgb(250,250,250)"><code><div><span style=3D"color:#000">std</span><span s=
tyle=3D"color:#660">::</span><span style=3D"color:#000">transform</span><sp=
an style=3D"color:#660">(</span><span style=3D"color:#000">std</span><span =
style=3D"color:#660">::</span><span style=3D"color:#008">begin</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"> std</span><span style=
=3D"color:#660">::</span><span style=3D"color:#008">end</span><span style=
=3D"color:#660">(</span><span style=3D"color:#000">a</span><span style=3D"c=
olor:#660">),</span><span style=3D"color:#000"> std</span><span style=3D"co=
lor:#660">::</span><span style=3D"color:#008">begin</span><span style=3D"co=
lor:#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 style=3D"color:#660">(</=
span><span style=3D"color:#008">auto</span><span style=3D"color:#000"> i</s=
pan><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 =
style=3D"color:#066">4</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">*</span><span style=3D"color:#000"> i </span><span style=3D=
"color:#660">});</span></div></code></div><div><br></div><div>I believe thi=
s would be unanimously rejected by the committee, since the readability - w=
hich is the only argument - is probably not convincing enough for a core la=
nguage change,</div><div>similar to e.g. terse range-based for loops (and a=
 lot of people will argue that it is generally less readable).</div><div>Bu=
t I felt that I should probably ask about the general opinion on this anywa=
y.</div></div></blockquote></div></div></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 />

------=_Part_202_1471573997.1430429770469--
------=_Part_201_1114343916.1430429770463--

.

On Thu, Apr 30, 2015 at 05:03:42PM -0400, Zhihao Yuan wrote:
> On Thu, Apr 30, 2015 at 4:55 PM, Christof Meerwald <cmeerw@cmeerw.org> wrote:
> >
> > Consider
> >
> > void foo()
> > {
> >   int a;
> >   [&a] () {
> >     a = 1;
> >   } ();
> > }
> >
> > does this now "return a = 1;"?
>
>   a = 1;
>
> is a statement not an expression, so not converted by the
> proposed syntax.

Ahh, yes, of course... Ok, I don't like the idea then. :)


Christof

--

http://cmeerw.org                              sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org                   xmpp:cmeerw at cmeerw.org

--

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

.

On 1 May 2015 at 00:36, T. C. <rs2740@gmail.com> wrote:
> I like allowing a single expression to be the body of a lambda; permitting


This was considered in Portland 2012, when reviewing
http://open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3418.pdf.
That proposal went even further and left out the braces. Even so, the implicit
return was rejected.

--

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

.