------=_Part_799_461170577.1469377966032
Content-Type: multipart/alternative;
 boundary="----=_Part_800_1386279712.1469377966032"

------=_Part_800_1386279712.1469377966032
Content-Type: text/plain; charset=UTF-8

STL proposed:
for (elem : range) { ... }

as synonymous with:
for (auto&& elem : range ) { ... }

This apparently got dropped from the ballot in Urbana. Does anybody know
why it 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e03d2317-d1d1-490c-8ec8-71f8ac67d84a%40isocpp.org.

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

<div dir=3D"ltr">STL proposed:<div><div class=3D"prettyprint" style=3D"bord=
er: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: =
rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><font color=3D"#660066"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">for</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">elem </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> range</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </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">=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
/font></div></code></div><br>as synonymous with:</div><div><div class=3D"pr=
ettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-=
word; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><font color=3D"#660066"><span style=3D"color: #=
008;" class=3D"styled-by-prettify">for</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">auto</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&amp;&amp;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> elem </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> range </=
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"> </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></font></div></code></div><div><br></div>This appare=
ntly got dropped from the ballot in Urbana. Does anybody know why it was re=
jected?<br></div></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/e03d2317-d1d1-490c-8ec8-71f8ac67d84a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e03d2317-d1d1-490c-8ec8-71f8ac67d84a=
%40isocpp.org</a>.<br />

------=_Part_800_1386279712.1469377966032--

------=_Part_799_461170577.1469377966032--

.

On 24 July 2016 at 19:32, Barry Revzin <barry.revzin@gmail.com> wrote:
> STL proposed:
> for (elem : range) { ... }
>
> as synonymous with:
> for (auto&& elem : range ) { ... }
>
> This apparently got dropped from the ballot in Urbana. Does anybody know why
> it was rejected?


Mostly because 'elem' can shadow names in the surrounding scope, and
such shadowing was deemed too subtle.
The opponents thought that even making such shadowing ill-formed
wouldn't change their mind. I can find some remarks
according to which introducing names without types is problematic for
some people. See
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4251.html
and search for "Straw poll, CWG Motion 15"

--
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/CAFk2RUba3NbmYBwoUFvVZTd-T9i7CHKzwfs26CdKK744GRF%3D0w%40mail.gmail.com.

.

------=_Part_1803_180797191.1469587153977
Content-Type: multipart/alternative;
 boundary="----=_Part_1804_577273677.1469587153977"

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

=E5=9C=A8 2016=E5=B9=B47=E6=9C=8825=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8A=E5=8D=8812:44:34=EF=BC=8CVille Voutilainen=E5=86=99=E9=81=93=EF=
=BC=9A
>
> On 24 July 2016 at 19:32, Barry Revzin <barry....@gmail.com <javascript:>=
>=20
> wrote:=20
> > STL proposed:=20
> > for (elem : range) { ... }=20
> >=20
> > as synonymous with:=20
> > for (auto&& elem : range ) { ... }=20
> >=20
> > This apparently got dropped from the ballot in Urbana. Does anybody kno=
w=20
> why=20
> > it was rejected?=20
>
>
> Mostly because 'elem' can shadow names in the surrounding scope, and=20
> such shadowing was deemed too subtle.=20
> The opponents thought that even making such shadowing ill-formed=20
> wouldn't change their mind. I can find some remarks=20
>
according to which introducing names without types is problematic for=20
> some people. See=20
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4251.html=20
> and search for "Straw poll, CWG Motion 15"=20
>

I don't know why they were worrying about that. First, a variable=20
introduced by declaration ensures there exists the declarator of type, but=
=20
not the type of that variable. To expect a variable mapping to some type in=
=20
a first glance of its declaration is already error-prone. The only sensible=
=20
way is to fully read and parse the declaration. Then, why the implicit=20
'auto&&' is a problem? It actually hides some semantic noise as well as=20
syntactic one. Second, as said, lambda initializers have already invalidate=
=20
the assumption of the existence of a declarator of some variable.

=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ad45d2a4-430a-4423-96d8-b275251d1f2f%40isocpp.or=
g.

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

<div dir=3D"ltr">=E5=9C=A8 2016=E5=B9=B47=E6=9C=8825=E6=97=A5=E6=98=9F=E6=
=9C=9F=E4=B8=80 UTC+8=E4=B8=8A=E5=8D=8812:44:34=EF=BC=8CVille Voutilainen=
=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On =
24 July 2016 at 19:32, Barry Revzin &lt;<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"nWgKM4Q_BAAJ" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">barry....@gmail.com</a>&gt; wrote:
<br>&gt; STL proposed:
<br>&gt; for (elem : range) { ... }
<br>&gt;
<br>&gt; as synonymous with:
<br>&gt; for (auto&amp;&amp; elem : range ) { ... }
<br>&gt;
<br>&gt; This apparently got dropped from the ballot in Urbana. Does anybod=
y know why
<br>&gt; it was rejected?
<br>
<br>
<br>Mostly because &#39;elem&#39; can shadow names in the surrounding scope=
, and
<br>such shadowing was deemed too subtle.
<br>The opponents thought that even making such shadowing ill-formed
<br>wouldn&#39;t change their mind. I can find some remarks
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">according to =
which introducing names without types is problematic for
<br>some people. See
<br><a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4251.ht=
ml" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FWG21%2=
Fdocs%2Fpapers%2F2014%2Fn4251.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCN=
H2STechkAU2HXSDSlyY4-Azqvz3A&#39;;return true;" onclick=3D"this.href=3D&#39=
;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2FSC22%2FW=
G21%2Fdocs%2Fpapers%2F2014%2Fn4251.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dA=
FQjCNH2STechkAU2HXSDSlyY4-Azqvz3A&#39;;return true;">http://open-std.org/JT=
C1/SC22/<wbr>WG21/docs/papers/2014/n4251.<wbr>html</a>
<br>and search for &quot;Straw poll, CWG Motion 15&quot;
<br></blockquote><div><br>I don&#39;t know why they were worrying about tha=
t. First, a variable introduced by declaration ensures there exists the dec=
larator of type, but not the type of that variable. To expect a variable ma=
pping to some type in a first glance of its declaration is already error-pr=
one. The only sensible way is to fully read and parse the declaration. Then=
, why the implicit &#39;auto&amp;&amp;&#39; is a problem? It actually hides=
 some semantic noise as well as syntactic one. Second, as said, lambda init=
ializers have already invalidate the assumption of the existence of a decla=
rator of some variable.<br><br>=C2=A0<br></div></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/ad45d2a4-430a-4423-96d8-b275251d1f2f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ad45d2a4-430a-4423-96d8-b275251d1f2f=
%40isocpp.org</a>.<br />

------=_Part_1804_577273677.1469587153977--

------=_Part_1803_180797191.1469587153977--

.

On 2016-07-27 04:39, FrankHB1989 wrote:
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8825=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 U=
TC+8=E4=B8=8A=E5=8D=8812:44:34=EF=BC=8CVille Voutilainen=E5=86=99=E9=81=93=
=EF=BC=9A
>
>     On 24 July 2016 at 19:32, Barry Revzin <barry....@gmail.com
>     <javascript:>> wrote:
>     > STL proposed:
>     > for (elem : range) { ... }
>     >
>     > as synonymous with:
>     > for (auto&& elem : range ) { ... }
>     >
>     > This apparently got dropped from the ballot in Urbana. Does
>     anybody know why
>     > it was rejected?
>
>
>     Mostly because 'elem' can shadow names in the surrounding scope, and
>     such shadowing was deemed too subtle.
>     The opponents thought that even making such shadowing ill-formed
>     wouldn't change their mind. I can find some remarks
>
>     according to which introducing names without types is problematic for
>     some people. See
>     http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4251.html
>     <http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4251.html>
>     and search for "Straw poll, CWG Motion 15"
>
>
> I don't know why they were worrying about that. First, a variable
> introduced by declaration ensures there exists the declarator of type,
> but not the type of that variable. To expect a variable mapping to some
> type in a first glance of its declaration is already error-prone. The
> only sensible way is to fully read and parse the declaration. Then, why
> the implicit 'auto&&' is a problem? It actually hides some semantic
> noise as well as syntactic one. Second, as said, lambda initializers
> have already invalidate the assumption of the existence of a declarator
> of some variable.
>

I believe the committee saw the "subtleness" in comparing

int i;
for (i =3D 0; i !=3D 10; ++i)       // reusing outer i
for (int i =3D 0; i !=3D 10; ++i)   // introduces a new variable

and

int i;
for (i : range)        // reusing outer i? no?
for (int i : range)    // introduces a new variable

How are we to recognize that the second version introduces a new=20
variable in both cases, but the first one does not?



     Bo Persson


--=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/nna2o8%24hhh%241%40ger.gmane.org.

.

--001a11468e08a4220d05389bbee6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 27, 2016 at 11:34 AM, Bo Persson <bop@gmb.dk> wrote:

> On 2016-07-27 04:39, FrankHB1989 wrote:
>
>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8825=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 =
UTC+8=E4=B8=8A=E5=8D=8812:44:34=EF=BC=8CVille Voutilainen=E5=86=99=E9=81=93=
=EF=BC=9A
>>
>>     On 24 July 2016 at 19:32, Barry Revzin <barry....@gmail.com
>>     <javascript:>> wrote:
>>     > STL proposed:
>>     > for (elem : range) { ... }
>>     >
>>     > as synonymous with:
>>     > for (auto&& elem : range ) { ... }
>>     >
>>     > This apparently got dropped from the ballot in Urbana. Does
>>     anybody know why
>>     > it was rejected?
>>
>>
>>     Mostly because 'elem' can shadow names in the surrounding scope, and
>>     such shadowing was deemed too subtle.
>>     The opponents thought that even making such shadowing ill-formed
>>     wouldn't change their mind. I can find some remarks
>>
>>     according to which introducing names without types is problematic fo=
r
>>     some people. See
>>     http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4251.html
>>     <http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4251.html>
>>     and search for "Straw poll, CWG Motion 15"
>>
>>
>> I don't know why they were worrying about that. First, a variable
>> introduced by declaration ensures there exists the declarator of type,
>> but not the type of that variable. To expect a variable mapping to some
>> type in a first glance of its declaration is already error-prone. The
>> only sensible way is to fully read and parse the declaration. Then, why
>> the implicit 'auto&&' is a problem? It actually hides some semantic
>> noise as well as syntactic one. Second, as said, lambda initializers
>> have already invalidate the assumption of the existence of a declarator
>> of some variable.
>>
>>
> I believe the committee saw the "subtleness" in comparing
>
> int i;
> for (i =3D 0; i !=3D 10; ++i)       // reusing outer i
> for (int i =3D 0; i !=3D 10; ++i)   // introduces a new variable
>
> and
>
> int i;
> for (i : range)        // reusing outer i? no?
> for (int i : range)    // introduces a new variable
>
> How are we to recognize that the second version introduces a new variable
> in both cases, but the first one does not?
>


For sure. It really doesn't cost anything to type auto &&, IMO. And
certainly isn't worth that much ambiguity.

--=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/CACGiwhG75KORTQJw4dtWFa-9ZwZCBicw3mwcmwfx%2By1Fk=
hpHMg%40mail.gmail.com.

--001a11468e08a4220d05389bbee6
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 W=
ed, Jul 27, 2016 at 11:34 AM, Bo Persson <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:bop@gmb.dk" target=3D"_blank">bop@gmb.dk</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"><span class=3D"">On 2016-07-27 04:39, FrankHB19=
89 wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span class=3D"">
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8825=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8A=E5=8D=8812:44:34=EF=BC=8CVille Voutilainen=E5=86=99=E9=81=93=EF=
=BC=9A<br>
<br>
=C2=A0 =C2=A0 On 24 July 2016 at 19:32, Barry Revzin &lt;<a href=3D"mailto:=
barry....@gmail.com" target=3D"_blank">barry....@gmail.com</a><br></span><d=
iv><div class=3D"h5">
=C2=A0 =C2=A0 &lt;javascript:&gt;&gt; wrote:<br>
=C2=A0 =C2=A0 &gt; STL proposed:<br>
=C2=A0 =C2=A0 &gt; for (elem : range) { ... }<br>
=C2=A0 =C2=A0 &gt;<br>
=C2=A0 =C2=A0 &gt; as synonymous with:<br>
=C2=A0 =C2=A0 &gt; for (auto&amp;&amp; elem : range ) { ... }<br>
=C2=A0 =C2=A0 &gt;<br>
=C2=A0 =C2=A0 &gt; This apparently got dropped from the ballot in Urbana. D=
oes<br>
=C2=A0 =C2=A0 anybody know why<br>
=C2=A0 =C2=A0 &gt; it was rejected?<br>
<br>
<br>
=C2=A0 =C2=A0 Mostly because &#39;elem&#39; can shadow names in the surroun=
ding scope, and<br>
=C2=A0 =C2=A0 such shadowing was deemed too subtle.<br>
=C2=A0 =C2=A0 The opponents thought that even making such shadowing ill-for=
med<br>
=C2=A0 =C2=A0 wouldn&#39;t change their mind. I can find some remarks<br>
<br>
=C2=A0 =C2=A0 according to which introducing names without types is problem=
atic for<br>
=C2=A0 =C2=A0 some people. See<br>
=C2=A0 =C2=A0 <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/201=
4/n4251.html" rel=3D"noreferrer" target=3D"_blank">http://open-std.org/JTC1=
/SC22/WG21/docs/papers/2014/n4251.html</a><br>
=C2=A0 =C2=A0 &lt;<a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers=
/2014/n4251.html" rel=3D"noreferrer" target=3D"_blank">http://open-std.org/=
JTC1/SC22/WG21/docs/papers/2014/n4251.html</a>&gt;<br>
=C2=A0 =C2=A0 and search for &quot;Straw poll, CWG Motion 15&quot;<br>
<br>
<br>
I don&#39;t know why they were worrying about that. First, a variable<br>
introduced by declaration ensures there exists the declarator of type,<br>
but not the type of that variable. To expect a variable mapping to some<br>
type in a first glance of its declaration is already error-prone. The<br>
only sensible way is to fully read and parse the declaration. Then, why<br>
the implicit &#39;auto&amp;&amp;&#39; is a problem? It actually hides some =
semantic<br>
noise as well as syntactic one. Second, as said, lambda initializers<br>
have already invalidate the assumption of the existence of a declarator<br>
of some variable.<br>
<br>
</div></div></blockquote>
<br>
I believe the committee saw the &quot;subtleness&quot; in comparing<br>
<br>
int i;<br>
for (i =3D 0; i !=3D 10; ++i)=C2=A0 =C2=A0 =C2=A0 =C2=A0// reusing outer i<=
br>
for (int i =3D 0; i !=3D 10; ++i)=C2=A0 =C2=A0// introduces a new variable<=
br>
<br>
and<br>
<br>
int i;<br>
for (i : range)=C2=A0 =C2=A0 =C2=A0 =C2=A0 // reusing outer i? no?<br>
for (int i : range)=C2=A0 =C2=A0 // introduces a new variable<br>
<br>
How are we to recognize that the second version introduces a new variable i=
n both cases, but the first one does not?<br></blockquote><div><br><br></di=
v><div>For sure. It really doesn&#39;t cost anything to type auto &amp;&amp=
;, IMO. And certainly isn&#39;t worth that much ambiguity. <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&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/CACGiwhG75KORTQJw4dtWFa-9ZwZCBicw3mwc=
mwfx%2By1FkhpHMg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhG75KORTQ=
Jw4dtWFa-9ZwZCBicw3mwcmwfx%2By1FkhpHMg%40mail.gmail.com</a>.<br />

--001a11468e08a4220d05389bbee6--

.

--047d7ba974d6b7d6a80538a05f1d
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 27, 2016 at 6:47 AM, D. B. <db0451@gmail.com> wrote:

> On Wed, Jul 27, 2016 at 11:34 AM, Bo Persson <bop@gmb.dk> wrote:
>
>>
>> int i;
>> for (i = 0; i != 10; ++i)       // reusing outer i
>> for (int i = 0; i != 10; ++i)   // introduces a new variable
>>
>> and
>>
>> int i;
>> for (i : range)        // reusing outer i? no?
>> for (int i : range)    // introduces a new variable
>>
>> How are we to recognize that the second version introduces a new variable
>> in both cases, but the first one does not?
>>
>
>
> For sure. It really doesn't cost anything to type auto &&, IMO. And
> certainly isn't worth that much ambiguity.
>
>
It is not the cost of typing, it is the cost of understanding auto &&.  It
would be nice if a common usage was easier to learn.
But still not worth the price, IMO.

I think there are people still planning on proposing something in this area.

Tony

--
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/CAOHCbitEG6uChd%3DD_TwE-h7e4Ekf_GaqJXH%3DqPN1a%3DqNJ6NbCA%40mail.gmail.com.

--047d7ba974d6b7d6a80538a05f1d
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 Wed, Jul 27, 2016 at 6:47 AM, D. B. <span dir=3D"ltr">&lt;<a href=3D=
"mailto:db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><div><div class=3D"h5">On Wed, Jul 27=
, 2016 at 11:34 AM, Bo Persson <span dir=3D"ltr">&lt;<a href=3D"mailto:bop@=
gmb.dk" target=3D"_blank">bop@gmb.dk</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><br>
int i;<br>
for (i =3D 0; i !=3D 10; ++i)=C2=A0 =C2=A0 =C2=A0 =C2=A0// reusing outer i<=
br>
for (int i =3D 0; i !=3D 10; ++i)=C2=A0 =C2=A0// introduces a new variable<=
br>
<br>
and<br>
<br>
int i;<br>
for (i : range)=C2=A0 =C2=A0 =C2=A0 =C2=A0 // reusing outer i? no?<br>
for (int i : range)=C2=A0 =C2=A0 // introduces a new variable<br>
<br>
How are we to recognize that the second version introduces a new variable i=
n both cases, but the first one does not?<br></blockquote><div><br><br></di=
v></div></div><div>For sure. It really doesn&#39;t cost anything to type au=
to &amp;&amp;, IMO. And certainly isn&#39;t worth that much ambiguity. <br>=
</div></div></div></div><span class=3D"">

<p></p></span></blockquote><div><br></div><div>It is not the cost of typing=
, it is the cost of understanding auto &amp;&amp;.=C2=A0 It would be nice i=
f a common usage was easier to learn.<br>But still not worth the price, IMO=
.. <br><br></div><div>I think there are people still planning on proposing s=
omething in this area.<br><br></div><div>Tony<br><br></div></div></div></di=
v>

<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/CAOHCbitEG6uChd%3DD_TwE-h7e4Ekf_GaqJX=
H%3DqPN1a%3DqNJ6NbCA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitEG6=
uChd%3DD_TwE-h7e4Ekf_GaqJXH%3DqPN1a%3DqNJ6NbCA%40mail.gmail.com</a>.<br />

--047d7ba974d6b7d6a80538a05f1d--

.

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

auto&& is trivial to understand and learn. What's the problem?

On Wed, Jul 27, 2016 at 12:18 PM, Tony V E <tvaneerd@gmail.com> wrote:

>
>
> On Wed, Jul 27, 2016 at 6:47 AM, D. B. <db0451@gmail.com> wrote:
>
>> On Wed, Jul 27, 2016 at 11:34 AM, Bo Persson <bop@gmb.dk> wrote:
>>
>>>
>>> int i;
>>> for (i = 0; i != 10; ++i)       // reusing outer i
>>> for (int i = 0; i != 10; ++i)   // introduces a new variable
>>>
>>> and
>>>
>>> int i;
>>> for (i : range)        // reusing outer i? no?
>>> for (int i : range)    // introduces a new variable
>>>
>>> How are we to recognize that the second version introduces a new
>>> variable in both cases, but the first one does not?
>>>
>>
>>
>> For sure. It really doesn't cost anything to type auto &&, IMO. And
>> certainly isn't worth that much ambiguity.
>>
>>
> It is not the cost of typing, it is the cost of understanding auto &&.  It
> would be nice if a common usage was easier to learn.
> But still not worth the price, IMO.
>
> I think there are people still planning on proposing something in this
> area.
>
> Tony
>
> --
> 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/CAOHCbitEG6uChd%3DD_TwE-h7e4Ekf_GaqJXH%3DqPN1a%3DqNJ6NbCA%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbitEG6uChd%3DD_TwE-h7e4Ekf_GaqJXH%3DqPN1a%3DqNJ6NbCA%40mail.gmail.com?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/CAMD6iD8mz0OKvc%3DWigWYxAgEo%3D9E%3DmSA%2Bc43YCThgRrAjgo1Hg%40mail.gmail.com.

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

<div dir=3D"ltr">auto&amp;&amp; is trivial to understand and learn. What&#3=
9;s the problem?</div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">On Wed, Jul 27, 2016 at 12:18 PM, Tony V E <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><di=
v class=3D"gmail_extra"><br><div class=3D"gmail_quote"><span class=3D"">On =
Wed, Jul 27, 2016 at 6:47 AM, D. B. <span dir=3D"ltr">&lt;<a href=3D"mailto=
:db0451@gmail.com" target=3D"_blank">db0451@gmail.com</a>&gt;</span> wrote:=
<br></span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><div><div><span class=3D"">On Wed, Ju=
l 27, 2016 at 11:34 AM, Bo Persson <span dir=3D"ltr">&lt;<a href=3D"mailto:=
bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a>&gt;</span> wrote:<br></span><s=
pan class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><br>
int i;<br>
for (i =3D 0; i !=3D 10; ++i)=C2=A0 =C2=A0 =C2=A0 =C2=A0// reusing outer i<=
br>
for (int i =3D 0; i !=3D 10; ++i)=C2=A0 =C2=A0// introduces a new variable<=
br>
<br>
and<br>
<br>
int i;<br>
for (i : range)=C2=A0 =C2=A0 =C2=A0 =C2=A0 // reusing outer i? no?<br>
for (int i : range)=C2=A0 =C2=A0 // introduces a new variable<br>
<br>
How are we to recognize that the second version introduces a new variable i=
n both cases, but the first one does not?<br></blockquote><div><br><br></di=
v></span></div></div><span class=3D""><div>For sure. It really doesn&#39;t =
cost anything to type auto &amp;&amp;, IMO. And certainly isn&#39;t worth t=
hat much ambiguity. <br></div></span></div></div></div><span>

<p></p></span></blockquote><div><br></div><div>It is not the cost of typing=
, it is the cost of understanding auto &amp;&amp;.=C2=A0 It would be nice i=
f a common usage was easier to learn.<br>But still not worth the price, IMO=
.. <br><br></div><div>I think there are people still planning on proposing s=
omething in this area.<br><br></div><div>Tony<br><br></div></div></div></di=
v><span class=3D"">

<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" 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></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAOHCbitEG6uChd%3DD_TwE-h7e4Ekf_GaqJX=
H%3DqPN1a%3DqNJ6NbCA%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAOHCbitEG6uChd%3DD_TwE-h7e4Ekf_GaqJXH%3DqPN1a%3DqNJ6NbCA%40mail=
..gmail.com</a>.<br>
</blockquote></div><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/CAMD6iD8mz0OKvc%3DWigWYxAgEo%3D9E%3Dm=
SA%2Bc43YCThgRrAjgo1Hg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD8m=
z0OKvc%3DWigWYxAgEo%3D9E%3DmSA%2Bc43YCThgRrAjgo1Hg%40mail.gmail.com</a>.<br=
 />

--001a113f3d023e3be80538a08d8c--

.

------=_Part_274_1634865276.1469638585254
Content-Type: multipart/alternative;
 boundary="----=_Part_275_1403696586.1469638585255"

------=_Part_275_1403696586.1469638585255
Content-Type: text/plain; charset=UTF-8

On Wednesday, July 27, 2016 at 12:31:40 PM UTC-4, Ren Industries wrote:
>
> auto&& is trivial to understand and learn. What's the problem?
>

Learning to type `auto&&` in that case is "trivial to understand and
learn". But that's hardly understanding *why* you're doing that instead of
just `auto`, which is what many people are being trained to use whenever
they declare variables.

--
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/550fdf4e-4257-4e6d-a5cd-6aabd832e937%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, July 27, 2016 at 12:31:40 PM UTC-4, Ren Indu=
stries wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
auto&amp;&amp; is trivial to understand and learn. What&#39;s the problem?<=
/div></blockquote><div><br>Learning to type `auto&amp;&amp;` in that case i=
s &quot;trivial to understand and learn&quot;. But that&#39;s hardly unders=
tanding <i>why</i> you&#39;re doing that instead of just `auto`, which is w=
hat many people are being trained to use whenever they declare variables.<b=
r></div></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/550fdf4e-4257-4e6d-a5cd-6aabd832e937%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/550fdf4e-4257-4e6d-a5cd-6aabd832e937=
%40isocpp.org</a>.<br />

------=_Part_275_1403696586.1469638585255--

------=_Part_274_1634865276.1469638585254--

.

------=_Part_1487_1331564297.1469703859107
Content-Type: multipart/alternative;
 boundary="----=_Part_1488_1105739310.1469703859108"

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



=E5=9C=A8 2016=E5=B9=B47=E6=9C=8827=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89 UTC=
+8=E4=B8=8B=E5=8D=886:47:35=EF=BC=8CD. B.=E5=86=99=E9=81=93=EF=BC=9A
>
> On Wed, Jul 27, 2016 at 11:34 AM, Bo Persson <b...@gmb.dk <javascript:>>=
=20
> wrote:
>
>> On 2016-07-27 04:39, FrankHB1989 wrote:
>>
>>> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8825=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80=
 UTC+8=E4=B8=8A=E5=8D=8812:44:34=EF=BC=8CVille Voutilainen=E5=86=99=E9=81=
=93=EF=BC=9A
>>>
>>>     On 24 July 2016 at 19:32, Barry Revzin <barry....@gmail.com
>>>     <javascript:>> wrote:
>>>     > STL proposed:
>>>     > for (elem : range) { ... }
>>>     >
>>>     > as synonymous with:
>>>     > for (auto&& elem : range ) { ... }
>>>     >
>>>     > This apparently got dropped from the ballot in Urbana. Does
>>>     anybody know why
>>>     > it was rejected?
>>>
>>>
>>>     Mostly because 'elem' can shadow names in the surrounding scope, an=
d
>>>     such shadowing was deemed too subtle.
>>>     The opponents thought that even making such shadowing ill-formed
>>>     wouldn't change their mind. I can find some remarks
>>>
>>>     according to which introducing names without types is problematic f=
or
>>>     some people. See
>>>     http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4251.html
>>>     <http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n4251.html>
>>>     and search for "Straw poll, CWG Motion 15"
>>>
>>>
>>> I don't know why they were worrying about that. First, a variable
>>> introduced by declaration ensures there exists the declarator of type,
>>> but not the type of that variable. To expect a variable mapping to some
>>> type in a first glance of its declaration is already error-prone. The
>>> only sensible way is to fully read and parse the declaration. Then, why
>>> the implicit 'auto&&' is a problem? It actually hides some semantic
>>> noise as well as syntactic one. Second, as said, lambda initializers
>>> have already invalidate the assumption of the existence of a declarator
>>> of some variable.
>>>
>>>
>> I believe the committee saw the "subtleness" in comparing
>>
>> int i;
>> for (i =3D 0; i !=3D 10; ++i)       // reusing outer i
>> for (int i =3D 0; i !=3D 10; ++i)   // introduces a new variable
>>
>> and
>>
>> int i;
>> for (i : range)        // reusing outer i? no?
>> for (int i : range)    // introduces a new variable
>>
>> How are we to recognize that the second version introduces a new variabl=
e=20
>> in both cases, but the first one does not?
>>
>
>
> For sure. It really doesn't cost anything to type auto &&, IMO. And=20
> certainly isn't worth that much ambiguity.=20
>
=20
Maybe. I actually don't care much about the extra typing, though I don't=20
like to see redundant syntactic noise when reading, either.

But I really don't appreciate the reason of rejection here, as most excuses=
=20
raised about readability in disputation on endorsement of using of `auto`=
=20
by default. (Teachability issue sounds more plausible to me.)

Parsing the contents between lparan and the initial semicolon after several=
=20
tokens in a 'for' statement should be trivial daily work for C++ users.=20
Note there is no ambiguity in grammar simply due to different 'for'=20
statement once you have parsed the init-statement correctly. It should not=
=20
be ambiguous easily for anyone who does read it carefully enough, otherwise=
=20
the code must be badly constructed. Anyway, this kind of work can't be=20
omitted if you want to know the meaning for the code. So I can hardly=20
believe it is a real problem.

For the code illustrated... I think it would always be subtle enough if you=
=20
only show the 'for' statement without the dummy variable declaration near=
=20
the code. Keep them compact, please.

BTW, I have no need to target pre-C99 ancient dialects or (damnit!) VC6, so=
=20
I haven't written 'for' statement whose init-statement is not a declaration=
=20
for years. Everything is OK.

I'd even be glad if the ancient form of 'for' statement is deprecated, just=
=20
to reduce the amount of naive excuses.

--=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/c8de07c2-c932-4e92-925a-4b07c30a4093%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8827=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=B8=89 UTC+8=E4=B8=8B=E5=8D=886:47:35=EF=BC=8CD. B.=E5=86=99=
=E9=81=93=EF=BC=9A<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"><div><div class=3D"gmail_quote">On Wed, Jul 27, 2016 at 11:34 AM, Bo P=
ersson <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"GbSL15bkBAAJ" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;">b...@gmb.dk</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><span>On 2016-07-27 04:39, FrankHB1989 wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span>
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8825=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80 UTC=
+8=E4=B8=8A=E5=8D=8812:44:34=EF=BC=8CVille Voutilainen=E5=86=99=E9=81=93=EF=
=BC=9A<br>
<br>
=C2=A0 =C2=A0 On 24 July 2016 at 19:32, Barry Revzin &lt;<a>barry....@gmail=
..com</a><br></span><div><div>
=C2=A0 =C2=A0 &lt;javascript:&gt;&gt; wrote:<br>
=C2=A0 =C2=A0 &gt; STL proposed:<br>
=C2=A0 =C2=A0 &gt; for (elem : range) { ... }<br>
=C2=A0 =C2=A0 &gt;<br>
=C2=A0 =C2=A0 &gt; as synonymous with:<br>
=C2=A0 =C2=A0 &gt; for (auto&amp;&amp; elem : range ) { ... }<br>
=C2=A0 =C2=A0 &gt;<br>
=C2=A0 =C2=A0 &gt; This apparently got dropped from the ballot in Urbana. D=
oes<br>
=C2=A0 =C2=A0 anybody know why<br>
=C2=A0 =C2=A0 &gt; it was rejected?<br>
<br>
<br>
=C2=A0 =C2=A0 Mostly because &#39;elem&#39; can shadow names in the surroun=
ding scope, and<br>
=C2=A0 =C2=A0 such shadowing was deemed too subtle.<br>
=C2=A0 =C2=A0 The opponents thought that even making such shadowing ill-for=
med<br>
=C2=A0 =C2=A0 wouldn&#39;t change their mind. I can find some remarks<br>
<br>
=C2=A0 =C2=A0 according to which introducing names without types is problem=
atic for<br>
=C2=A0 =C2=A0 some people. See<br>
=C2=A0 =C2=A0 <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/201=
4/n4251.html" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2FS=
C22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn4251.html\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNH2STechkAU2HXSDSlyY4-Azqvz3A&#39;;return true;" onclick=3D"this=
..href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC=
1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn4251.html\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNH2STechkAU2HXSDSlyY4-Azqvz3A&#39;;return true;">http://ope=
n-std.org/JTC1/SC22/<wbr>WG21/docs/papers/2014/n4251.<wbr>html</a><br>
=C2=A0 =C2=A0 &lt;<a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers=
/2014/n4251.html" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJTC1%2=
FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn4251.html\x26sa\x3dD\x26sntz\x3d1\x2=
6usg\x3dAFQjCNH2STechkAU2HXSDSlyY4-Azqvz3A&#39;;return true;" onclick=3D"th=
is.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fopen-std.org%2FJ=
TC1%2FSC22%2FWG21%2Fdocs%2Fpapers%2F2014%2Fn4251.html\x26sa\x3dD\x26sntz\x3=
d1\x26usg\x3dAFQjCNH2STechkAU2HXSDSlyY4-Azqvz3A&#39;;return true;">http://o=
pen-std.org/JTC1/<wbr>SC22/WG21/docs/papers/2014/<wbr>n4251.html</a>&gt;<br=
>
=C2=A0 =C2=A0 and search for &quot;Straw poll, CWG Motion 15&quot;<br>
<br>
<br>
I don&#39;t know why they were worrying about that. First, a variable<br>
introduced by declaration ensures there exists the declarator of type,<br>
but not the type of that variable. To expect a variable mapping to some<br>
type in a first glance of its declaration is already error-prone. The<br>
only sensible way is to fully read and parse the declaration. Then, why<br>
the implicit &#39;auto&amp;&amp;&#39; is a problem? It actually hides some =
semantic<br>
noise as well as syntactic one. Second, as said, lambda initializers<br>
have already invalidate the assumption of the existence of a declarator<br>
of some variable.<br>
<br>
</div></div></blockquote>
<br>
I believe the committee saw the &quot;subtleness&quot; in comparing<br>
<br>
int i;<br>
for (i =3D 0; i !=3D 10; ++i)=C2=A0 =C2=A0 =C2=A0 =C2=A0// reusing outer i<=
br>
for (int i =3D 0; i !=3D 10; ++i)=C2=A0 =C2=A0// introduces a new variable<=
br>
<br>
and<br>
<br>
int i;<br>
for (i : range)=C2=A0 =C2=A0 =C2=A0 =C2=A0 // reusing outer i? no?<br>
for (int i : range)=C2=A0 =C2=A0 // introduces a new variable<br>
<br>
How are we to recognize that the second version introduces a new variable i=
n both cases, but the first one does not?<br></blockquote><div><br><br></di=
v><div>For sure. It really doesn&#39;t cost anything to type auto &amp;&amp=
;, IMO. And certainly isn&#39;t worth that much ambiguity. <br></div></div>=
</div></div></blockquote><div>=C2=A0<br>Maybe. I actually don&#39;t care mu=
ch about the extra typing, though I don&#39;t like to see redundant syntact=
ic noise when reading, either.<br><br>But I really don&#39;t appreciate the=
 reason of rejection here, as most excuses raised about readability in disp=
utation on endorsement of using of `auto` by default. (Teachability issue s=
ounds more plausible to me.)<br><br>Parsing the contents between lparan and=
 the initial semicolon after several tokens in a &#39;for&#39; statement sh=
ould be trivial daily work for C++ users. Note there is no ambiguity in gra=
mmar simply due to different &#39;for&#39; statement once you have parsed t=
he init-statement correctly. It should not be ambiguous easily for anyone w=
ho does read it carefully enough, otherwise the code must be badly construc=
ted. Anyway, this kind of work can&#39;t be omitted if you want to know the=
 meaning for the code. So I can hardly believe it is a real problem.<br><br=
>For the code illustrated... I think it would always be subtle enough if=20
you only show the &#39;for&#39; statement without the dummy variable=20
declaration near the code. Keep them compact, please.<br><br>BTW, I have no=
 need to target pre-C99 ancient dialects or (damnit!) VC6, so I haven&#39;t=
 written &#39;for&#39; statement whose init-statement is not a declaration =
for years. Everything is OK.<br><br>I&#39;d even be glad if the ancient for=
m of &#39;for&#39; statement is deprecated, just to reduce the amount of na=
ive excuses.<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&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/c8de07c2-c932-4e92-925a-4b07c30a4093%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c8de07c2-c932-4e92-925a-4b07c30a4093=
%40isocpp.org</a>.<br />

------=_Part_1488_1105739310.1469703859108--

------=_Part_1487_1331564297.1469703859107--

.

On 2016-07-28 07:04, FrankHB1989 wrote:
> I'd even be glad if the ancient form of 'for' statement is deprecated, just
> to reduce the amount of naive excuses.

No. Declaring the iterator outside the loop also preserves its value
outside the loop. That is sometimes useful. Perhaps even more so with
range-based for which is less easily rewritten as a while loop.

--
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/nnd895%24l6m%241%40ger.gmane.org.

.

------=_Part_473_2114895753.1469872607784
Content-Type: multipart/alternative;
 boundary="----=_Part_474_2145608112.1469872607785"

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



=E5=9C=A8 2016=E5=B9=B47=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8A=E5=8D=887:20:15=EF=BC=8CMatthew Woehlke=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On 2016-07-28 07:04, FrankHB1989 wrote:=20
> > I'd even be glad if the ancient form of 'for' statement is deprecated,=
=20
> just=20
> > to reduce the amount of naive excuses.=20
>
> No. Declaring the iterator outside the loop also preserves its value=20
> outside the loop. That is sometimes useful. Perhaps even more so with=20
> range-based for which is less easily rewritten as a while loop.=20
>
> --=20
> Matthew=20
>
> No. I did not suggest that. However, for any loop like

for(i =3D first; i !=3D last; ++i)
 //...;

Practically, you should always be allowed to rewrite it as

i =3D first;
for(; i !=3D last; ++i) // Where the first ';' is an empty declaration.
 //...

Or even:

i =3D first;
while(i !=3D last)
{
  //...
  ++i;
}
As long as the names do not clash. Anyway, 'for' statement is a kind of=20
syntax sugar. There is no need to have more than one flavor to work in=20
general.

And unless you like extra '{}' around the loop, you have to allow the=20
scoped syntax to avoid name pollution out of the loop in some cases, which=
=20
are perhaps more common. (I also don't like raw do-while statement because=
=20
it can't work in this way well.)


=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b7f06b25-5bc5-4597-876f-a0ba92fb6ae7%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8830=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=887:20:15=EF=BC=8CMatthew Woehlk=
e=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On=
 2016-07-28 07:04, FrankHB1989 wrote:
<br>&gt; I&#39;d even be glad if the ancient form of &#39;for&#39; statemen=
t is deprecated, just=20
<br>&gt; to reduce the amount of naive excuses.
<br>
<br>No. Declaring the iterator outside the loop also preserves its value
<br>outside the loop. That is sometimes useful. Perhaps even more so with
<br>range-based for which is less easily rewritten as a while loop.
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div>No. I did not suggest that. However, for any loop lik=
e<br><br>for(i =3D first; i !=3D last; ++i)<br>=C2=A0//...;<br><br>Practica=
lly, you should always be allowed to rewrite it as<br><br>i =3D first;<br>f=
or(; i !=3D last; ++i) // Where the first &#39;;&#39; is an empty declarati=
on.<br>=C2=A0//...<br><br>Or even:<br><br>i =3D first;<br>while(i !=3D last=
)<br>{<br>=C2=A0 //...<br>=C2=A0 ++i;<br>}<br>As long as the names do not c=
lash. Anyway, &#39;for&#39; statement is a kind of syntax sugar. There is n=
o need to have more than one flavor to work in general.<br><br>And unless y=
ou like extra &#39;{}&#39; around the loop, you have to allow the scoped sy=
ntax to avoid name pollution out of the loop in some cases, which are perha=
ps more common. (I also don&#39;t like raw do-while statement because it ca=
n&#39;t work in this way well.)<br><br><br>=C2=A0<br></div></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/b7f06b25-5bc5-4597-876f-a0ba92fb6ae7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b7f06b25-5bc5-4597-876f-a0ba92fb6ae7=
%40isocpp.org</a>.<br />

------=_Part_474_2145608112.1469872607785--

------=_Part_473_2114895753.1469872607784--

.

--047d7b6d9bfaeece040538d81eb4
Content-Type: text/plain; charset=UTF-8

On Sat, Jul 30, 2016 at 10:56 AM, FrankHB1989 <frankhb1989@gmail.com> wrote:

> And unless you like extra '{}' around the loop, you have to allow the
> scoped syntax to avoid name pollution out of the loop in some cases, which
> are perhaps more common. (I also don't like raw do-while statement because
> it can't work in this way well.)
>

Speaking of which, I've been wondering why there was no *while (type t =
f(); t--) { /*...*/ }* accepted alongside the *if* and *switch* versions
coming in C++17.

I can only assume that it's because you can already do the same thing
using *for
(type t = f(); t--; )* but then since we're already redundant, it wouldn't
have hurt to add it for *while* too, surely?

Also, *for* doesn't cover the same semantics as do, so we could also add
that:

* do ( type t = f() ) { /*...*/ } while ( cond() );*
Might as well be consistent, otherwise the *while* keywords look kinda
unmaintained and like they're kept around for compatibility only.

--
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/CACGiwhF3d5SmKzdoY_KJstVF46WJL0F3ynE7YM%2BeG44oJZoFoA%40mail.gmail.com.

--047d7b6d9bfaeece040538d81eb4
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=
at, Jul 30, 2016 at 10:56 AM, FrankHB1989 <span dir=3D"ltr">&lt;<a href=3D"=
mailto:frankhb1989@gmail.com" target=3D"_blank">frankhb1989@gmail.com</a>&g=
t;</span> wrote:<br><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 =
dir=3D"ltr">And unless you like extra &#39;{}&#39; around the loop, you hav=
e to allow the=20
scoped syntax to avoid name pollution out of the loop in some cases,=20
which are perhaps more common. (I also don&#39;t like raw do-while statemen=
t
 because it can&#39;t work in this way well.)</div></blockquote><div><br></=
div><div>Speaking of which, I&#39;ve been wondering why there was no <i>whi=
le (type t =3D f(); t--) { /*...*/ }</i> accepted alongside the <i>if</i> a=
nd <i>switch</i> versions coming in C++17.<br><br>I can only assume that it=
&#39;s because you can already do the same thing using <i>for (type t =3D f=
(); t--; )</i> but then since we&#39;re already redundant, it wouldn&#39;t =
have hurt to add it for <i>while</i> too, surely?<br><br></div><div>Also, <=
i>for</i> doesn&#39;t cover the same semantics as do, so we could also add =
that:<i> do ( type t =3D f() ) { /*...*/ } while ( cond() );<br><br></i></d=
iv><div>Might as well be consistent, otherwise the <i>while</i> keywords lo=
ok kinda unmaintained and like they&#39;re kept around for compatibility on=
ly.<br><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&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/CACGiwhF3d5SmKzdoY_KJstVF46WJL0F3ynE7=
YM%2BeG44oJZoFoA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhF3d5SmKz=
doY_KJstVF46WJL0F3ynE7YM%2BeG44oJZoFoA%40mail.gmail.com</a>.<br />

--047d7b6d9bfaeece040538d81eb4--

.

------=_Part_1536_1423662677.1469894535806
Content-Type: multipart/alternative;
 boundary="----=_Part_1537_1892467605.1469894535806"

------=_Part_1537_1892467605.1469894535806
Content-Type: text/plain; charset=UTF-8

On Saturday, July 30, 2016 at 6:49:33 AM UTC-4, D. B. wrote:
>
> On Sat, Jul 30, 2016 at 10:56 AM, FrankHB1989 <frank...@gmail.com
> <javascript:>> wrote:
>
>> And unless you like extra '{}' around the loop, you have to allow the
>> scoped syntax to avoid name pollution out of the loop in some cases, which
>> are perhaps more common. (I also don't like raw do-while statement because
>> it can't work in this way well.)
>>
>
> Speaking of which, I've been wondering why there was no *while (type t =
> f(); t--) { /*...*/ }* accepted alongside the *if* and *switch* versions
> coming in C++17.
>

>
I can only assume that it's because you can already do the same thing using *for
> (type t = f(); t--; )* but then since we're already redundant, it
> wouldn't have hurt to add it for *while* too, surely?
>
> Also, *for* doesn't cover the same semantics as do, so we could also add
> that:
>
> * do ( type t = f() ) { /*...*/ } while ( cond() );*
> Might as well be consistent, otherwise the *while* keywords look kinda
> unmaintained and like they're kept around for compatibility only.
>

Well, they kinda are. Not for compatibility, but for the same reason we
keep `goto` around. Because sometimes, you really need that one special
tool, and it'd better be in your toolbox when you need it.

That doesn't mean it needs to be the most well-polished tool in your box.

Think about the ratio of `while` loops to `for` loops in your code. Think
about the ratio of `while` loops to `do/while`. And the ratio of all of
them to the number of `goto`. And with range-based algorithms, adapters,
filters, and so forth on the way, these kinds of explicit control
structures are only going to get even more rare.

So what's does it matter if they "look kinda unmaintained"? As long as
they're in your toolbox when the need arises, it's fine. Indeed, the lack
of elegant features helps get across the idea that these things should be
avoided where reasonable.

--
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/8b8d3a3a-66e2-4fee-b17f-c64618654458%40isocpp.org.

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

<div dir=3D"ltr">On Saturday, July 30, 2016 at 6:49:33 AM UTC-4, D. B. wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div c=
lass=3D"gmail_quote">On Sat, Jul 30, 2016 at 10:56 AM, FrankHB1989 <span di=
r=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"TwRXA6ADBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;">frank...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr">And unless you like extra &#39=
;{}&#39; around the loop, you have to allow the=20
scoped syntax to avoid name pollution out of the loop in some cases,=20
which are perhaps more common. (I also don&#39;t like raw do-while statemen=
t
 because it can&#39;t work in this way well.)</div></blockquote><div><br></=
div><div>Speaking of which, I&#39;ve been wondering why there was no <i>whi=
le (type t =3D f(); t--) { /*...*/ }</i> accepted alongside the <i>if</i> a=
nd <i>switch</i> versions coming in C++17.<br></div></div></div></div></blo=
ckquote><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px so=
lid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><div>=C2=
=A0</div></blockquote><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"><div>I can only assume that it&#39=
;s because you can already do the same thing using <i>for (type t =3D f(); =
t--; )</i> but then since we&#39;re already redundant, it wouldn&#39;t have=
 hurt to add it for <i>while</i> too, surely?<br><br></div><div>Also, <i>fo=
r</i> doesn&#39;t cover the same semantics as do, so we could also add that=
:<i> do ( type t =3D f() ) { /*...*/ } while ( cond() );<br><br></i></div><=
div>Might as well be consistent, otherwise the <i>while</i> keywords look k=
inda unmaintained and like they&#39;re kept around for compatibility only.<=
br></div></div></div></div></blockquote><div><br>Well, they kinda are. Not =
for compatibility, but for the same reason we keep `goto` around. Because s=
ometimes, you really need that one special tool, and it&#39;d better be in =
your toolbox when you need it.<br><br>That doesn&#39;t mean it needs to be =
the most well-polished tool in your box.<br><br>Think about the ratio of `w=
hile` loops to `for` loops in your code. Think about the ratio of `while` l=
oops to `do/while`. And the ratio of all of them to the number of `goto`. A=
nd with range-based algorithms, adapters, filters, and so forth on the way,=
 these kinds of explicit control structures are only going to get even more=
 rare.<br><br>So what&#39;s does it matter if they &quot;look kinda unmaint=
ained&quot;? As long as they&#39;re in your toolbox when the need arises, i=
t&#39;s fine. Indeed, the lack of elegant features helps get across the ide=
a that these things should be avoided where reasonable.<br></div></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/8b8d3a3a-66e2-4fee-b17f-c64618654458%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8b8d3a3a-66e2-4fee-b17f-c64618654458=
%40isocpp.org</a>.<br />

------=_Part_1537_1892467605.1469894535806--

------=_Part_1536_1423662677.1469894535806--

.

------=_Part_3_1218383233.1470022461929
Content-Type: multipart/alternative;
 boundary="----=_Part_4_851601.1470022461929"

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



=E5=9C=A8 2016=E5=B9=B47=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8B=E5=8D=886:49:33=EF=BC=8CD. B.=E5=86=99=E9=81=93=EF=BC=9A
>
> On Sat, Jul 30, 2016 at 10:56 AM, FrankHB1989 <frank...@gmail.com=20
> <javascript:>> wrote:
>
>> And unless you like extra '{}' around the loop, you have to allow the=20
>> scoped syntax to avoid name pollution out of the loop in some cases, whi=
ch=20
>> are perhaps more common. (I also don't like raw do-while statement becau=
se=20
>> it can't work in this way well.)
>>
>
> Speaking of which, I've been wondering why there was no *while (type t =
=3D=20
> f(); t--) { /*...*/ }* accepted alongside the *if* and *switch* versions=
=20
> coming in C++17.
>
> I can only assume that it's because you can already do the same thing=20
> using *for (type t =3D f(); t--; )* but then since we're already redundan=
t,=20
> it wouldn't have hurt to add it for *while* too, surely?
>
> Also, *for* doesn't cover the same semantics as do, so we could also add=
=20
> that:
>
> * do ( type t =3D f() ) { /*...*/ } while ( cond() );*
>
I personally even do not use "do-while" statement at all, exception a few=
=20
cases. This is because the code is often concerned with variable only=20
living in the scope of the loop body plus the condition, and "do-while"=20
will almost always pollute the enclosing scope, leading to more pressure=20
about naming. Instead, I invent my own wheel=20
<https://bitbucket.org/FrankHB/yslib/src/4988c8a0fe703d0c27bfb030c61e77cf02=
d717b9/YBase/include/ystdex/functional.hpp#functional.hpp-1019>,=20
specifically to replace almost all ordinary instances of "do-while"=20
statement - not too intuitive, but handy. This eventually eliminate for new=
=20
core features. (BTW, regular void=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0146r1.html> will=
=20
make it easier...)

=20

> Might as well be consistent, otherwise the *while* keywords look kinda=20
> unmaintained and like they're kept around for compatibility only.
>
>

--=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/91b076be-cbf9-4ba3-9db8-677c189d583b%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8830=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8B=E5=8D=886:49:33=EF=BC=8CD. B.=E5=86=99=
=E9=81=93=EF=BC=9A<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"><div><div class=3D"gmail_quote">On Sat, Jul 30, 2016 at 10:56 AM, Fran=
kHB1989 <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"TwRXA6ADBgAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">frank...@gmail.com</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">And unless you=
 like extra &#39;{}&#39; around the loop, you have to allow the=20
scoped syntax to avoid name pollution out of the loop in some cases,=20
which are perhaps more common. (I also don&#39;t like raw do-while statemen=
t
 because it can&#39;t work in this way well.)</div></blockquote><div><br></=
div><div>Speaking of which, I&#39;ve been wondering why there was no <i>whi=
le (type t =3D f(); t--) { /*...*/ }</i> accepted alongside the <i>if</i> a=
nd <i>switch</i> versions coming in C++17.<br><br>I can only assume that it=
&#39;s because you can already do the same thing using <i>for (type t =3D f=
(); t--; )</i> but then since we&#39;re already redundant, it wouldn&#39;t =
have hurt to add it for <i>while</i> too, surely?<br><br></div><div>Also, <=
i>for</i> doesn&#39;t cover the same semantics as do, so we could also add =
that:<i> do ( type t =3D f() ) { /*...*/ } while ( cond() );<br><br></i></d=
iv></div></div></div></blockquote><div>I personally even do not use &quot;d=
o-while&quot; statement at all, exception a few cases. This is because the =
code is often concerned with variable only living in the scope of the loop =
body plus the condition, and &quot;do-while&quot; will almost always pollut=
e the enclosing scope, leading to more pressure about naming. Instead, I in=
vent <a href=3D"https://bitbucket.org/FrankHB/yslib/src/4988c8a0fe703d0c27b=
fb030c61e77cf02d717b9/YBase/include/ystdex/functional.hpp#functional.hpp-10=
19">my own wheel</a>, specifically to replace almost all ordinary instances=
 of &quot;do-while&quot; statement - not too intuitive, but handy. This eve=
ntually eliminate for new core features. (BTW, <a href=3D"http://www.open-s=
td.org/jtc1/sc22/wg21/docs/papers/2016/p0146r1.html">regular void</a> will =
make it easier...)<br><br>=C2=A0<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"><div><div class=3D"gmail_quote"><div><i></i></=
div><div>Might as well be consistent, otherwise the <i>while</i> keywords l=
ook kinda unmaintained and like they&#39;re kept around for compatibility o=
nly.<br><br></div></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&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/91b076be-cbf9-4ba3-9db8-677c189d583b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/91b076be-cbf9-4ba3-9db8-677c189d583b=
%40isocpp.org</a>.<br />

------=_Part_4_851601.1470022461929--

------=_Part_3_1218383233.1470022461929--

.

On 2016-07-30 05:56, FrankHB1989 wrote:
> =E5=9C=A8 2016=E5=B9=B47=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD U=
TC+8=E4=B8=8A=E5=8D=887:20:15=EF=BC=8CMatthew Woehlke=E5=86=99=E9=81=93=EF=
=BC=9A
>> On 2016-07-28 07:04, FrankHB1989 wrote:=20
>>> I'd even be glad if the ancient form of 'for' statement is deprecated,=
=20
>>> just to reduce the amount of naive excuses.=20
>>
>> No. Declaring the iterator outside the loop also preserves its value=20
>> outside the loop. That is sometimes useful. Perhaps even more so with=20
>> range-based for which is less easily rewritten as a while loop.=20
>
> No. I did not suggest that [...]

I'm confused. I thought the suggestion was to make 'for(var : ...)' to
*always* mean 'for(atuo&& var : ...)'. If not, then never mind :-).

--=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/nnnlap%24ab%241%40blaine.gmane.org.

.

------=_Part_828_1790364445.1470640546405
Content-Type: multipart/alternative;
 boundary="----=_Part_829_665424925.1470640546405"

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



=E5=9C=A8 2016=E5=B9=B48=E6=9C=884=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UTC+=
8=E4=B8=8A=E5=8D=8812:16:56=EF=BC=8CMatthew Woehlke=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On 2016-07-30 05:56, FrankHB1989 wrote:=20
> > =E5=9C=A8 2016=E5=B9=B47=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD=
 UTC+8=E4=B8=8A=E5=8D=887:20:15=EF=BC=8CMatthew Woehlke=E5=86=99=E9=81=93=
=EF=BC=9A=20
> >> On 2016-07-28 07:04, FrankHB1989 wrote:=20
> >>> I'd even be glad if the ancient form of 'for' statement is deprecated=
,=20
> >>> just to reduce the amount of naive excuses.=20
> >>=20
> >> No. Declaring the iterator outside the loop also preserves its value=
=20
> >> outside the loop. That is sometimes useful. Perhaps even more so with=
=20
> >> range-based for which is less easily rewritten as a while loop.=20
> >=20
> > No. I did not suggest that [...]=20
>
> I'm confused. I thought the suggestion was to make 'for(var : ...)' to=20
> *always* mean 'for(atuo&& var : ...)'. If not, then never mind :-).=20
>
> --=20
> Matthew=20
>
I think this transformation (specific to range-based for) is OK, since=20
relying on the existence of declarator is already error-prone so I will=20
never be confused by omission of 'auto&&'.

However, if you do want to have an lived-out-of-loop iterator, then it has=
=20
nothing to do with the range-based for statement because the iteration is=
=20
not based on specific range. I think the classic for statement with=20
for-scoped declaration is enough. The ancient one I mentioned is the oldest=
=20
and the only syntax which conforming to C89 (C89 does not accept other=20
forms of "for" statements). Besides to compatibility concerns, it is not=20
necessary now since the embedded declaration in the "for" statement can be=
=20
empty (a single semicolon) in the form introduced in C99/C++.



--=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/1632cc10-b646-4524-a3e5-9049b78d50d3%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B48=E6=9C=884=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8A=E5=8D=8812:16:56=EF=BC=8CMatthew Woehl=
ke=E5=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">O=
n 2016-07-30 05:56, FrankHB1989 wrote:
<br>&gt; =E5=9C=A8 2016=E5=B9=B47=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=85=AD UTC+8=E4=B8=8A=E5=8D=887:20:15=EF=BC=8CMatthew Woehlke=E5=86=99=E9=
=81=93=EF=BC=9A
<br>&gt;&gt; On 2016-07-28 07:04, FrankHB1989 wrote:=20
<br>&gt;&gt;&gt; I&#39;d even be glad if the ancient form of &#39;for&#39; =
statement is deprecated,=20
<br>&gt;&gt;&gt; just to reduce the amount of naive excuses.=20
<br>&gt;&gt;
<br>&gt;&gt; No. Declaring the iterator outside the loop also preserves its=
 value=20
<br>&gt;&gt; outside the loop. That is sometimes useful. Perhaps even more =
so with=20
<br>&gt;&gt; range-based for which is less easily rewritten as a while loop=
..=20
<br>&gt;
<br>&gt; No. I did not suggest that [...]
<br>
<br>I&#39;m confused. I thought the suggestion was to make &#39;for(var : .=
...)&#39; to
<br>*always* mean &#39;for(atuo&amp;&amp; var : ...)&#39;. If not, then nev=
er mind :-).
<br>
<br>--=20
<br>Matthew
<br></blockquote><div>I think this transformation (specific to range-based =
for) is OK, since relying on the existence of declarator is already error-p=
rone so I will never be confused by omission of &#39;auto&amp;&amp;&#39;.<b=
r><br>However, if you do want to have an lived-out-of-loop iterator, then i=
t has nothing to do with the range-based for statement because the iteratio=
n is not based on specific range. I think the classic for statement with fo=
r-scoped declaration is enough. The ancient one I mentioned is the oldest a=
nd the only syntax which conforming to C89 (C89 does not accept other forms=
 of &quot;for&quot; statements). Besides to compatibility concerns, it is n=
ot necessary now since the embedded declaration in the &quot;for&quot; stat=
ement can be empty (a single semicolon) in the form introduced in C99/C++.<=
br><br><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&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/1632cc10-b646-4524-a3e5-9049b78d50d3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1632cc10-b646-4524-a3e5-9049b78d50d3=
%40isocpp.org</a>.<br />

------=_Part_829_665424925.1470640546405--

------=_Part_828_1790364445.1470640546405--

.