------=_Part_724_138720025.1480690148487
Content-Type: multipart/alternative;
 boundary="----=_Part_725_781528534.1480690148487"

------=_Part_725_781528534.1480690148487
Content-Type: text/plain; charset=UTF-8

Good code vs.Bad Code

#define LAMBA [=]

menu1.callback("Log->Clear", LAMBDA() {dosomething1(); dosomthing2()});

^^^ Abouve with Inferred last semi-colon: LOOKS GOOD, but a compiler
error.
Why not make it legal to infer the last semicolon in a curly brace block?


Compiles... but the syntax gets on your nerves:

        menu1.callback("Log->Clear", [=]() {dosomething1();
dosomthing2();}); //extra semicolon at the end


sure Laugh now.  But all those semicolons add up in a large program...


Actually while we are on this one.  I always like the "perl feature of
allowing extra "commas" when defining a list.  this feature sames a huge
amount of lot of time when writing programs that write programs without all
the extra garbage code needed to detect the end of list to remove comma at
the end of the list:

GOOD:  (thank you perl)
  vector<string> blah {
    "one",
    "two",
    "three",  // <= extra comma ok... ignored without warn
  };

BAD: (no thanks c++: lighten up a little bit c++ compiler... )
  vector<string> blah {
    "one",
    "two",
..    "three"  // <=== no comma allowed here... now all of my loops need
extra if block to detect end of list when writing programs that write
programs...
  };

now you are asking... why on earth would anybody ever want to write a
program that writes a program?
it happens more often than you think...





--
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/99df401b-562e-424f-9c17-01575f8b47e1%40isocpp.org.

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

<div dir=3D"ltr">Good code vs.Bad Code<br><br>#define LAMBA [=3D]<br><br>me=
nu1.callback(&quot;Log-&gt;Clear&quot;, LAMBDA() {dosomething1(); dosomthin=
g2()});<br><br>^^^ Abouve with Inferred last semi-colon: LOOKS GOOD, but a =
compiler error.=C2=A0 <br>Why not make=20
it legal to infer the last semicolon in a curly brace block? <br><br><br>Co=
mpiles... but the syntax gets on your nerves:<br><br>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 menu1.callback(&quot;Log-&gt;Clear&quot;, [=3D]() {do=
something1(); dosomthing2();}); //extra semicolon at the end<br><br><br>sur=
e Laugh now.=C2=A0 But all those semicolons add up in a large program...<br=
><br><br>Actually while we are on this one.=C2=A0 I always like the &quot;p=
erl feature of allowing extra &quot;commas&quot; when defining a list.=C2=
=A0 this feature sames a huge amount of lot of time when writing programs t=
hat write programs without all the extra garbage code needed to detect the =
end of list to remove comma at the end of the list:<br><br>GOOD:=C2=A0 (tha=
nk you perl)<br>=C2=A0 vector&lt;string&gt; blah {<br>=C2=A0=C2=A0=C2=A0 &q=
uot;one&quot;,<br>=C2=A0=C2=A0=C2=A0 &quot;two&quot;,<br>=C2=A0=C2=A0=C2=A0=
 &quot;three&quot;,=C2=A0 // &lt;=3D extra comma ok... ignored without warn=
<br>=C2=A0 };<br><br>BAD: (no thanks c++: lighten up a little bit c++ compi=
ler... )<br>=C2=A0 vector&lt;string&gt; blah {<br>=C2=A0=C2=A0=C2=A0 &quot;=
one&quot;,<br>=C2=A0=C2=A0=C2=A0 &quot;two&quot;,<br>. =C2=A0=C2=A0 &quot;t=
hree&quot;=C2=A0 // &lt;=3D=3D=3D no comma allowed here... now all of my lo=
ops need extra if block to detect end of list when writing programs that wr=
ite programs...<br>=C2=A0 };<br><br>now you are asking... why on earth woul=
d anybody ever want to write a program that writes a program?<br>it happens=
 more often than you think...<br><br><br><br><br><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/99df401b-562e-424f-9c17-01575f8b47e1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/99df401b-562e-424f-9c17-01575f8b47e1=
%40isocpp.org</a>.<br />

------=_Part_725_781528534.1480690148487--

------=_Part_724_138720025.1480690148487--

.