------=_Part_1929_3330529.1400980459125
Content-Type: text/plain; charset=UTF-8

Hi Everyone

Is there any reason why the ( x : y ) loop syntax does not
the initialisation and step elements from regular loops?

e.g., we can do:

std::vector<std::string> v;
for (const auto& e : v )
 do_something(e);

but why not:

std::vector<std::string> v;
for (size_t i = 0; const auto& e : v; ++i )
 do_something(i, e);

I'm not sure why this was omitted in the original design? It seems
inconsistent and surprising for those already used to these elements in
regular for loops.

My motivations are:

* I often find myself still in need of an index counter for various reasons
as well as the element.
* I like to be able to use continue etc. and know that it will be
incremented.
* I like (usually) that my index variable is tied to my loop and also
vanishes when my loop goes out of scope.
* I find it surprising and odd that they aren't supported and out of step
(ho ho ho) with the original loop syntax.

I like the newer range loop, but it hasn't removed my need for these other
things. Does anyone else find this?

N3994 proposes yet another syntax (quite understandably) as does the other
range loop thread just started.

So now seems the right time to discuss this, perhaps in the context of
those also, and make sure the door isn't shut on this idea unless we mean
to.

The discussion might help me understand why these elements got cut from the
original loop construct in the first place or realise that I'm using them
wrong or something, if nothing else.

Without that understanding, as of right now, I propose we put these missing
constructs back!

Your thoughts please.

Thanks

--

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

<div dir=3D"ltr"><div>Hi Everyone</div><div><br></div><div>Is there any rea=
son why&nbsp;the ( x : y ) loop syntax&nbsp;does not the&nbsp;initialisatio=
n and step elements from regular loops?</div><div><br></div><div>e.g., we c=
an do:</div><div><br></div><div>std::vector&lt;std::string&gt; v;</div><div=
>for (const auto&amp; e : v )</div><div>&nbsp;do_something(e);</div><div><b=
r></div><div>but why not:</div><div><br><div>std::vector&lt;std::string&gt;=
 v;</div><div>for (size_t i =3D 0; const auto&amp; e : v; ++i&nbsp;)</div><=
div>&nbsp;do_something(i, e);</div><div><br></div><div><div>I'm not sure wh=
y this was omitted in the original design? It seems inconsistent and surpri=
sing for those already used to these elements in regular for loops.</div><d=
iv><br></div><div>My motivations are:<br></div></div></div><div><br></div><=
div>* I often find myself&nbsp;still in&nbsp;need of an index counter for v=
arious reasons as well as the element.</div><div>* I&nbsp;like to be able t=
o use continue etc. and know that it will be incremented.</div><div>* I&nbs=
p;like (usually) that my index variable is tied to my loop and also vanishe=
s when my loop goes out of scope.</div><div>* I find it&nbsp;surprising and=
 odd&nbsp;that they aren't supported and out of step (ho ho ho) with the or=
iginal loop syntax.</div><div><br></div><div>I like the newer range loop, b=
ut it hasn't removed my need&nbsp;for these other things. Does anyone else =
find this?</div><div>&nbsp;</div><div>N3994 proposes yet another syntax (qu=
ite understandably) as does the other range loop thread just started. </div=
><div><br></div><div>So now seems the right time&nbsp;to discuss this, perh=
aps in the context of those also,&nbsp;and make sure the door isn't shut on=
 this idea unless we mean to.</div><div><br></div><div>The discussion&nbsp;=
might help me understand&nbsp;why these elements&nbsp;got cut from the orig=
inal loop construct in the first place or realise that I'm using them wrong=
 or something, if nothing else.</div><div><br></div><div>Without that under=
standing,&nbsp;as of right now, I propose we put these missing constructs&n=
bsp;back!</div><div><br></div><div>Your thoughts please.</div><div><br></di=
v><div>Thanks</div><div><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_1929_3330529.1400980459125--

.

On 2014-05-24 21:14, gmisocpp@gmail.com wrote:
> * I often find myself still in need of an index counter for various reasons
> as well as the element.

  for (n, value : std::enumerate(container)) // :-)

....though this requires adding std::enumerate, tuple unpacking, and
extending tuple unpacking to be implied in case of range-based for with
type omitted.

> * I like to be able to use continue etc. and know that it will be
> incremented.
> * I like (usually) that my index variable is tied to my loop and also
> vanishes when my loop goes out of scope.

Both are not a problem if we had the above.

--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_2864_20215864.1401132338953
Content-Type: text/plain; charset=UTF-8



On Sunday, 25 May 2014 02:14:19 UTC+1, gmis...@gmail.com wrote:
>
> Hi Everyone
>
> Is there any reason why the ( x : y ) loop syntax does not
> the initialisation and step elements from regular loops?
>
> e.g., we can do:
>
> std::vector<std::string> v;
> for (const auto& e : v )
>  do_something(e);
>
> but why not:
>
> std::vector<std::string> v;
> for (size_t i = 0; const auto& e : v; ++i )
>  do_something(i, e);
>
> I feel that would just be confusing.  The range-based for is sufficiently
different to the traditional for that mixing of the syntax is surely a
no-no.

I'm not sure why this was omitted in the original design? It seems
> inconsistent and surprising for those already used to these elements in
> regular for loops.
>

I can easily imagine why, though.


> Your thoughts please.
>
> Thanks
>
> No problem :)

--

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

<div dir=3D"ltr"><br><br>On Sunday, 25 May 2014 02:14:19 UTC+1, gmis...@gma=
il.com  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div>Hi Everyone</div><div><br></div><div>Is there any reason why&nbsp;the=
 ( x : y ) loop syntax&nbsp;does not the&nbsp;initialisation and step eleme=
nts from regular loops?</div><div><br></div><div>e.g., we can do:</div><div=
><br></div><div>std::vector&lt;std::string&gt; v;</div><div>for (const auto=
&amp; e : v )</div><div>&nbsp;do_something(e);</div><div><br></div><div>but=
 why not:</div><div><br><div>std::vector&lt;std::string&gt; v;</div><div>fo=
r (size_t i =3D 0; const auto&amp; e : v; ++i&nbsp;)</div><div>&nbsp;do_som=
ething(i, e);</div><div><br></div></div></div></blockquote><div>I feel that=
 would just be confusing. &nbsp;The range-based for is sufficiently differe=
nt to the traditional for that mixing of the syntax is surely a no-no.&nbsp=
;</div><div><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></div><div><div>I'm not sure why this was omitted in the=
 original design? It seems inconsistent and surprising for those already us=
ed to these elements in regular for loops.</div></div></div></div></blockqu=
ote><div><br></div><div>I can easily imagine why, though.&nbsp;</div><div>&=
nbsp;</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"><d=
iv><div><div>Your thoughts please.<br></div></div></div><div><br></div><div=
>Thanks</div><div><br></div></div></blockquote><div>No problem :)&nbsp;</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 />

------=_Part_2864_20215864.1401132338953--

.

------=_Part_3605_19696729.1401145097309
Content-Type: text/plain; charset=UTF-8

HI Matthew

On Tuesday, May 27, 2014 6:00:05 AM UTC+12, Matthew Woehlke wrote:
>
> On 2014-05-24 21:14, gmis...@gmail.com <javascript:> wrote:
> > * I often find myself still in need of an index counter for various
> reasons
> > as well as the element.
>
>   for (n, value : std::enumerate(container)) // :-)
>
> ...though this requires adding std::enumerate, tuple unpacking, and
> extending tuple unpacking to be implied in case of range-based for with
> type omitted.
>

Why would we want to jump through hoops to make something different when we
already have a loop construct in the for( x = 9; x < 10; ++x)  that does
what I want and everybody is familiar with?

>
> > * I like to be able to use continue etc. and know that it will be
> > incremented.
> > * I like (usually) that my index variable is tied to my loop and also
> > vanishes when my loop goes out of scope.
>
> Both are not a problem if we had the above.
>
> --
> 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">HI Matthew<br><br>On Tuesday, May 27, 2014 6:00:05 AM UTC+=
12, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 20=
4); border-left-width: 1px; border-left-style: solid;">On 2014-05-24 21:14,=
 <a onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.=
href=3D'javascript:';return true;" href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"P2oFU0EnIIEJ">gmis...@gmail.com</a> wrote:
<br>&gt; * I often find myself still in need of an index counter for variou=
s reasons=20
<br>&gt; as well as the element.
<br>
<br>&nbsp; for (n, value : std::enumerate(container)) // :-)
<br>
<br>...though this requires adding std::enumerate, tuple unpacking, and
<br>extending tuple unpacking to be implied in case of range-based for with
<br>type omitted.
<br></blockquote><div><br></div><div>Why&nbsp;would we want to jump through=
 hoops to make something different when we already have&nbsp;a loop constru=
ct&nbsp;in the for(&nbsp;x =3D 9; x &lt;&nbsp;10; ++x)&nbsp; that does what=
 I want and everybody is familiar with?</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-colo=
r: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">
<br>&gt; * I like to be able to use continue etc. and know that it will be=
=20
<br>&gt; incremented.
<br>&gt; * I like (usually) that my index variable is tied to my loop and a=
lso=20
<br>&gt; vanishes when my loop goes out of scope.
<br>
<br>Both are not a problem if we had the above.
<br>
<br>--=20
<br>Matthew
<br></blockquote><div>&nbsp;</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_3605_19696729.1401145097309--

.

------=_Part_40_20423368.1401145287294
Content-Type: text/plain; charset=UTF-8

Hi Douglas

On Tuesday, May 27, 2014 7:25:39 AM UTC+12, Douglas Boffey wrote:
>
>
>
> On Sunday, 25 May 2014 02:14:19 UTC+1, gmis...@gmail.com wrote:
>>
>> Hi Everyone
>>
>> Is there any reason why the ( x : y ) loop syntax does not
>> the initialisation and step elements from regular loops?
>>
>> e.g., we can do:
>>
>> std::vector<std::string> v;
>> for (const auto& e : v )
>>  do_something(e);
>>
>> but why not:
>>
>> std::vector<std::string> v;
>> for (size_t i = 0; const auto& e : v; ++i )
>>  do_something(i, e);
>>
>> I feel that would just be confusing.  The range-based for is sufficiently
> different to the traditional for that mixing of the syntax is surely a
> no-no.
>
Why?

>
> I'm not sure why this was omitted in the original design? It seems
>> inconsistent and surprising for those already used to these elements in
>> regular for loops.
>>
>
> I can easily imagine why, though.
>
Do elaborate. I'm none the wiser otherwise.

>
>
>> Your thoughts please.
>>
>> Thanks
>>
>> No problem :)
>
Thanks

--

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

<div dir=3D"ltr">Hi Douglas<br><br>On Tuesday, May 27, 2014 7:25:39 AM UTC+=
12, Douglas Boffey wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br>=
<br>On Sunday, 25 May 2014 02:14:19 UTC+1, <a>gmis...@gmail.com</a>  wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;"><div dir=3D"ltr"><div>Hi Everyone</div><div><b=
r></div><div>Is there any reason why&nbsp;the ( x : y ) loop syntax&nbsp;do=
es not the&nbsp;initialisation and step elements from regular loops?</div><=
div><br></div><div>e.g., we can do:</div><div><br></div><div>std::vector&lt=
;std::string&gt; v;</div><div>for (const auto&amp; e : v )</div><div>&nbsp;=
do_something(e);</div><div><br></div><div>but why not:</div><div><br><div>s=
td::vector&lt;std::string&gt; v;</div><div>for (size_t i =3D 0; const auto&=
amp; e : v; ++i&nbsp;)</div><div>&nbsp;do_something(i, e);</div><div><br></=
div></div></div></blockquote><div>I feel that would just be confusing. &nbs=
p;The range-based for is sufficiently different to the traditional for that=
 mixing of the syntax is surely a no-no.&nbsp;</div></div></blockquote><div=
>Why?&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pa=
dding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: =
1px; border-left-style: solid;"><div dir=3D"ltr"><div><div></div><div><div>=
I'm not sure why this was omitted in the original design? It seems inconsis=
tent and surprising for those already used to these elements in regular for=
 loops.</div></div></div></div></blockquote><div><br></div><div>I can easil=
y imagine why, though.&nbsp;</div></div></blockquote><div>Do elaborate. I'm=
 none the wiser otherwise.&nbsp;</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(=
204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr"><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 20=
4); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><di=
v><div><div>Your thoughts please.<br></div></div></div><div><br></div><div>=
Thanks</div><div><br></div></div></blockquote><div>No problem :)&nbsp;</div=
></div></blockquote><div>Thanks&nbsp;</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_40_20423368.1401145287294--

.

------=_Part_275_23505386.1401159701349
Content-Type: text/plain; charset=UTF-8

The range for loop is syntactic shorthand in order to produce a for loop
which serves the task of the most common thing that a for loop is used for.
That is, iterating over a range. Your suggestion seems to imply that the
paranthesized portion of the range for loop (the (x:y) in for(x:y)) stands
in for the conditional part of a normal for loop (the part between the two
semicolons). But in fact, it stands in for all three portions. The init
statement, the condition, and the iteration expression. So, although I
can't speak for the authors of the proposal, I would say those parts were
omitted, because the purpose they serve was already covered. The range-for
loop is for iterating over a range. If you need something with more
abilities than that, the normal for loop still exists.

As an alternative, you could write a class which wraps a reference to a
container, and has iterators with value types which contain both a counter
and the value from the container. Used something like this:

for (auto const& e : with_counter(my_container))
    do_something(e.counter, e.value)

On Saturday, May 24, 2014 8:14:19 PM UTC-5, gmis...@gmail.com wrote:
>
> Hi Everyone
>
> Is there any reason why the ( x : y ) loop syntax does not
> the initialisation and step elements from regular loops?
>
> e.g., we can do:
>
> std::vector<std::string> v;
> for (const auto& e : v )
>  do_something(e);
>
> but why not:
>
> std::vector<std::string> v;
> for (size_t i = 0; const auto& e : v; ++i )
>  do_something(i, e);
>
> I'm not sure why this was omitted in the original design? It seems
> inconsistent and surprising for those already used to these elements in
> regular for loops.
>
> My motivations are:
>
> * I often find myself still in need of an index counter for various
> reasons as well as the element.
> * I like to be able to use continue etc. and know that it will be
> incremented.
> * I like (usually) that my index variable is tied to my loop and also
> vanishes when my loop goes out of scope.
> * I find it surprising and odd that they aren't supported and out of step
> (ho ho ho) with the original loop syntax.
>
> I like the newer range loop, but it hasn't removed my need for these other
> things. Does anyone else find this?
>
> N3994 proposes yet another syntax (quite understandably) as does the other
> range loop thread just started.
>
> So now seems the right time to discuss this, perhaps in the context of
> those also, and make sure the door isn't shut on this idea unless we mean
> to.
>
> The discussion might help me understand why these elements got cut from
> the original loop construct in the first place or realise that I'm using
> them wrong or something, if nothing else.
>
> Without that understanding, as of right now, I propose we put these
> missing constructs back!
>
> Your thoughts please.
>
> Thanks
>
>

--

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

<div dir=3D"ltr">The range for loop is syntactic shorthand in order to prod=
uce a for loop which serves the task of the most common thing that a for lo=
op is used for. That is, iterating over a range. Your suggestion seems to i=
mply that the paranthesized portion of the range for loop (the (x:y) in for=
(x:y)) stands in for the conditional part of a normal for loop (the part be=
tween the two semicolons). But in fact, it stands in for all three portions=
.. The init statement, the condition, and the iteration expression. So, alth=
ough I can't speak for the authors of the proposal, I would say those parts=
 were omitted, because the purpose they serve was already covered. The rang=
e-for loop is for iterating over a range. If you need something with more a=
bilities than that, the normal for loop still exists.<br><br>As an alternat=
ive, you could write a class which wraps a reference to a container, and ha=
s iterators with value types which contain both a counter and the value fro=
m the container. Used something like this:<br><br>for (auto const&amp; e : =
with_counter(my_container))<br>&nbsp;&nbsp;&nbsp; do_something(e.counter, e=
..value)<br><br>On Saturday, May 24, 2014 8:14:19 PM UTC-5, gmis...@gmail.co=
m wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>=
Hi Everyone</div><div><br></div><div>Is there any reason why&nbsp;the ( x :=
 y ) loop syntax&nbsp;does not the&nbsp;initialisation and step elements fr=
om regular loops?</div><div><br></div><div>e.g., we can do:</div><div><br><=
/div><div>std::vector&lt;std::string&gt; v;</div><div>for (const auto&amp; =
e : v )</div><div>&nbsp;do_something(e);</div><div><br></div><div>but why n=
ot:</div><div><br><div>std::vector&lt;std::string&gt; v;</div><div>for (siz=
e_t i =3D 0; const auto&amp; e : v; ++i&nbsp;)</div><div>&nbsp;do_something=
(i, e);</div><div><br></div><div><div>I'm not sure why this was omitted in =
the original design? It seems inconsistent and surprising for those already=
 used to these elements in regular for loops.</div><div><br></div><div>My m=
otivations are:<br></div></div></div><div><br></div><div>* I often find mys=
elf&nbsp;still in&nbsp;need of an index counter for various reasons as well=
 as the element.</div><div>* I&nbsp;like to be able to use continue etc. an=
d know that it will be incremented.</div><div>* I&nbsp;like (usually) that =
my index variable is tied to my loop and also vanishes when my loop goes ou=
t of scope.</div><div>* I find it&nbsp;surprising and odd&nbsp;that they ar=
en't supported and out of step (ho ho ho) with the original loop syntax.</d=
iv><div><br></div><div>I like the newer range loop, but it hasn't removed m=
y need&nbsp;for these other things. Does anyone else find this?</div><div>&=
nbsp;</div><div>N3994 proposes yet another syntax (quite understandably) as=
 does the other range loop thread just started. </div><div><br></div><div>S=
o now seems the right time&nbsp;to discuss this, perhaps in the context of =
those also,&nbsp;and make sure the door isn't shut on this idea unless we m=
ean to.</div><div><br></div><div>The discussion&nbsp;might help me understa=
nd&nbsp;why these elements&nbsp;got cut from the original loop construct in=
 the first place or realise that I'm using them wrong or something, if noth=
ing else.</div><div><br></div><div>Without that understanding,&nbsp;as of r=
ight now, I propose we put these missing constructs&nbsp;back!</div><div><b=
r></div><div>Your thoughts please.</div><div><br></div><div>Thanks</div><di=
v><br></div></div></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 />

------=_Part_275_23505386.1401159701349--

.

------=_Part_157_6533378.1401168856921
Content-Type: text/plain; charset=UTF-8

Hi Benjamin

On Tuesday, May 27, 2014 3:01:41 PM UTC+12, Benjamin Lindley wrote:
>
> The range for loop is syntactic shorthand in order to produce a for loop
> which serves the task of the most common thing that a for loop is used for.
> That is, iterating over a range. Your suggestion seems to imply that the
> paranthesized portion of the range for loop (the (x:y) in for(x:y)) stands
> in for the conditional part of a normal for loop (the part between the two
> semicolons). But in fact, it stands in for all three portions. The init
> statement, the condition, and the iteration expression. So, although I
> can't speak for the authors of the proposal, I would say those parts were
> omitted, because the purpose they serve was already covered. The range-for
> loop is for iterating over a range. If you need something with more
> abilities than that, the normal for loop still exists.
>

I agree with you on that. Never the less, it would seem to be that the ( x
:y ) could still be re-expanded to so that the users initialization and
step parts could be accepted and merged in with the compilers generated
elements for the initialization, test and step components. I don't see any
fact that would prevent and it would appear to have value to allow that for
the reasons I mentioned in my first post.

The question is, why not allow that? It seems possible, natural and useful.

>
> As an alternative, you could write a class which wraps a reference to a
> container, and has iterators with value types which contain both a counter
> and the value from the container. Used something like this:
>
> for (auto const& e : with_counter(my_container))
>     do_something(e.counter, e.value)
>

We could do something like that, but do we need to and is it better than
what I'm proposing?

--

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

<div dir=3D"ltr">Hi Benjamin<br><br>On Tuesday, May 27, 2014 3:01:41 PM UTC=
+12, Benjamin Lindley wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">T=
he range for loop is syntactic shorthand in order to produce a for loop whi=
ch serves the task of the most common thing that a for loop is used for. Th=
at is, iterating over a range. Your suggestion seems to imply that the para=
nthesized portion of the range for loop (the (x:y) in for(x:y)) stands in f=
or the conditional part of a normal for loop (the part between the two semi=
colons). But in fact, it stands in for all three portions. The init stateme=
nt, the condition, and the iteration expression. So, although I can't speak=
 for the authors of the proposal, I would say those parts were omitted, bec=
ause the purpose they serve was already covered. The range-for loop is for =
iterating over a range. If you need something with more abilities than that=
, the normal for loop still exists.<br></div></blockquote><div><br></div><d=
iv>I agree with you on that. Never the less, it would seem to be that the&n=
bsp;( x :y )&nbsp;could still be re-expanded to so that the users initializ=
ation and step parts could be accepted and merged in with the compilers gen=
erated elements for the initialization, test and step components. I don't s=
ee any fact that would prevent and it would appear to have value to allow t=
hat for the reasons I mentioned in my first post.</div><div><br></div><div>=
The question is, why not allow that? It seems possible, natural and useful.=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
 padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-widt=
h: 1px; border-left-style: solid;"><div dir=3D"ltr"><br>As an alternative, =
you could write a class which wraps a reference to a container, and has ite=
rators with value types which contain both a counter and the value from the=
 container. Used something like this:<br><br>for (auto const&amp; e : with_=
counter(my_container))<br>&nbsp;&nbsp;&nbsp; do_something(e.counter, e.valu=
e)<br></div></blockquote><div><br></div><div>We could do something like tha=
t, but do we need to and is it better than what I'm proposing?<br></div></d=
iv>

<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_157_6533378.1401168856921--

.

------=_Part_2182_31627438.1401171002141
Content-Type: text/plain; charset=UTF-8



On Tuesday, May 27, 2014 12:34:17 AM UTC-5, gmis...@gmail.com wrote:
>
> I agree with you on that. Never the less, it would seem to be that the ( x
> :y ) could still be re-expanded to so that the users initialization and
> step parts could be accepted and merged in with the compilers generated
> elements for the initialization, test and step components. I don't see any
> fact that would prevent and it would appear to have value to allow that for
> the reasons I mentioned in my first post.
>
> The question is, why not allow that? It seems possible, natural and useful.
>
>>
>> As an alternative, you could write a class which wraps a reference to a
>> container, and has iterators with value types which contain both a counter
>> and the value from the container. Used something like this:
>>
>> for (auto const& e : with_counter(my_container))
>>     do_something(e.counter, e.value)
>>
>
> We could do something like that, but do we need to and is it better than
> what I'm proposing?
>

Yes, in my opinion, it is better than what you are proposing. Much better.
Because it doesn't require a change to the core language. It addresses your
first three bullet points

* I often find myself still in need of an index counter for various reasons
as well as the element.
* I like to be able to use continue etc. and know that it will be
incremented.
* I like (usually) that my index variable is tied to my loop and also
vanishes when my loop goes out of scope.

And as for your fourth bullet point,

* I find it surprising and odd that they aren't supported and out of step
(ho ho ho) with the original loop syntax.

I, for one, do not find it surprising at all. In fact, I would find your
suggested syntax surprising, or at least a little odd. The basic for loop
has a conditional as the second expression. Your suggestion proposes that
it can alternatively have something that is not a conditional expression,
but something else entirely. I think that the explanation for the two
different types of for loops, as they currently are, is less confusing that
having one type of for loop, where the middle expression takes one of two
different forms. Mind you, I'm not saying that your suggested syntax is
mind-bogglingly difficult to understand, just that it is at least as
difficult to understand as what we have now.

So, to re-iterate, since my suggestion does not require a language change,
and it address the 3 problems that I agree with out of the 4 you listed,
yes, it is better.

--

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

<div dir=3D"ltr"><br><br>On Tuesday, May 27, 2014 12:34:17 AM UTC-5, gmis..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div></div><div>I agree with you on that. Never the less, it would see=
m to be that the&nbsp;( x :y )&nbsp;could still be re-expanded to so that t=
he users initialization and step parts could be accepted and merged in with=
 the compilers generated elements for the initialization, test and step com=
ponents. I don't see any fact that would prevent and it would appear to hav=
e value to allow that for the reasons I mentioned in my first post.</div><d=
iv><br></div><div>The question is, why not allow that? It seems possible, n=
atural and useful.</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border=
-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><br>As an alterna=
tive, you could write a class which wraps a reference to a container, and h=
as iterators with value types which contain both a counter and the value fr=
om the container. Used something like this:<br><br>for (auto const&amp; e :=
 with_counter(my_container))<br>&nbsp;&nbsp;&nbsp; do_something(e.counter, =
e.value)<br></div></blockquote><div><br></div><div>We could do something li=
ke that, but do we need to and is it better than what I'm proposing?<br></d=
iv></div></blockquote><div><br>Yes, in my opinion, it is better than what y=
ou are proposing. Much better. Because it doesn't require a change to the c=
ore language. It addresses your first three bullet points<br>&nbsp;<br>* I =
often find myself&nbsp;still in&nbsp;need of an index counter for various r=
easons as well as the element.<div>* I&nbsp;like to be able to use continue=
 etc. and know that it will be incremented.</div><div>* I&nbsp;like (usuall=
y) that my index variable is tied to my loop and also vanishes when my loop=
 goes out of scope.<br><br>And as for your fourth bullet point,<br><br>* I =
find it&nbsp;surprising and odd&nbsp;that they aren't supported and out of =
step (ho ho ho) with the original loop syntax.<br><br>I, for one, do not fi=
nd it surprising at all. In fact, I would find your suggested syntax surpri=
sing, or at least a little odd. The basic for loop has a conditional as the=
 second expression. Your suggestion proposes that it can alternatively have=
 something that is not a conditional expression, but something else entirel=
y. I think that the explanation for the two different types of for loops, a=
s they currently are, is less confusing that having one type of for loop, w=
here the middle expression takes one of two different forms. Mind you, I'm =
not saying that your suggested syntax is mind-bogglingly difficult to under=
stand, just that it is at least as difficult to understand as what we have =
now.<br><br>So, to re-iterate, since my suggestion does not require a langu=
age change, and it address the 3 problems that I agree with out of the 4 yo=
u listed, yes, it is better.<br></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_2182_31627438.1401171002141--

.

------=_Part_10_28229822.1401188810464
Content-Type: text/plain; charset=UTF-8

I think Benjamin has summarised my position much better than I ever could.
Thank you Benjamin.

--

---
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_10_28229822.1401188810464
Content-Type: text/html; charset=UTF-8

<div dir="ltr">I think Benjamin has summarised my position much better than I ever could.&nbsp; Thank you Benjamin.</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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_10_28229822.1401188810464--

.

------=_Part_4089_22027882.1401194745353
Content-Type: text/plain; charset=UTF-8

Hi Benjamin

On Tuesday, May 27, 2014 6:10:02 PM UTC+12, Benjamin Lindley wrote:
>
>
>
> On Tuesday, May 27, 2014 12:34:17 AM UTC-5, gmis...@gmail.com wrote:
>>
>> I agree with you on that. Never the less, it would seem to be that the (
>> x :y ) could still be re-expanded to so that the users initialization and
>> step parts could be accepted and merged in with the compilers generated
>> elements for the initialization, test and step components. I don't see any
>> fact that would prevent and it would appear to have value to allow that for
>> the reasons I mentioned in my first post.
>>
>> The question is, why not allow that? It seems possible, natural and
>> useful.
>>
>>>
>>> As an alternative, you could write a class which wraps a reference to a
>>> container, and has iterators with value types which contain both a counter
>>> and the value from the container. Used something like this:
>>>
>>> for (auto const& e : with_counter(my_container))
>>>     do_something(e.counter, e.value)
>>>
>>
>> We could do something like that, but do we need to and is it better than
>> what I'm proposing?
>>
>
> Yes, in my opinion, it is better than what you are proposing. Much better.
> Because it doesn't require a change to the core language. It addresses your
> first three bullet points
>

I don't find that an argument at all. The for (x ;y) syntax would not have
been created in the first place if that logic prevailed because that too
required a core language change since we already had a for syntax to begin
with. But nobody argued against it on that basis. So why here? Should we
not have added the extra terse lambda fix in c++14 because c++11 already
had the basic lambda. Most invention or fixing requires change. So what?
Your point here seems a non argument.

>
> * I often find myself still in need of an index counter for various
> reasons as well as the element.
> * I like to be able to use continue etc. and know that it will be
> incremented.
> * I like (usually) that my index variable is tied to my loop and also
> vanishes when my loop goes out of scope.
>
> And as for your fourth bullet point,
>
> * I find it surprising and odd that they aren't supported and out of step
> (ho ho ho) with the original loop syntax.
>
> I, for one, do not find it surprising at all. In fact, I would find your
> suggested syntax surprising, or at least a little odd. The basic for loop
> has a conditional as the second expression. Your suggestion proposes that
> it can alternatively have something that is not a conditional expression,
> but something else entirely. I think that the explanation for the two
> different types of for loops, as they currently are, is less confusing that
> having one type of for loop, where the middle expression takes one of two
> different forms. Mind you, I'm not saying that your suggested syntax is
> mind-bogglingly difficult to understand, just that it is at least as
> difficult to understand as what we have now.
>

I don't see it that way. for ( x : y ) just elides the init part, there
still is an init part, and a step part. it's not like those parts don't
exist. I'm just suggesting that init and step parts be re-exposed as the
regular for provides, so that it can be augmented with the users init and
step components, if it helps to see it that way.

for (int xi = 0; x : y; ++xi)  doesn't have too many plausible meanings. I
fail to see why anyone should be so surprised as to what this statement
might do.

> So, to re-iterate, since my suggestion does not require a language
change, and it address the 3 problems that I agree with out of the 4 you
listed, yes, it is better.

You're entitled to your opinion but given your workarounds don't appear to
be shorter in syntax and they deviate from the "obvious" and common
solutions; ones that one already uses for regular for loops. t don't
see anything in your arguments that show why what you've said is better
than what I've proposed.

Does anyone else have objections that might help me see the folly in my
suggestion? If you like the idea, do say that too, of course.

Thanks

--

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

<div dir=3D"ltr">Hi Benjamin<br><br>On Tuesday, May 27, 2014 6:10:02 PM UTC=
+12, Benjamin Lindley wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><=
br><br>On Tuesday, May 27, 2014 12:34:17 AM UTC-5, <a>gmis...@gmail.com</a>=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex=
; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-wid=
th: 1px; border-left-style: solid;"><div dir=3D"ltr"><div></div><div>I agre=
e with you on that. Never the less, it would seem to be that the&nbsp;( x :=
y )&nbsp;could still be re-expanded to so that the users initialization and=
 step parts could be accepted and merged in with the compilers generated el=
ements for the initialization, test and step components. I don't see any fa=
ct that would prevent and it would appear to have value to allow that for t=
he reasons I mentioned in my first post.</div><div><br></div><div>The quest=
ion is, why not allow that? It seems possible, natural and useful.</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-=
left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; b=
order-left-style: solid;"><div dir=3D"ltr"><br>As an alternative, you could=
 write a class which wraps a reference to a container, and has iterators wi=
th value types which contain both a counter and the value from the containe=
r. Used something like this:<br><br>for (auto const&amp; e : with_counter(m=
y_container))<br>&nbsp;&nbsp;&nbsp; do_something(e.counter, e.value)<br></d=
iv></blockquote><div><br></div><div>We could do something like that, but do=
 we need to and is it better than what I'm proposing?<br></div></div></bloc=
kquote><div><br>Yes, in my opinion, it is better than what you are proposin=
g. Much better. Because it doesn't require a change to the core language. I=
t addresses your first three bullet points<br></div></div></blockquote><div=
><br></div><div>I don't&nbsp;find that&nbsp;an argument&nbsp;at all.&nbsp;T=
he for (x ;y) syntax would not have been created in the first place if that=
 logic prevailed&nbsp;because&nbsp;that too required a core language change=
&nbsp;since&nbsp;we already had a&nbsp;for&nbsp;syntax&nbsp;to begin with. =
But nobody&nbsp;argued&nbsp;against it on that basis. So why here?&nbsp;Sho=
uld we not&nbsp;have added the extra terse lambda fix in c++14 because c++1=
1 already had the basic lambda. Most invention or fixing&nbsp;requires chan=
ge. So what? Your point here&nbsp;seems a non argument.</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; =
border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-=
style: solid;"><div dir=3D"ltr"><div>&nbsp;<br>* I often find myself&nbsp;s=
till in&nbsp;need of an index counter for various reasons as well as the el=
ement.<div>* I&nbsp;like to be able to use continue etc. and know that it w=
ill be incremented.</div><div>* I&nbsp;like (usually) that my index variabl=
e is tied to my loop and also vanishes when my loop goes out of scope.<br><=
br>And as for your fourth bullet point,<br><br>* I find it&nbsp;surprising =
and odd&nbsp;that they aren't supported and out of step (ho ho ho) with the=
 original loop syntax.<br><br>I, for one, do not find it surprising at all.=
 In fact, I would find your suggested syntax surprising, or at least a litt=
le odd. The basic for loop has a conditional as the second expression. Your=
 suggestion proposes that it can alternatively have something that is not a=
 conditional expression, but something else entirely. I think that the expl=
anation for the two different types of for loops, as they currently are, is=
 less confusing that having one type of for loop, where the middle expressi=
on takes one of two different forms. Mind you, I'm not saying that your sug=
gested syntax is mind-bogglingly difficult to understand, just that it is a=
t least as difficult to understand as what we have now.</div></div></div></=
blockquote><div><br></div><div>I don't see it that way. for (&nbsp;x : y ) =
just elides the init part, there still is an init part, and a step part. it=
's not like those parts don't exist. I'm just suggesting that init and step=
 parts be re-exposed as the regular for provides, so that it can be augment=
ed with the users init and step components, if&nbsp;it helps&nbsp;to see it=
 that way.</div><div><br></div><div>for (int&nbsp;xi =3D&nbsp;0; x : y; ++x=
i)&nbsp; doesn't&nbsp;have too many&nbsp;plausible meanings. I fail to see =
why&nbsp;anyone&nbsp;should be so&nbsp;surprised as to what this statement =
might do.</div><div><br>&gt; So, to re-iterate, since my suggestion does no=
t require a language change, and it address the 3 problems that I agree wit=
h out of the 4 you listed, yes, it is better.<br></div><div><br></div><div>=
You're entitled to your opinion but given your&nbsp;workarounds don't appea=
r to be shorter&nbsp;in syntax and&nbsp;they deviate from&nbsp;the&nbsp;"ob=
vious" and&nbsp;common solutions; ones that&nbsp;one&nbsp;already uses for =
regular for loops.&nbsp;t don't see&nbsp;anything&nbsp;in your arguments th=
at show&nbsp;why what you've said is better than what I've proposed.</div><=
div><br></div><div>Does anyone else have objections that might help me see =
the folly in my suggestion?&nbsp;If you like the idea, do say that too, of =
course.</div><div><br></div><div>Thanks</div><div><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_4089_22027882.1401194745353--

.

On 2014-05-26 18:58, gmisocpp@gmail.com wrote:
> On Tuesday, May 27, 2014 6:00:05 AM UTC+12, Matthew Woehlke wrote:
>> On 2014-05-24 21:14, gmis...@gmail.com <javascript:> wrote:
>>> * I often find myself still in need of an index counter for various
>>> reasons as well as the element.
>>
>>   for (n, value : std::enumerate(container)) // :-)
>>
>> ...though this requires adding std::enumerate, tuple unpacking, and
>> extending tuple unpacking to be implied in case of range-based for with
>> type omitted.
>
> Why would we want to jump through hoops to make something different when we
> already have a loop construct in the for( x = 9; x < 10; ++x)  that does
> what I want and everybody is familiar with?

So use that. (Of course you'll need a separate call to get the value
from the index.)

Your original suggestion was to mix range-based for with 'classic' for,
which seems... very odd to me. Your proposed loop condition isn't
actually a condition. As such, I have to agree with others that I don't
like that syntax.

If you need both the iterator and value, I think my proposal, or else
use a 'classic' for with separate call to get the value, makes more sense.

Besides, it would already be nice to be able to write:

  for (key, value : map_container)

(And there are other uses for tuple unpacking as well.)

--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-05-26 23:01, Benjamin Lindley wrote:
> As an alternative, you could write a class which wraps a reference to a
> container, and has iterators with value types which contain both a counter
> and the value from the container.

....which ideally would be called std::enumerate :-).

--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_4191_15089338.1401229570197
Content-Type: text/plain; charset=UTF-8


On Wednesday, May 28, 2014 3:26:36 AM UTC+12, Matthew Woehlke wrote:
>
> On 2014-05-26 18:58, gmis...@gmail.com <javascript:> wrote:
> > On Tuesday, May 27, 2014 6:00:05 AM UTC+12, Matthew Woehlke wrote:
> >> On 2014-05-24 21:14, gmis...@gmail.com <javascript:> wrote:
> >>> * I often find myself still in need of an index counter for various
> >>> reasons as well as the element.
> >>
> >>   for (n, value : std::enumerate(container)) // :-)
> >>
> >> ...though this requires adding std::enumerate, tuple unpacking, and
> >> extending tuple unpacking to be implied in case of range-based for with
> >> type omitted.
> >
> > Why would we want to jump through hoops to make something different when
> we
> > already have a loop construct in the for( x = 9; x < 10; ++x)  that does
> > what I want and everybody is familiar with?
>
> So use that. (Of course you'll need a separate call to get the value
> from the index.)
>

Why is that necessary when extending the for (e : c), would appear to
give me the best of both without loss of anything?

>
> Your original suggestion was to mix range-based for with 'classic' for,
> which seems... very odd to me. Your proposed loop condition isn't
> actually a condition. As such, I have to agree with others that I don't
> like that syntax.
>
> If you need both the iterator and value, I think my proposal, or else
> use a 'classic' for with separate call to get the value, makes more sense.
>
> Besides, it would already be nice to be able to write:
>
>   for (key, value : map_container)
>

I agree that would be nice. But why does my proposal prevent that? .e..g.:

for (int I = 0; key, value : map_container; ++I)

Your statement seems to suggest my proposal would prevent this. Why could
the above not compose the same?


The for (c:e) syntax has an init, test, and step elements like any other
loop, does it not, and the compiler knows where they go?

Why can't it take the init, test, and set steps from the users code and
insert that in the right places with the compilers init test and step
statements for the (e:c) syntax to achieve the result above?

I'm more likely to accept arguments that attack that core concept. The
arguments so far seem to amount to subjective syntax objections.

I've not seen anything more concrete. Sorry if I have missed such an
example.

My view is that the original loop caters for the fact that multiple things
can get initialized with the loop, step with the loop, and die with the
loop and the continue keyword places along in that cycle. These are useful
virtues which is why they were introduced to begin with.

The for (e:c) syntax is a nice feature too but it removed the properties
the original loop had. My proposal attempts to put them back; adding the
same virtues and expectations that the original loop gave to the newer
loop: it allows users to use the newer loop to gain it's virtues and
keep the virtues of the original loop construct too.

Counter arguments in this thread so far haven't shown to provide these
virtues.

They suggest that if I desire a feature from the for (e:c) syntax but need
a counter, I have to abandon the new loop and go back to the old one and
lose it's virtues but they offer no clear reason why beyond syntax. That
doesn't makes sense to me, if I can have both. Which so far, it still seems
I can.

I think arguments against my proposal need to attack all these core
concepts to be more convincing to me. I'm sure somebody will get there, but
as yet, I haven't seen that yet.

Thanks

--

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

<div dir=3D"ltr"><br>On Wednesday, May 28, 2014 3:26:36 AM UTC+12, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0p=
x 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-l=
eft-width: 1px; border-left-style: solid;">On 2014-05-26 18:58, <a onmoused=
own=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'java=
script:';return true;" href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"T-KI3PA6aAAJ">gmis...@gmail.com</a> wrote:
<br>&gt; On Tuesday, May 27, 2014 6:00:05 AM UTC+12, Matthew Woehlke wrote:
<br>&gt;&gt; On 2014-05-24 21:14, <a>gmis...@gmail.com</a> &lt;javascript:&=
gt; wrote:=20
<br>&gt;&gt;&gt; * I often find myself still in need of an index counter fo=
r various=20
<br>&gt;&gt;&gt; reasons as well as the element.=20
<br>&gt;&gt;
<br>&gt;&gt; &nbsp; for (n, value : std::enumerate(container)) // :-)=20
<br>&gt;&gt;
<br>&gt;&gt; ...though this requires adding std::enumerate, tuple unpacking=
, and=20
<br>&gt;&gt; extending tuple unpacking to be implied in case of range-based=
 for with=20
<br>&gt;&gt; type omitted.=20
<br>&gt;=20
<br>&gt; Why would we want to jump through hoops to make something differen=
t when we=20
<br>&gt; already have a loop construct in the for( x =3D 9; x &lt; 10; ++x)=
 &nbsp;that does=20
<br>&gt; what I want and everybody is familiar with?
<br>
<br>So use that. (Of course you'll need a separate call to get the value
<br>from the index.)
<br></blockquote><div>&nbsp;</div><div>Why&nbsp;is that necessary when&nbsp=
;extending the for (e : c), would appear to give&nbsp;me the&nbsp;best of b=
oth without loss of anything?</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;">
<br>Your original suggestion was to mix range-based for with 'classic' for,
<br>which seems... very odd to me. Your proposed loop condition isn't
<br>actually a condition. As such, I have to agree with others that I don't
<br>like that syntax.
<br>
<br>If you need both the iterator and value, I think my proposal, or else
<br>use a 'classic' for with separate call to get the value, makes more sen=
se.
<br>
<br>Besides, it would already be nice to be able to write:
<br>
<br>&nbsp; for (key, value : map_container)
<br></blockquote><div><br></div><div>I agree that would be nice. But&nbsp;w=
hy does my proposal prevent that? .e..g.:</div><div><br></div><div>for (int=
 I =3D 0; key, value : map_container; ++I)&nbsp;</div><div><br></div><div>Y=
our statement seems to suggest&nbsp;my proposal&nbsp;would prevent this.&nb=
sp;Why could the above not compose the same?</div><div><br></div><div><br><=
/div><div>The for (c:e) syntax has an init, test,&nbsp;and step elements li=
ke any other loop, does it not,&nbsp;and the compiler knows where they go?<=
/div><div><br></div><div>Why&nbsp;can't it&nbsp;take the init, test, and se=
t steps from the users code and insert that in the right places with the co=
mpilers init test and step statements for the (e:c) syntax to achieve the r=
esult above?</div><div><br></div><div>I'm more likely to accept&nbsp;argume=
nts&nbsp;that attack that core concept.&nbsp;The arguments&nbsp;so far seem=
&nbsp;to amount to subjective syntax objections.</div><div><br></div><div>I=
've not seen&nbsp;anything more concrete. Sorry if I have missed such an ex=
ample.</div><div><br></div><div>My view is that the original loop caters fo=
r the fact that multiple things can&nbsp;get initialized with the loop,&nbs=
p;step with the loop, and die with the loop and the continue keyword places=
 along in that cycle. These are useful virtues which is why they were intro=
duced to begin with.</div><div><br></div><div>The for (e:c) syntax is a nic=
e feature too but it removed the properties the original loop had. My propo=
sal attempts to put them back;&nbsp;adding the same virtues and expectation=
s that the original loop gave to the newer loop: it allows users&nbsp;to us=
e&nbsp;the newer loop to gain it's virtues&nbsp;and keep&nbsp;the virtues o=
f the original loop construct too.</div><div><br></div><div>Counter argumen=
ts in this thread so far haven't shown to provide these virtues.&nbsp;</div=
><div><br></div><div><div>They suggest that&nbsp;if I&nbsp;desire a feature=
 from the for (e:c) syntax but need a counter, I have to abandon the new lo=
op and go back to the old one and lose it's virtues but they offer no clear=
 reason why beyond syntax. That doesn't makes sense to me, if I can have bo=
th. Which so far, it still seems I can.</div><div><br></div><div><div>I thi=
nk arguments&nbsp;against my proposal need to attack all these core concept=
s&nbsp;to&nbsp;be more&nbsp;convincing to me. I'm sure somebody will get th=
ere, but as yet, I haven't seen that yet.</div></div></div><div><br></div><=
div>Thanks</div><div><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_4191_15089338.1401229570197--

.

On 2014-05-27 18:26, gmisocpp@gmail.com wrote:
> Why is that necessary when extending the for (e : c), would appear to
> give me the best of both without loss of anything?

Clarity. As others have also noted, I find the suggested syntax
combining 'classic' and range-based for to be strange and confusing.
Whereas 'for(n, value : std::enumerate(container))' is not introducing
strange syntax and is quite clear what is going on. (Just by itself, I
would argue that using std::enumerate to produce index/value pairs is
clearer than your suggestion which adds loosely-coupled code to do the
same task. Not to mention that with std::enumerate, it's impossible to
modify the index counter outside of the loop iteration.)

> On Wednesday, May 28, 2014 3:26:36 AM UTC+12, Matthew Woehlke wrote:
>> Besides, it would already be nice to be able to write:
>>
>>   for (key, value : map_container)
>
> I agree that would be nice. But why does my proposal prevent that?

No. I was responding more to your "jumping through hoops" comment. (IOW,
yes, tuple unpacking is more of a feature, but it's a *very useful* and
more general feature.)

(That said... mixing enumerate and map suggests a use case for nested
tuple unpacking... not going to go there in this thread...)

> I'm more likely to accept arguments that attack that core concept. The
> arguments so far seem to amount to subjective syntax objections.

Well, yes. IMHO however, rejecting a request (or at least seeking a
better solution for the underlying problem) because the suggested
resolution would inherently result in confusing code is reasonable.

(The argument for being able to do even-more-loosely related things in
the init/step is more interesting.)

> They suggest that if I desire a feature from the for (e:c) syntax but need
> a counter, I have to abandon the new loop and go back to the old one

No, we just need tuple unpacking and std::enumerate ;-). (Both of which
are already requested.)

--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_4566_10867636.1401235995921
Content-Type: text/plain; charset=UTF-8



On Wednesday, May 28, 2014 10:58:35 AM UTC+12, Matthew Woehlke wrote:
>
> On 2014-05-27 18:26, gmis...@gmail.com <javascript:> wrote:
> > Why is that necessary when extending the for (e : c), would appear to
> > give me the best of both without loss of anything?
>
> Clarity. As others have also noted, I find the suggested syntax
> combining 'classic' and range-based for to be strange and confusing.
> Whereas 'for(n, value : std::enumerate(container))' is not introducing
> strange syntax and is quite clear what is going on. (Just by itself, I
> would argue that using std::enumerate to produce index/value pairs is
> clearer than your suggestion which adds loosely-coupled code to do the
> same task. Not to mention that with std::enumerate, it's impossible to
> modify the index counter outside of the loop iteration.)
>

When for (e:c) was introduced, some attacked the new syntax as strange and
confusing. But it wasn't much of an argument. People just needed to get
used to it.
Of course it helped that Java already had trailed it a bit.
But I don't think it takes much to get used to my proposal's syntax any
more than it took time to get used to for (e:c) syntax.

I don't see anything being combined, that should be combined.
initialisation, and step are fundamental to both concepts and the test is
the same.

It appears to be purely a matter of verifying if that statement is true and
for people to see then see that fact.

>
> > On Wednesday, May 28, 2014 3:26:36 AM UTC+12, Matthew Woehlke wrote:
> >> Besides, it would already be nice to be able to write:
> >>
> >>   for (key, value : map_container)
> >
> > I agree that would be nice. But why does my proposal prevent that?
>
> No. I was responding more to your "jumping through hoops" comment. (IOW,
> yes, tuple unpacking is more of a feature, but it's a *very useful* and
> more general feature.)
>
> (That said... mixing enumerate and map suggests a use case for nested
> tuple unpacking... not going to go there in this thread...)
>

I'll understand these comments better when/if you make them on the another
thread then.

>
> > I'm more likely to accept arguments that attack that core concept. The
> > arguments so far seem to amount to subjective syntax objections.
>
> Well, yes. IMHO however, rejecting a request (or at least seeking a
> better solution for the underlying problem) because the suggested
> resolution would inherently result in confusing code is reasonable.
>
> (The argument for being able to do even-more-loosely related things in
> the init/step is more interesting.)
>
> > They suggest that if I desire a feature from the for (e:c) syntax but
> need
> > a counter, I have to abandon the new loop and go back to the old one
>
> No, we just need tuple unpacking and std::enumerate ;-). (Both of which
> are already requested.)
>

I think you mean yes here ;). An argument that makes the original for
(init;test;step) loop redundant, is something that might make my proposal
similarly redundant, but that's still being explored and I haven't
seen anything fully articulated that would do that yet. If it doesn't
happen, the value of my proposal still seems sound.

I assert that when a loop starts and ends, matching initialization and
destruction and scope voiding is useful. When a step is taken, being able
to take matching/corresponding steps is also useful. I don't see what new
concept for (e:c) loop introduces be it "rangey" or not that creates a
worry about "combining things" that shouldn't be combined or why having
integration points into this same cycle as the original for loops provides
is not just as useful in the new loop as the old loop.

The new loop just drops useful elements from the old loop for no clear
reason, forcing people who want features from both to pick one and provide
the rest themselves. I remain unclear why that's necessary if the best of
both worlds is possible?

It's not clear to me how the other proposals you suggest will restore *all*
these features this proposal aims to? On the contrary it seem this proposal
would augment other proposals in this area if anything too?

I've seen no argument beyond a vague syntax concerns that get to the core
of these issues. Nobody has shown that to me yet.

Thanks

--

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

<div dir=3D"ltr"><br><br>On Wednesday, May 28, 2014 10:58:35 AM UTC+12, Mat=
thew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;">On 2014-05-27 18:26, <a onm=
ousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D=
'javascript:';return true;" href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"1L3Q__6hmfEJ">gmis...@gmail.com</a> wrote:
<br>&gt; Why is that necessary when extending the for (e : c), would appear=
 to=20
<br>&gt; give me the best of both without loss of anything?
<br>
<br>Clarity. As others have also noted, I find the suggested syntax
<br>combining 'classic' and range-based for to be strange and confusing.
<br>Whereas 'for(n, value : std::enumerate(container))' is not introducing
<br>strange syntax and is quite clear what is going on. (Just by itself, I
<br>would argue that using std::enumerate to produce index/value pairs is
<br>clearer than your suggestion which adds loosely-coupled code to do the
<br>same task. Not to mention that with std::enumerate, it's impossible to
<br>modify the index counter outside of the loop iteration.)
<br></blockquote><div><br></div><div>When for (e:c) was introduced,&nbsp;so=
me&nbsp;attacked&nbsp;the new syntax as strange and confusing. But it wasn'=
t much of an argument. People just needed to get used to it.</div><div>Of c=
ourse it helped that Java already had&nbsp;trailed it a bit.</div><div>But =
I don't think it takes much to get used to my proposal's syntax&nbsp;any mo=
re than it took time to get used to&nbsp;for (e:c) syntax.</div><div><br></=
div><div>I don't see anything being combined, that should be combined. init=
ialisation, and step are fundamental to both concepts and the test is the s=
ame.</div><div><br></div><div>It appears to be&nbsp;purely a matter of veri=
fying if that statement is true and for people to see then see that fact.</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; p=
adding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width:=
 1px; border-left-style: solid;">
<br>&gt; On Wednesday, May 28, 2014 3:26:36 AM UTC+12, Matthew Woehlke wrot=
e:
<br>&gt;&gt; Besides, it would already be nice to be able to write:=20
<br>&gt;&gt;
<br>&gt;&gt; &nbsp; for (key, value : map_container)=20
<br>&gt;=20
<br>&gt; I agree that would be nice. But why does my proposal prevent that?
<br>
<br>No. I was responding more to your "jumping through hoops" comment. (IOW=
,
<br>yes, tuple unpacking is more of a feature, but it's a *very useful* and
<br>more general feature.)
<br>
<br>(That said... mixing enumerate and map suggests a use case for nested
<br>tuple unpacking... not going to go there in this thread...)
<br></blockquote><div><br></div><div>I'll understand these comments better =
when/if you make them on the another thread then.</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border=
-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style:=
 solid;">
<br>&gt; I'm more likely to accept arguments that attack that core concept.=
 The=20
<br>&gt; arguments so far seem to amount to subjective syntax objections.
<br>
<br>Well, yes. IMHO however, rejecting a request (or at least seeking a
<br>better solution for the underlying problem) because the suggested
<br>resolution would inherently result in confusing code is reasonable.
<br>
<br>(The argument for being able to do even-more-loosely related things in
<br>the init/step is more interesting.)
<br>
<br>&gt; They suggest that if I desire a feature from the for (e:c) syntax =
but need=20
<br>&gt; a counter, I have to abandon the new loop and go back to the old o=
ne
<br>
<br>No, we just need tuple unpacking and std::enumerate ;-). (Both of which
<br>are already requested.)
<br></blockquote><div><br></div><div>I think you mean yes here ;).&nbsp;An&=
nbsp;argument&nbsp;that makes the&nbsp;original for (init;test;step) loop r=
edundant,&nbsp;is something that might make my proposal similarly redundant=
, but that's still being explored and&nbsp;I haven't seen&nbsp;anything ful=
ly articulated that would do that yet. If it doesn't happen, the value of m=
y proposal still seems sound.</div><div><br></div><div>I assert that when a=
 loop starts and ends, matching initialization and destruction and scope vo=
iding is useful. When a step is taken,&nbsp;being able to&nbsp;take matchin=
g/corresponding steps&nbsp;is also useful.&nbsp;I don't see&nbsp;what new c=
oncept&nbsp;for (e:c) loop introduces be it&nbsp;"rangey" or not that creat=
es a worry about "combining things" that shouldn't be combined or why havin=
g integration points into this same cycle as the original for loops provide=
s is not just as useful in the new loop as the old loop.</div><div><br></di=
v><div>The new loop just drops useful elements from the old loop for no cle=
ar reason, forcing people who want features from both to pick one and provi=
de the rest themselves. I remain unclear why that's necessary if the best o=
f both worlds is possible?</div><div><br></div><div>It's not clear to me ho=
w&nbsp;the&nbsp;other proposals you suggest will&nbsp;restore *all* these&n=
bsp;features this proposal aims to? On the contrary it&nbsp;seem this propo=
sal would augment&nbsp;other proposals in this area if anything too?</div><=
div><br></div><div>I've seen no argument beyond a vague syntax concerns tha=
t get to the core of these issues. Nobody has shown that to me yet.</div><d=
iv><br></div><div>Thanks</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_4566_10867636.1401235995921--

.

On Sat, May 24, 2014 at 6:14 PM,  <gmisocpp@gmail.com> wrote:
> Hi Everyone
>
> Is there any reason why the ( x : y ) loop syntax does not the
> initialisation and step elements from regular loops?
>
> e.g., we can do:
>
> std::vector<std::string> v;
> for (const auto& e : v )
>  do_something(e);
>
> but why not:
>
> std::vector<std::string> v;
> for (size_t i = 0; const auto& e : v; ++i )
>  do_something(i, e);
>
> I'm not sure why this was omitted in the original design?

The "x : y" syntax is an abbreviation for something that uses all
three elements of the C for loop syntax. Allowing some of those
elements in addition to the abbreviation doesn't seem like a good
idea.

--

---
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_2648_3472357.1401246802030
Content-Type: text/plain; charset=UTF-8



On Tuesday, May 27, 2014 7:45:45 AM UTC-5, gmis...@gmail.com wrote:

I don't find that an argument at all. The for (x ;y) syntax would not have
> been created in the first place if that logic prevailed because that too
> required a core language change since we already had a for syntax to begin
> with.
>

The range-for loop provides a highly desirable convenience which could not
be provided without a change to the language, so I don't understand your
point here.


> But nobody argued against it on that basis. So why here?
>

People argue against core language changes all the time, especially when
the same functionality can be provided by a library feature. The range for
loop could not be provided without a core language change.


> Should we not have added the extra terse lambda fix in c++14 because c++11
> already had the basic lambda.
>

Again, same as above. It's a highly desired convenience that cannot be
provided by a library solution.

--

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

<div dir=3D"ltr"><br><br>On Tuesday, May 27, 2014 7:45:45 AM UTC-5, gmis...=
@gmail.com wrote:<br><br><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><div>I don't&nbsp;find that&nbsp;an argument&nbsp;at=
 all.&nbsp;The for (x ;y) syntax would not have been created in the first p=
lace if that logic prevailed&nbsp;because&nbsp;that too required a core lan=
guage change&nbsp;since&nbsp;we already had a&nbsp;for&nbsp;syntax&nbsp;to =
begin with.</div></div></blockquote><div><br>The range-for loop provides a =
highly desirable convenience which could not be provided without a change t=
o the language, so I don't understand your point here.<br>&nbsp;</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>But nobody&nb=
sp;argued&nbsp;against it on that basis. So why here?</div></div></blockquo=
te><div><br>People argue against core language changes all the time, especi=
ally when the same functionality can be provided by a library feature. The =
range for loop could not be provided without a core language change.<br>&nb=
sp;</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=
>Should we not&nbsp;have added the extra terse lambda fix in c++14 because =
c++11 already had the basic lambda.</div></div></blockquote><div><br>Again,=
 same as above. It's a highly desired convenience that cannot be provided b=
y a library solution.<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_2648_3472357.1401246802030--

.

------=_Part_331_9431564.1401255056726
Content-Type: text/plain; charset=UTF-8



On Wednesday, May 28, 2014 1:08:09 PM UTC+12, Jeffrey Yasskin wrote:
>
> On Sat, May 24, 2014 at 6:14 PM,  <gmis...@gmail.com <javascript:>>
> wrote:
> > Hi Everyone
> >
> > Is there any reason why the ( x : y ) loop syntax does not the
> > initialisation and step elements from regular loops?
> >
> > e.g., we can do:
> >
> > std::vector<std::string> v;
> > for (const auto& e : v )
> >  do_something(e);
> >
> > but why not:
> >
> > std::vector<std::string> v;
> > for (size_t i = 0; const auto& e : v; ++i )
> >  do_something(i, e);
> >
> > I'm not sure why this was omitted in the original design?
>
> The "x : y" syntax is an abbreviation for something that uses all
> three elements of the C for loop syntax. Allowing some of those
> elements in addition to the abbreviation doesn't seem like a good
> idea.
>

I know this.  But why isn't it a good idea is the question.

--

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

<div dir=3D"ltr"><br><br>On Wednesday, May 28, 2014 1:08:09 PM UTC+12, Jeff=
rey Yasskin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;">On Sat, May 24, 2014 at 6:14=
 PM, &nbsp;&lt;<a onmousedown=3D"this.href=3D'javascript:';return true;" on=
click=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"RAPLCpjLwvYJ">gmis...@gmail.com</a>&g=
t; wrote:
<br>&gt; Hi Everyone
<br>&gt;
<br>&gt; Is there any reason why the ( x : y ) loop syntax does not the
<br>&gt; initialisation and step elements from regular loops?
<br>&gt;
<br>&gt; e.g., we can do:
<br>&gt;
<br>&gt; std::vector&lt;std::string&gt; v;
<br>&gt; for (const auto&amp; e : v )
<br>&gt; &nbsp;do_something(e);
<br>&gt;
<br>&gt; but why not:
<br>&gt;
<br>&gt; std::vector&lt;std::string&gt; v;
<br>&gt; for (size_t i =3D 0; const auto&amp; e : v; ++i )
<br>&gt; &nbsp;do_something(i, e);
<br>&gt;
<br>&gt; I'm not sure why this was omitted in the original design?
<br>
<br>The "x : y" syntax is an abbreviation for something that uses all
<br>three elements of the C for loop syntax. Allowing some of those
<br>elements in addition to the abbreviation doesn't seem like a good
<br>idea.
<br></blockquote><div><br></div><div>I know this.&nbsp; But why isn't it a =
good idea is the question.</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_331_9431564.1401255056726--

.

------=_Part_1409_1805087.1401260088006
Content-Type: text/plain; charset=UTF-8



On Wednesday, May 28, 2014 3:13:22 PM UTC+12, Benjamin Lindley wrote:
>
>
>
> On Tuesday, May 27, 2014 7:45:45 AM UTC-5, gmis...@gmail.com wrote:
>
> I don't find that an argument at all. The for (x ;y) syntax would not have
>> been created in the first place if that logic prevailed because that too
>> required a core language change since we already had a for syntax to begin
>> with.
>>
>
> The range-for loop provides a highly desirable convenience which could not
> be provided without a change to the language, so I don't understand your
> point here.
>

It is desirable I agree. My point is change is required to get the features
you want. So just arguing against something because it requires a change
isn't an argument. Argue about the features.

But nobody argued against it on that basis. So why here?
>>
>
> People argue against core language changes all the time, especially when
> the same functionality can be provided by a library feature. The range for
> loop could not be provided without a core language change.
>

Sure. But similarly, I haven't seen a clear demonstration of a library
that offers the features I want, nor in a syntax that is superior to what
I've proposed.

I'm not saying it's not possible or that people are wrong. I'm just saying
they haven't demonstrated that clearly enough to undermine the case I've
made to my satisfaction. I'm sure and hopeful they will in time, but I
haven't seen that yet. So far the arguments against have been vague and not
feature driven.


>
>> Should we not have added the extra terse lambda fix in c++14 because
>> c++11 already had the basic lambda.
>>
>
> Again, same as above. It's a highly desired convenience that cannot be
> provided by a library solution.
>

Again, I see no library presented that clearly provides *all* of the
features I am talking about?

The original for loop construct has value, The newer loop construct also
has value. But the superset of the two has more value. That superset
is what my proposal offers. No-one has demonstrated a library that
does offers that whole superset?

If there is a library that can do all that, that is as succinct and
as clear and familiar as the syntax I have suggested (which is just
the original for loop pattern), then great, present it. But I've yet to see
it.

Most of the argument against this proposal has so far
been based on subjective objections about syntax or general concerns
about language change or just plain statements of "I don't like it."
but nothing that clearly attacks the guts of my proposal with any focus on
the specific features offered by the superset I mention.

The original for loop provides the iteration features it does for a
reason. I don't see why iterating over a range means I don't need those
integration points anymore. Nor do I see a library that clearly provides
all those features and integration points and as simply as the original for
loop.

I believe a convincing counter argument to my proposal has to begin with
determining what the feature set of the loop superset I've proposed is;
then presenting a library that caters to all of those features; and in a
way that is as clear and succinct and familiar as the syntax of what I've
presented.

I'll be happy if that's possible, but as yet, still nobody has presented
that.

--

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

<div dir=3D"ltr"><br><br>On Wednesday, May 28, 2014 3:13:22 PM UTC+12, Benj=
amin Lindley wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br><br>On=
 Tuesday, May 27, 2014 7:45:45 AM UTC-5, <a>gmis...@gmail.com</a> wrote:<br=
><br><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; =
padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width=
: 1px; border-left-style: solid;"><div dir=3D"ltr"><div></div><div>I don't&=
nbsp;find that&nbsp;an argument&nbsp;at all.&nbsp;The for (x ;y) syntax wou=
ld not have been created in the first place if that logic prevailed&nbsp;be=
cause&nbsp;that too required a core language change&nbsp;since&nbsp;we alre=
ady had a&nbsp;for&nbsp;syntax&nbsp;to begin with.</div></div></blockquote>=
<div><br>The range-for loop provides a highly desirable convenience which c=
ould not be provided without a change to the language, so I don't understan=
d your point here.<br></div></div></blockquote><div><br></div><div>It is de=
sirable I agree.&nbsp;My point is change is required to get the features yo=
u want. So just arguing against something because it requires a change isn'=
t an argument. Argue about the features.</div><div><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; =
border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-=
style: solid;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"=
margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 2=
04, 204); border-left-width: 1px; border-left-style: solid;"><div dir=3D"lt=
r"><div>But nobody&nbsp;argued&nbsp;against it on that basis. So why here?<=
/div></div></blockquote><div><br>People argue against core language changes=
 all the time, especially when the same functionality can be provided by a =
library feature. The range for loop could not be provided without a core la=
nguage change.<br></div></div></blockquote><div><br></div><div>Sure. But si=
milarly,&nbsp;I haven't seen a clear demonstration of a library that&nbsp;o=
ffers the&nbsp;features I want, nor&nbsp;in a syntax that is superior to wh=
at I've proposed.</div><div><br></div><div>I'm not saying it's not possible=
 or that people are wrong. I'm just saying they haven't demonstrated that&n=
bsp;clearly enough to undermine the case I've made to my satisfaction. I'm =
sure and hopeful they will in time, but I haven't seen that yet. So far the=
 arguments against have been vague and not feature driven.</div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; p=
adding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width:=
 1px; border-left-style: solid;"><div dir=3D"ltr"><div>&nbsp;</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left:=
 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border=
-left-style: solid;"><div dir=3D"ltr"><div>Should we not&nbsp;have added th=
e extra terse lambda fix in c++14 because c++11 already had the basic lambd=
a.</div></div></blockquote><div><br>Again, same as above. It's a highly des=
ired convenience that cannot be provided by a library solution.<br></div></=
div></blockquote><div><br></div><div>Again,&nbsp;I see no library presented=
 that clearly provides&nbsp;*all* of the features I am talking about?</div>=
<div><br></div><div><div>The original for loop&nbsp;construct has&nbsp;valu=
e, The newer loop construct also has value. But the superset of the&nbsp;tw=
o has more value. That superset is&nbsp;what my proposal offers. No-one has=
 demonstrated a library&nbsp;that does&nbsp;offers that whole&nbsp;superset=
?</div><div><br></div><div>If there is a library that can do all that, that=
 is as&nbsp;succinct&nbsp;and as&nbsp;clear and familiar as the syntax I ha=
ve suggested (which&nbsp;is just the&nbsp;original for&nbsp;loop&nbsp;patte=
rn),&nbsp;then great,&nbsp;present it. But I've yet to see it.</div><div><b=
r></div><div>Most of the argument against&nbsp;this proposal has so far bee=
n&nbsp;based&nbsp;on&nbsp;subjective objections&nbsp;about syntax or genera=
l concerns about&nbsp;language change or just plain statements of "I don't =
like it." but&nbsp;nothing that clearly attacks the guts of my&nbsp;proposa=
l with any focus on the specific features offered by the superset I mention=
..</div><div><br></div><div>The original for loop provides the iteration&nbs=
p;features it does for a reason.&nbsp;I don't see why iterating over a rang=
e means I don't need those integration points anymore.&nbsp;Nor&nbsp;do&nbs=
p;I see a library that clearly&nbsp;provides all those features and&nbsp;in=
tegration points&nbsp;and as simply as the original for loop.</div><div><br=
></div><div>I believe a convincing counter argument&nbsp;to my proposal&nbs=
p;has to begin with determining what the feature set of the loop superset I=
've proposed is; then presenting&nbsp;a library that&nbsp;caters to&nbsp;al=
l&nbsp;of those&nbsp;features; and&nbsp;in&nbsp;a way that is as clear&nbsp=
;and&nbsp;succinct and familiar as the syntax of what I've presented.</div>=
<div><br></div><div>I'll be happy if that's possible, but as yet, still nob=
ody has presented that.</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_1409_1805087.1401260088006--

.

------=_Part_4149_713327.1401267682407
Content-Type: text/plain; charset=UTF-8

Odd at first, but I like the idea.

--

---
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_4149_713327.1401267682407
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Odd at first, but I like the idea.<br></div>

<p></p>

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

------=_Part_4149_713327.1401267682407--

.

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

If we look at how the for-loops would be expanded (pre-optimisation):
=20
 for (Type var =3D init; final; iter) code;
=20
would become

=20
         Type var =3D init;          // initialisation                     =
 =20
                                                             =20
label1: if (!final) goto label 2; // continuation                          =
=20
                                                         =20
        code;                                                              =
=20
                     =20
        iter;                     // iteration                            =
=20
                                                       =20
        goto label1;                                                      =
=20
                             =20
label2: var::~var();

Here, I use a call to the destructor to indicate where the variable goes=20
out of scope.
Similarly,
=20
 for (Type var : cont) code;

would become
         Type var =3D begin(cont);            // initialisation            =
  =20
                                           =20
label3: if (var =3D=3D end(cont)) goto label4; // continuation             =
   =20
                                         =20
        code;                                                          =20
        ++var;                             // iteration                    =
=20
                                     =20
        goto label3;                                                      =
=20
   =20
label4: var::~var();

So, if
 =20
  for (Type1 var1 =3D init; Type2 var2 : cont; iter) code;

where allowed, logically it would have the following consequence:
=20
         Type1 var1 =3D init;                  // initialisation of var1   =
 =20
                    =20
label5: Type2 var2 =3D begin(cont);           // initialisation of var2    =
  =20
                  =20
label6: if (var2 =3D=3D end(cont)) goto label7; // continuation of var2    =
    =20
                =20
        ++var2;                             // iteration of var2          =
=20
              =20
        goto label6;                        // NB. the var2 loop is empty  =
=20
                      =20
label7: var2::~var2();                         =20
        if (false) goto label8;             // continuation of var1=E2=80=
=94no=20
condition in the continuation means =E2=80=98forever=E2=80=99              =
           =20
        code;                               // NB. var2 is out of scope    =
=20
                    =20
        iter;                               // iteration of var1          =
=20
              =20
        goto label5;                         =20
label8: var1::~var1();

I expect this is not what is wanted.

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

<div dir=3D"ltr"><DIV>If we look at how the for-loops would be expanded (pr=
e-optimisation):</DIV>
<DIV>&nbsp;</DIV>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid" class=3Dprettyprint><CODE class=3Dprettypri=
nt>
<DIV class=3Dsubprettyprint><SPAN style=3D"COLOR: #008" class=3Dstyled-by-p=
rettify>for</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> <=
/SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>(</SPAN><SPAN =
style=3D"COLOR: #606" class=3Dstyled-by-prettify>Type</SPAN><SPAN style=3D"=
COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #008"=
 class=3Dstyled-by-prettify>var</SPAN><SPAN style=3D"COLOR: #000" class=3Ds=
tyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-pre=
ttify>=3D</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> ini=
t</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>;</SPAN><SPA=
N style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"C=
OLOR: #008" class=3Dstyled-by-prettify>final</SPAN><SPAN style=3D"COLOR: #6=
60" class=3Dstyled-by-prettify>;</SPAN><SPAN style=3D"COLOR: #000" class=3D=
styled-by-prettify> iter</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-b=
y-prettify>)</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> =
code</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>;</SPAN><=
/DIV></CODE></DIV>
<DIV>&nbsp;</DIV>
<DIV>would become</DIV>
<P>&nbsp;</P>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid" class=3Dprettyprint><CODE class=3Dprettypri=
nt>
<DIV class=3Dsubprettyprint><SPAN style=3D"COLOR: #000" class=3Dstyled-by-p=
rettify>&nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"COLOR: #606" clas=
s=3Dstyled-by-prettify>Type</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyle=
d-by-prettify> </SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-prettif=
y>var</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN>=
<SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>=3D</SPAN><SPAN styl=
e=3D"COLOR: #000" class=3Dstyled-by-prettify> init</SPAN><SPAN style=3D"COL=
OR: #660" class=3Dstyled-by-prettify>;</SPAN><SPAN style=3D"COLOR: #000" cl=
ass=3Dstyled-by-prettify> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</SPAN><SPAN st=
yle=3D"COLOR: #800" class=3Dstyled-by-prettify>// initialisation &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</SPAN><SPAN styl=
e=3D"COLOR: #000" class=3Dstyled-by-prettify>&nbsp;<BR>label1</SPAN><SPAN s=
tyle=3D"COLOR: #660" class=3Dstyled-by-prettify>:</SPAN><SPAN style=3D"COLO=
R: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #008" cla=
ss=3Dstyled-by-prettify>if</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled=
-by-prettify> </SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify=
>(!</SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-prettify>final</SPA=
N><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>)</SPAN><SPAN styl=
e=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: =
#008" class=3Dstyled-by-prettify>goto</SPAN><SPAN style=3D"COLOR: #000" cla=
ss=3Dstyled-by-prettify> label </SPAN><SPAN style=3D"COLOR: #066" class=3Ds=
tyled-by-prettify>2</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-pre=
ttify>;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPA=
N><SPAN style=3D"COLOR: #800" class=3Dstyled-by-prettify>// continuation &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</SPAN><S=
PAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>&nbsp;<BR>&nbsp; &nbsp=
; &nbsp; &nbsp; code</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-pr=
ettify>;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;<BR>&=
nbsp; &nbsp; &nbsp; &nbsp; iter</SPAN><SPAN style=3D"COLOR: #660" class=3Ds=
tyled-by-prettify>;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-pre=
ttify> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; </SPAN><SPAN style=3D"COLOR: #800" class=3Dstyled-by-prettify>// iteratio=
n &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</SPA=
N><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>&nbsp;<BR>&nbsp; &=
nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-pr=
ettify>goto</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> l=
abel1</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>;</SPAN>=
<SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;<BR>label2</SPAN><SP=
AN style=3D"COLOR: #660" class=3Dstyled-by-prettify>:</SPAN><SPAN style=3D"=
COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #008"=
 class=3Dstyled-by-prettify>var</SPAN><SPAN style=3D"COLOR: #660" class=3Ds=
tyled-by-prettify>::~</SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-p=
rettify>var</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>()=
;</SPAN></DIV></CODE></DIV><BR>
<P>Here, I use a call to the destructor to indicate where the variable goes=
 out of scope.</P>
<DIV>Similarly,</DIV>
<DIV>&nbsp;</DIV>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid" class=3Dprettyprint><CODE class=3Dprettypri=
nt>
<DIV class=3Dsubprettyprint><SPAN style=3D"COLOR: #008" class=3Dstyled-by-p=
rettify>for</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> <=
/SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>(</SPAN><SPAN =
style=3D"COLOR: #606" class=3Dstyled-by-prettify>Type</SPAN><SPAN style=3D"=
COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #008"=
 class=3Dstyled-by-prettify>var</SPAN><SPAN style=3D"COLOR: #000" class=3Ds=
tyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-pre=
ttify>:</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> cont<=
/SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>)</SPAN><SPAN =
style=3D"COLOR: #000" class=3Dstyled-by-prettify> code</SPAN><SPAN style=3D=
"COLOR: #660" class=3Dstyled-by-prettify>;</SPAN></DIV></CODE></DIV><BR>
<P>would become</P>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid" class=3Dprettyprint><CODE class=3Dprettypri=
nt>
<DIV class=3Dsubprettyprint><SPAN style=3D"COLOR: #000" class=3Dstyled-by-p=
rettify>&nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"COLOR: #606" clas=
s=3Dstyled-by-prettify>Type</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyle=
d-by-prettify> </SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-prettif=
y>var</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN>=
<SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>=3D</SPAN><SPAN styl=
e=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: =
#008" class=3Dstyled-by-prettify>begin</SPAN><SPAN style=3D"COLOR: #660" cl=
ass=3Dstyled-by-prettify>(</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled=
-by-prettify>cont</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prett=
ify>);</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</SPAN><SPAN style=3D"COLOR: #800" class=
=3Dstyled-by-prettify>// initialisation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prett=
ify>&nbsp;<BR>label3</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-pr=
ettify>:</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SP=
AN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-prettify>if</SPAN><SPAN st=
yle=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR=
: #660" class=3Dstyled-by-prettify>(</SPAN><SPAN style=3D"COLOR: #008" clas=
s=3Dstyled-by-prettify>var</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled=
-by-prettify> </SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify=
>=3D=3D</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPA=
N><SPAN style=3D"COLOR: #008" class=3Dstyled-by-prettify>end</SPAN><SPAN st=
yle=3D"COLOR: #660" class=3Dstyled-by-prettify>(</SPAN><SPAN style=3D"COLOR=
: #000" class=3Dstyled-by-prettify>cont</SPAN><SPAN style=3D"COLOR: #660" c=
lass=3Dstyled-by-prettify>))</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyl=
ed-by-prettify> </SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-pretti=
fy>goto</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> label=
4</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>;</SPAN><SPA=
N style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"C=
OLOR: #800" class=3Dstyled-by-prettify>// continuation &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp;</SPAN><SPAN style=3D"COLOR: #000" class=3D=
styled-by-prettify>&nbsp;<BR>&nbsp; &nbsp; &nbsp; &nbsp; code</SPAN><SPAN s=
tyle=3D"COLOR: #660" class=3Dstyled-by-prettify>;</SPAN><SPAN style=3D"COLO=
R: #000" class=3Dstyled-by-prettify> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp;&nbsp;<BR>&nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"C=
OLOR: #660" class=3Dstyled-by-prettify>++</SPAN><SPAN style=3D"COLOR: #008"=
 class=3Dstyled-by-prettify>var</SPAN><SPAN style=3D"COLOR: #660" class=3Ds=
tyled-by-prettify>;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-pre=
ttify> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"COLOR: #800" class=3Dst=
yled-by-prettify>// iteration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>&nbsp;=
<BR>&nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"COLOR: #008" class=3D=
styled-by-prettify>goto</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by=
-prettify> label3</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prett=
ify>;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;<BR>label4</SPAN><SPAN s=
tyle=3D"COLOR: #660" class=3Dstyled-by-prettify>:</SPAN><SPAN style=3D"COLO=
R: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #008" cla=
ss=3Dstyled-by-prettify>var</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyle=
d-by-prettify>::~</SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-prett=
ify>var</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>();</S=
PAN></DIV></CODE></DIV><BR>
<DIV>So, if</DIV>
<DIV>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid" class=3Dsubprettyprint>&nbsp;</DIV>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid" class=3Dprettyprint><CODE class=3Dprettypri=
nt>
<DIV class=3Dsubprettyprint><SPAN style=3D"COLOR: #000" class=3Dstyled-by-p=
rettify>&nbsp;</SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-prettify=
>for</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><=
SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>(</SPAN><SPAN style=
=3D"COLOR: #606" class=3Dstyled-by-prettify>Type1</SPAN><SPAN style=3D"COLO=
R: #000" class=3Dstyled-by-prettify> var1 </SPAN><SPAN style=3D"COLOR: #660=
" class=3Dstyled-by-prettify>=3D</SPAN><SPAN style=3D"COLOR: #000" class=3D=
styled-by-prettify> init</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-b=
y-prettify>;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> =
</SPAN><SPAN style=3D"COLOR: #606" class=3Dstyled-by-prettify>Type2</SPAN><=
SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> var2 </SPAN><SPAN st=
yle=3D"COLOR: #660" class=3Dstyled-by-prettify>:</SPAN><SPAN style=3D"COLOR=
: #000" class=3Dstyled-by-prettify> cont</SPAN><SPAN style=3D"COLOR: #660" =
class=3Dstyled-by-prettify>;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyl=
ed-by-prettify> iter</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-pr=
ettify>)</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> code=
</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>;</SPAN></DIV=
></CODE></DIV><BR></DIV>
<DIV>where allowed, logically it would have the following consequence:</DIV=
>
<DIV>&nbsp;</DIV>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid" class=3Dprettyprint><CODE class=3Dprettypri=
nt>
<DIV class=3Dsubprettyprint><SPAN style=3D"COLOR: #000" class=3Dstyled-by-p=
rettify>&nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"COLOR: #606" clas=
s=3Dstyled-by-prettify>Type1</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyl=
ed-by-prettify> var1 </SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-p=
rettify>=3D</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> i=
nit</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>;</SPAN><S=
PAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</SPAN><SPAN style=3D"COLOR: #800"=
 class=3Dstyled-by-prettify>// initialisation of var1 &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN=
 style=3D"COLOR: #000" class=3Dstyled-by-prettify>&nbsp;<BR>label5</SPAN><S=
PAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>:</SPAN><SPAN style=3D=
"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #606=
" class=3Dstyled-by-prettify>Type2</SPAN><SPAN style=3D"COLOR: #000" class=
=3Dstyled-by-prettify> var2 </SPAN><SPAN style=3D"COLOR: #660" class=3Dstyl=
ed-by-prettify>=3D</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-pret=
tify> </SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-prettify>begin</=
SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>(</SPAN><SPAN s=
tyle=3D"COLOR: #000" class=3Dstyled-by-prettify>cont</SPAN><SPAN style=3D"C=
OLOR: #660" class=3Dstyled-by-prettify>);</SPAN><SPAN style=3D"COLOR: #000"=
 class=3Dstyled-by-prettify> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPA=
N style=3D"COLOR: #800" class=3Dstyled-by-prettify>// initialisation of var=
2 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; </SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>&n=
bsp;<BR>label6</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify=
>:</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SP=
AN style=3D"COLOR: #008" class=3Dstyled-by-prettify>if</SPAN><SPAN style=3D=
"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #660=
" class=3Dstyled-by-prettify>(</SPAN><SPAN style=3D"COLOR: #000" class=3Dst=
yled-by-prettify>var2 </SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-=
prettify>=3D=3D</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettif=
y> </SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-prettify>end</SPAN>=
<SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>(</SPAN><SPAN style=
=3D"COLOR: #000" class=3Dstyled-by-prettify>cont</SPAN><SPAN style=3D"COLOR=
: #660" class=3Dstyled-by-prettify>))</SPAN><SPAN style=3D"COLOR: #000" cla=
ss=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-=
by-prettify>goto</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-pretti=
fy> label7</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>;</=
SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN s=
tyle=3D"COLOR: #800" class=3Dstyled-by-prettify>// continuation of var2 &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; </SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>&nbsp;<=
BR>&nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"COLOR: #660" class=3Ds=
tyled-by-prettify>++</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-pr=
ettify>var2</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>;<=
/SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; </SPAN><SPAN style=3D"COLOR: #800" class=3Dstyled-by-prettify>// =
iteration of var2 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"COLOR: #000" class=3Dstyle=
d-by-prettify>&nbsp;<BR>&nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"C=
OLOR: #008" class=3Dstyled-by-prettify>goto</SPAN><SPAN style=3D"COLOR: #00=
0" class=3Dstyled-by-prettify> label6</SPAN><SPAN style=3D"COLOR: #660" cla=
ss=3Dstyled-by-prettify>;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-=
by-prettify> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp;</SPAN><SPAN style=3D"COLOR: #800" class=3Dstyled-by-p=
rettify>// NB. the var2 loop is empty &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"COLOR:=
 #000" class=3Dstyled-by-prettify>&nbsp;<BR>label7</SPAN><SPAN style=3D"COL=
OR: #660" class=3Dstyled-by-prettify>:</SPAN><SPAN style=3D"COLOR: #000" cl=
ass=3Dstyled-by-prettify> var2</SPAN><SPAN style=3D"COLOR: #660" class=3Dst=
yled-by-prettify>::~</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-pr=
ettify>var2</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>()=
;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp;<BR>&nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"COLOR: #008" clas=
s=3Dstyled-by-prettify>if</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-=
by-prettify> </SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>=
(</SPAN><SPAN style=3D"COLOR: #008" class=3Dstyled-by-prettify>false</SPAN>=
<SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>)</SPAN><SPAN style=
=3D"COLOR: #000" class=3Dstyled-by-prettify> </SPAN><SPAN style=3D"COLOR: #=
008" class=3Dstyled-by-prettify>goto</SPAN><SPAN style=3D"COLOR: #000" clas=
s=3Dstyled-by-prettify> label8</SPAN><SPAN style=3D"COLOR: #660" class=3Dst=
yled-by-prettify>;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-pret=
tify> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"COLOR=
: #800" class=3Dstyled-by-prettify>// continuation of var1=E2=80=94no condi=
tion in the continuation means =E2=80=98forever=E2=80=99 &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </SPAN><S=
PAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>&nbsp;<BR>&nbsp; &nbsp=
; &nbsp; &nbsp; code</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-pr=
ettify>;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"COLOR: #800" class=3Dstyled=
-by-prettify>// NB. var2 is out of scope &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"COL=
OR: #000" class=3Dstyled-by-prettify>&nbsp;<BR>&nbsp; &nbsp; &nbsp; &nbsp; =
iter</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>;</SPAN><=
SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify> &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; </SPAN><SPAN style=3D"COLOR: #800" class=3Dstyled-by-prettify>// =
iteration of var1 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"COLOR: #000" class=3Dstyle=
d-by-prettify>&nbsp;<BR>&nbsp; &nbsp; &nbsp; &nbsp; </SPAN><SPAN style=3D"C=
OLOR: #008" class=3Dstyled-by-prettify>goto</SPAN><SPAN style=3D"COLOR: #00=
0" class=3Dstyled-by-prettify> label5</SPAN><SPAN style=3D"COLOR: #660" cla=
ss=3Dstyled-by-prettify>;</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-=
by-prettify> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp;<BR>label8</SPAN><SPAN style=3D"COLOR: #660" cl=
ass=3Dstyled-by-prettify>:</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled=
-by-prettify> var1</SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-pret=
tify>::~</SPAN><SPAN style=3D"COLOR: #000" class=3Dstyled-by-prettify>var1<=
/SPAN><SPAN style=3D"COLOR: #660" class=3Dstyled-by-prettify>();</SPAN></DI=
V></CODE></DIV><BR>
<P>I expect this is not what is wanted.<BR></P></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_553_26407699.1401364872958--

.

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


On Friday, May 30, 2014 12:01:13 AM UTC+12, Douglas Boffey wrote:
>
> If we look at how the for-loops would be expanded (pre-optimisation):
> =20
>  for (Type var =3D init; final; iter) code;
> =20
> would become
>
> =20
>          Type var =3D init;          // initialisation                   =
 =20
>                                                                =20
> label1: if (!final) goto label 2; // continuation                        =
=20
>                                                            =20
>         code;                                                            =
=20
>                        =20
>         iter;                     // iteration                          =
=20
>                                                          =20
>         goto label1;                                                    =
=20
>                                =20
> label2: var::~var();
>
> Here, I use a call to the destructor to indicate where the variable goes=
=20
> out of scope.
> Similarly,
> =20
>  for (Type var : cont) code;
>
> would become
>          Type var =3D begin(cont);            // initialisation          =
  =20
>                                              =20
> label3: if (var =3D=3D end(cont)) goto label4; // continuation           =
   =20
>                                            =20
>         code;                                                          =
=20
>         ++var;                             // iteration                  =
=20
>                                        =20
>         goto label3;                                                    =
=20
>      =20
> label4: var::~var();
>
> So, if
>  =20
>   for (Type1 var1 =3D init; Type2 var2 : cont; iter) code;
>
> where allowed, logically it would have the following consequence:
> =20
>          Type1 var1 =3D init;                  // initialisation of var1 =
 =20
>                       =20
> label5: Type2 var2 =3D begin(cont);           // initialisation of var2  =
  =20
>                     =20
> label6: if (var2 =3D=3D end(cont)) goto label7; // continuation of var2  =
    =20
>                   =20
>         ++var2;                             // iteration of var2        =
=20
>                 =20
>         goto label6;                        // NB. the var2 loop is empty=
=20
>                         =20
> label7: var2::~var2();                         =20
>         if (false) goto label8;             // continuation of var1=E2=80=
=94no=20
> condition in the continuation means =E2=80=98forever=E2=80=99            =
             =20
>         code;                               // NB. var2 is out of scope  =
=20
>                       =20
>         iter;                               // iteration of var1        =
=20
>                 =20
>         goto label5;                         =20
> label8: var1::~var1();
>
> I expect this is not what is wanted.
>


I find it hard the assembly code hard to follow, though I appreciate the=20
effort.
But I'm also not sure what you are concluding? I assume it's that my=20
propsoal won't work for some reason?

If so, may I cheat and use this as my source:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2049.pdf

It may be a little dated, but it describes the range for loop as thus:

for( type-specifier-seq simple-declarator : expression ) statement
which shall be syntactically equivalent to this, it says:
{
typedef decltype(expression) C;
auto&& rng(( expression ));
for( auto begin( std::For< C>::begin( rng) ), end( std::For< C>::end( rng)=
=20
);
    begin !=3D end; ++ begin ) {
    type-specifier-seq simple-declarator ( begin );
    statement
    }
}

So for my proposed new code statement of  this:
std::vector<int> c;
for (int i =3D 0; const auto& e : c; ++i )
    whatever();

Then where begin is initialized above, imagine int i =3D 0 is also performe=
d;
where we see ++begin done, imagine ++i is doned also, etc.

I can't see why this wouldn't work?

To my mind, we initialize a range, we step over each thing, and then things=
=20
go out of scope at range end.

Having the compiler initialize other things when the range initializes; run=
=20
other code as it steps; and have it all end when the range ends, doesn't=20
seem undesirable or impossible to achieve to me?

Put another way, if you deny people this, they will just end up writing=20
it anyway, something like this:

std::vector<int> c;
int i =3D 0;
for (const auto& e : c)
{
    whatever();
    ++i;
}

But why make them do that when they now have no access to "continue" as=20
using it will leave I un-incremented; and i is in the outer scope=20
which they don't want.

If you make them use the original loop construct as has been said, sure,=20
but they're back to toying with iterators and begin and end themselves. Why=
=20
force that on them? They want the new loop feature to avoid that.

Sot why make people do either if you can.let them have the best of both=20
worlds?

What makes range iteration so special that it can't play nice with any the=
=20
initialisation / stepping /scoping features we have that they=20
might want/need to use?=20

It is after all why the original for loop evolved to support those elements=
..

It's not been proved to my satisfaction why the new loop construct needs to=
=20
take those features away again or why it wont work to put them back.

If your assembly example demonstrates that, I'm sorry but that form makes=
=20
it hard for me to see it.

Conceptually I don't see a problem? The expansion rules from the original=
=20
range loop proposal don't suggest a problem to me either?

Thanks

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

<div dir=3D"ltr"><br>On Friday, May 30, 2014 12:01:13 AM UTC+12, Douglas Bo=
ffey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left=
-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>If we look at=
 how the for-loops would be expanded (pre-optimisation):</div>
<div>&nbsp;</div>
<div style=3D"border: 1px solid rgb(187, 187, 187); border-image: none; -ms=
-word-wrap: break-word; background-color: rgb(250, 250, 250);"><code>
<div><span style=3D"color: rgb(0, 0, 136);">for</span><span style=3D"color:=
 rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 102, 0);">(</span><s=
pan style=3D"color: rgb(102, 0, 102);">Type</span><span style=3D"color: rgb=
(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">var</span><span =
style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 102, =
0);">=3D</span><span style=3D"color: rgb(0, 0, 0);"> init</span><span style=
=3D"color: rgb(102, 102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);">=
 </span><span style=3D"color: rgb(0, 0, 136);">final</span><span style=3D"c=
olor: rgb(102, 102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);"> iter=
</span><span style=3D"color: rgb(102, 102, 0);">)</span><span style=3D"colo=
r: rgb(0, 0, 0);"> code</span><span style=3D"color: rgb(102, 102, 0);">;</s=
pan></div></code></div>
<div>&nbsp;</div>
<div>would become</div>
<p>&nbsp;</p>
<div style=3D"border: 1px solid rgb(187, 187, 187); border-image: none; -ms=
-word-wrap: break-word; background-color: rgb(250, 250, 250);"><code>
<div><span style=3D"color: rgb(0, 0, 0);">&nbsp; &nbsp; &nbsp; &nbsp; </spa=
n><span style=3D"color: rgb(102, 0, 102);">Type</span><span style=3D"color:=
 rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">var</span><s=
pan style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 1=
02, 0);">=3D</span><span style=3D"color: rgb(0, 0, 0);"> init</span><span s=
tyle=3D"color: rgb(102, 102, 0);">;</span><span style=3D"color: rgb(0, 0, 0=
);"> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</span><span style=3D"color: rgb(136=
, 0, 0);">// initialisation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp;</span><span style=3D"color: rgb(0, 0, 0);">&nbsp;<br>=
label1</span><span style=3D"color: rgb(102, 102, 0);">:</span><span style=
=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">if=
</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: r=
gb(102, 102, 0);">(!</span><span style=3D"color: rgb(0, 0, 136);">final</sp=
an><span style=3D"color: rgb(102, 102, 0);">)</span><span style=3D"color: r=
gb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">goto</span><sp=
an style=3D"color: rgb(0, 0, 0);"> label </span><span style=3D"color: rgb(0=
, 102, 102);">2</span><span style=3D"color: rgb(102, 102, 0);">;</span><spa=
n style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(136, 0, =
0);">// continuation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp;</span><span style=3D"color: rgb(0, 0, 0);">&nbsp;<br>&nbsp; =
&nbsp; &nbsp; &nbsp; code</span><span style=3D"color: rgb(102, 102, 0);">;<=
/span><span style=3D"color: rgb(0, 0, 0);"> &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;<br>&nbsp; &nbsp; &nbsp; &nbsp; =
iter</span><span style=3D"color: rgb(102, 102, 0);">;</span><span style=3D"=
color: rgb(0, 0, 0);"> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; </span><span style=3D"color: rgb(136, 0, 0);">// iteratio=
n &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</spa=
n><span style=3D"color: rgb(0, 0, 0);">&nbsp;<br>&nbsp; &nbsp; &nbsp; &nbsp=
; </span><span style=3D"color: rgb(0, 0, 136);">goto</span><span style=3D"c=
olor: rgb(0, 0, 0);"> label1</span><span style=3D"color: rgb(102, 102, 0);"=
>;</span><span style=3D"color: rgb(0, 0, 0);"> &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;<br>label2</span><span style=
=3D"color: rgb(102, 102, 0);">:</span><span style=3D"color: rgb(0, 0, 0);">=
 </span><span style=3D"color: rgb(0, 0, 136);">var</span><span style=3D"col=
or: rgb(102, 102, 0);">::~</span><span style=3D"color: rgb(0, 0, 136);">var=
</span><span style=3D"color: rgb(102, 102, 0);">();</span></div></code></di=
v><br>
<p>Here, I use a call to the destructor to indicate where the variable goes=
 out of scope.</p>
<div>Similarly,</div>
<div>&nbsp;</div>
<div style=3D"border: 1px solid rgb(187, 187, 187); border-image: none; -ms=
-word-wrap: break-word; background-color: rgb(250, 250, 250);"><code>
<div><span style=3D"color: rgb(0, 0, 136);">for</span><span style=3D"color:=
 rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 102, 0);">(</span><s=
pan style=3D"color: rgb(102, 0, 102);">Type</span><span style=3D"color: rgb=
(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">var</span><span =
style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 102, =
0);">:</span><span style=3D"color: rgb(0, 0, 0);"> cont</span><span style=
=3D"color: rgb(102, 102, 0);">)</span><span style=3D"color: rgb(0, 0, 0);">=
 code</span><span style=3D"color: rgb(102, 102, 0);">;</span></div></code><=
/div><br>
<p>would become</p>
<div style=3D"border: 1px solid rgb(187, 187, 187); border-image: none; -ms=
-word-wrap: break-word; background-color: rgb(250, 250, 250);"><code>
<div><span style=3D"color: rgb(0, 0, 0);">&nbsp; &nbsp; &nbsp; &nbsp; </spa=
n><span style=3D"color: rgb(102, 0, 102);">Type</span><span style=3D"color:=
 rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">var</span><s=
pan style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 1=
02, 0);">=3D</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=
=3D"color: rgb(0, 0, 136);">begin</span><span style=3D"color: rgb(102, 102,=
 0);">(</span><span style=3D"color: rgb(0, 0, 0);">cont</span><span style=
=3D"color: rgb(102, 102, 0);">);</span><span style=3D"color: rgb(0, 0, 0);"=
> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</span><span style=3D"color: rgb=
(136, 0, 0);">// initialisation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp;</span><span style=3D"color: rgb(0, 0, 0);">&nbsp;<br>label3</span=
><span style=3D"color: rgb(102, 102, 0);">:</span><span style=3D"color: rgb=
(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">if</span><span s=
tyle=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 102, 0=
);">(</span><span style=3D"color: rgb(0, 0, 136);">var</span><span style=3D=
"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 102, 0);">=3D=
=3D</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color=
: rgb(0, 0, 136);">end</span><span style=3D"color: rgb(102, 102, 0);">(</sp=
an><span style=3D"color: rgb(0, 0, 0);">cont</span><span style=3D"color: rg=
b(102, 102, 0);">))</span><span style=3D"color: rgb(0, 0, 0);"> </span><spa=
n style=3D"color: rgb(0, 0, 136);">goto</span><span style=3D"color: rgb(0, =
0, 0);"> label4</span><span style=3D"color: rgb(102, 102, 0);">;</span><spa=
n style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(136, 0, =
0);">// continuation &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</=
span><span style=3D"color: rgb(0, 0, 0);">&nbsp;<br>&nbsp; &nbsp; &nbsp; &n=
bsp; code</span><span style=3D"color: rgb(102, 102, 0);">;</span><span styl=
e=3D"color: rgb(0, 0, 0);"> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp;&nbsp;<br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: rgb=
(102, 102, 0);">++</span><span style=3D"color: rgb(0, 0, 136);">var</span><=
span style=3D"color: rgb(102, 102, 0);">;</span><span style=3D"color: rgb(0=
, 0, 0);"> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: rgb(136, 0, =
0);">// iteration &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</spa=
n><span style=3D"color: rgb(0, 0, 0);">&nbsp;<br>&nbsp; &nbsp; &nbsp; &nbsp=
; </span><span style=3D"color: rgb(0, 0, 136);">goto</span><span style=3D"c=
olor: rgb(0, 0, 0);"> label3</span><span style=3D"color: rgb(102, 102, 0);"=
>;</span><span style=3D"color: rgb(0, 0, 0);"> &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp;&nbsp;<br>label4</span><span style=3D"color: rgb(10=
2, 102, 0);">:</span><span style=3D"color: rgb(0, 0, 0);"> </span><span sty=
le=3D"color: rgb(0, 0, 136);">var</span><span style=3D"color: rgb(102, 102,=
 0);">::~</span><span style=3D"color: rgb(0, 0, 136);">var</span><span styl=
e=3D"color: rgb(102, 102, 0);">();</span></div></code></div><br>
<div>So, if</div>
<div>
<div style=3D"border: 1px solid rgb(187, 187, 187); border-image: none; -ms=
-word-wrap: break-word; background-color: rgb(250, 250, 250);">&nbsp;</div>
<div style=3D"border: 1px solid rgb(187, 187, 187); border-image: none; -ms=
-word-wrap: break-word; background-color: rgb(250, 250, 250);"><code>
<div><span style=3D"color: rgb(0, 0, 0);">&nbsp;</span><span style=3D"color=
: rgb(0, 0, 136);">for</span><span style=3D"color: rgb(0, 0, 0);"> </span><=
span style=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(1=
02, 0, 102);">Type1</span><span style=3D"color: rgb(0, 0, 0);"> var1 </span=
><span style=3D"color: rgb(102, 102, 0);">=3D</span><span style=3D"color: r=
gb(0, 0, 0);"> init</span><span style=3D"color: rgb(102, 102, 0);">;</span>=
<span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102,=
 0, 102);">Type2</span><span style=3D"color: rgb(0, 0, 0);"> var2 </span><s=
pan style=3D"color: rgb(102, 102, 0);">:</span><span style=3D"color: rgb(0,=
 0, 0);"> cont</span><span style=3D"color: rgb(102, 102, 0);">;</span><span=
 style=3D"color: rgb(0, 0, 0);"> iter</span><span style=3D"color: rgb(102, =
102, 0);">)</span><span style=3D"color: rgb(0, 0, 0);"> code</span><span st=
yle=3D"color: rgb(102, 102, 0);">;</span></div></code></div><br></div>
<div>where allowed, logically it would have the following consequence:</div=
>
<div>&nbsp;</div>
<div style=3D"border: 1px solid rgb(187, 187, 187); border-image: none; -ms=
-word-wrap: break-word; background-color: rgb(250, 250, 250);"><code>
<div><span style=3D"color: rgb(0, 0, 0);">&nbsp; &nbsp; &nbsp; &nbsp; </spa=
n><span style=3D"color: rgb(102, 0, 102);">Type1</span><span style=3D"color=
: rgb(0, 0, 0);"> var1 </span><span style=3D"color: rgb(102, 102, 0);">=3D<=
/span><span style=3D"color: rgb(0, 0, 0);"> init</span><span style=3D"color=
: rgb(102, 102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);"> &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</span><span style=3D=
"color: rgb(136, 0, 0);">// initialisation of var1 &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; </span><span st=
yle=3D"color: rgb(0, 0, 0);">&nbsp;<br>label5</span><span style=3D"color: r=
gb(102, 102, 0);">:</span><span style=3D"color: rgb(0, 0, 0);"> </span><spa=
n style=3D"color: rgb(102, 0, 102);">Type2</span><span style=3D"color: rgb(=
0, 0, 0);"> var2 </span><span style=3D"color: rgb(102, 102, 0);">=3D</span>=
<span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0=
, 136);">begin</span><span style=3D"color: rgb(102, 102, 0);">(</span><span=
 style=3D"color: rgb(0, 0, 0);">cont</span><span style=3D"color: rgb(102, 1=
02, 0);">);</span><span style=3D"color: rgb(0, 0, 0);"> &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; </span><span style=3D"color: rgb(136, 0, 0);">// initialisa=
tion of var2 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; </span><span style=3D"color: rgb(0, 0, 0);">&nbsp;<br=
>label6</span><span style=3D"color: rgb(102, 102, 0);">:</span><span style=
=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">if=
</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: r=
gb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 0);">var2 </span>=
<span style=3D"color: rgb(102, 102, 0);">=3D=3D</span><span style=3D"color:=
 rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">end</span><s=
pan style=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0,=
 0, 0);">cont</span><span style=3D"color: rgb(102, 102, 0);">))</span><span=
 style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136=
);">goto</span><span style=3D"color: rgb(0, 0, 0);"> label7</span><span sty=
le=3D"color: rgb(102, 102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);=
"> </span><span style=3D"color: rgb(136, 0, 0);">// continuation of var2 &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; </span><span style=3D"color: rgb(0, 0, 0);">&nbsp;<br>&nbsp; &nbsp; =
&nbsp; &nbsp; </span><span style=3D"color: rgb(102, 102, 0);">++</span><spa=
n style=3D"color: rgb(0, 0, 0);">var2</span><span style=3D"color: rgb(102, =
102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);"> &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; </span><span style=3D"color: rgb(136, 0, 0);">// iteration of var2 &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; </span><span style=3D"color: rgb(0, 0, 0);">&nbsp;<br>&nbsp; &nbsp; &n=
bsp; &nbsp; </span><span style=3D"color: rgb(0, 0, 136);">goto</span><span =
style=3D"color: rgb(0, 0, 0);"> label6</span><span style=3D"color: rgb(102,=
 102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);"> &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;</span><sp=
an style=3D"color: rgb(136, 0, 0);">// NB. the var2 loop is empty &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
</span><span style=3D"color: rgb(0, 0, 0);">&nbsp;<br>label7</span><span st=
yle=3D"color: rgb(102, 102, 0);">:</span><span style=3D"color: rgb(0, 0, 0)=
;"> var2</span><span style=3D"color: rgb(102, 102, 0);">::~</span><span sty=
le=3D"color: rgb(0, 0, 0);">var2</span><span style=3D"color: rgb(102, 102, =
0);">();</span><span style=3D"color: rgb(0, 0, 0);"> &nbsp; &nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br>&nb=
sp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: rgb(0, 0, 136);">if</=
span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb=
(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 136);">false</span>=
<span style=3D"color: rgb(102, 102, 0);">)</span><span style=3D"color: rgb(=
0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">goto</span><span =
style=3D"color: rgb(0, 0, 0);"> label8</span><span style=3D"color: rgb(102,=
 102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);"> &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: rgb(136, 0, 0);">// co=
ntinuation of var1=E2=80=94no condition in the continuation means =E2=80=98=
forever=E2=80=99 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: rgb(0, 0, 0);">&nbsp=
;<br>&nbsp; &nbsp; &nbsp; &nbsp; code</span><span style=3D"color: rgb(102, =
102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);"> &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; </span><span style=3D"color: rgb(136, 0, 0);">// NB. var2 is out=
 of scope &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; </span><span style=3D"color: rgb(0, 0, 0);">&nbsp;<br>&n=
bsp; &nbsp; &nbsp; &nbsp; iter</span><span style=3D"color: rgb(102, 102, 0)=
;">;</span><span style=3D"color: rgb(0, 0, 0);"> &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; </span><span style=3D"color: rgb(136, 0, 0);">// iteration of var1 &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; </span><span style=3D"color: rgb(0, 0, 0);">&nbsp;<br>&nbsp; &nbsp; &n=
bsp; &nbsp; </span><span style=3D"color: rgb(0, 0, 136);">goto</span><span =
style=3D"color: rgb(0, 0, 0);"> label5</span><span style=3D"color: rgb(102,=
 102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);"> &nbsp; &nbsp; &nbs=
p; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<br=
>label8</span><span style=3D"color: rgb(102, 102, 0);">:</span><span style=
=3D"color: rgb(0, 0, 0);"> var1</span><span style=3D"color: rgb(102, 102, 0=
);">::~</span><span style=3D"color: rgb(0, 0, 0);">var1</span><span style=
=3D"color: rgb(102, 102, 0);">();</span></div></code></div><br>
<p>I expect this is not what is wanted.<br></p></div></blockquote><div><br>=
</div><div><br></div><div>I find it hard&nbsp;the assembly code hard to fol=
low, though I appreciate the effort.</div><div>But I'm also not sure what y=
ou are concluding? I assume it's that my propsoal won't work for some reaso=
n?</div><div><br></div><div>If so, may I cheat and use this as my source:<b=
r><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2049.=
pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2049.pdf</a><=
/div><div><br></div><div>It may be a little dated, but it describes the ran=
ge for loop as thus:</div><div><br></div><div>for( type-specifier-seq simpl=
e-declarator : expression ) statement</div><div>which shall be syntacticall=
y equivalent to this, it says:</div><div>{<br>typedef decltype(expression) =
C;<br>auto&amp;&amp; rng(( expression ));<br>for( auto begin( std::For&lt; =
C&gt;::begin( rng) ), end( std::For&lt; C&gt;::end( rng) );<br>&nbsp;&nbsp;=
&nbsp; begin !=3D end; ++ begin ) {<br>&nbsp;&nbsp;&nbsp; type-specifier-se=
q simple-declarator ( begin );<br>&nbsp;&nbsp;&nbsp; statement<br>&nbsp;&nb=
sp;&nbsp; }<br>}</div><div><br></div><div>So for my proposed new code state=
ment of&nbsp; this:</div><div>std::vector&lt;int&gt; c;<br>for (int i =3D 0=
; const auto&amp; e : c; ++i )<br>&nbsp;&nbsp;&nbsp; whatever();</div><div>=
<br></div><div>Then where begin is initialized above, imagine int i =3D 0 i=
s also performed;<br>where we see ++begin done, imagine ++i is doned also, =
etc.</div><div><br></div><div>I can't see why this wouldn't work?</div><div=
><br></div><div>To my mind, we initialize a range, we step over each thing,=
 and then things go out of scope at range end.<br></div><div><br></div><div=
>Having the compiler initialize other things when the range initializes; ru=
n other code as it steps; and have it all end when the range ends, doesn't =
seem undesirable or impossible to achieve to me?</div><div><br>Put another =
way, if you deny&nbsp;people this,&nbsp;they will&nbsp;just end up writing =
it&nbsp;anyway, something like this:</div><div><br></div><div>std::vector&l=
t;int&gt; c;<br>int i =3D 0;<br>for (const auto&amp; e : c)<br>{<br>&nbsp;&=
nbsp;&nbsp; whatever();<br>&nbsp;&nbsp;&nbsp; ++i;<br>}</div><div><br></div=
><div>But why make them&nbsp;do that when&nbsp;they now have no access to "=
continue" as using it will leave I un-incremented; and i is in the outer sc=
ope which&nbsp;they don't want.</div><div><br>If&nbsp;you make&nbsp;them&nb=
sp;use the original loop construct as has been said, sure, but&nbsp;they're=
 back to toying with iterators and begin and end themselves. Why force that=
 on them? They want the new loop feature to avoid that.</div><div><br></div=
><div>Sot why make people&nbsp;do&nbsp;either if you can.let them have the =
best of both worlds?</div><div><br></div><div>What makes range iteration so=
 special that it can't play nice with any&nbsp;the initialisation / steppin=
g /scoping&nbsp;features we have that they might&nbsp;want/need to use?&nbs=
p;</div><div><br></div><div>It is after all why the original for loop evolv=
ed to support those elements.</div><div><br></div><div>It's not been proved=
 to my satisfaction why the new loop construct needs to take those features=
 away again or why it wont work to put them back.</div><div><br></div><div>=
If your assembly example demonstrates that, I'm sorry&nbsp;but that&nbsp;fo=
rm makes it hard for me to see it.</div><div><br></div><div>Conceptually I =
don't see a problem? The expansion rules from the original range loop propo=
sal don't suggest a problem to me either?</div><div><br></div><div>Thanks</=
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_1138_14337856.1401369076958--

.

------=_Part_536_9265200.1401391508386
Content-Type: text/plain; charset=UTF-8

I have some things to add to the conversation: first of all, I don't like
the syntax. At all. As many people here, I prefere the tuple unpacking and
std::enumerate solution. I agree that it is subjective before anything
else, but I just don't like it, sorry for that :(. However, no matter how
subjective something is, if 90% of the people don't like a solution and
prefer an alternative, the alternative will probably be chosen instead.

Why did the current for loop made its way to the standard? First of all,
people didn't really like the iterator boilerplate in the traditional for
loop. Library solutions have been proposed (BOOST_FOREACH for example) and
it seems that it wasn't really satisfying, so a language solution was
needed to reduce the syntax. By the way, the syntax is roughly the same as
the one used in Java's foreach loops, so this solution already exists
somewhere else, and many people are already used to it.

Why do we think that tuple unpacking and std::enumerate is a better
alternative? First of all, as it has already been said, tuple unpacking is
a much wanted feature, not only to solve this problem, but because it would
help in other areas too. Moreover, tuple unpacking exists in many
programming languages with a similar syntax than the one proposed.
Moreover, Python already uses a built-in function named "enumerate" to
iterate over a container and provide an index along with the element.
Actually, the proposed std::enumerate function would be almost exactly the
same as the Python one, so it's already well understood, and there are
probably many Python developpers around. There are also many C++(11)
versions of enumerate available all around the internet (they generally
yield std::pair<size_t, T> values). The only thing needed for such a
function to be *really* cool is tuple unpacking.

Why don't I like your solution? First of all, I always found that the
C-style for loop was no more than a hack around a regular while. The only
difference is the place of the declaration and of the increment, as well as
the scope of the declared variable (and we can get around that by putting a
while loop in a new scope). The range-based for loop offers a new level of
abstraction, so I wouldn't want of a "new" loop that still forces me to
write the iterator increment stuff by hand. At least, std::enumerate
automagically produces the indices, we don't have to compute them by hand.
Moreover, while "enumerate" is easy to find with a searching tool, your
proposed syntax is rather hard to find, and if one reads too fast, they may
think it is a regular C-style for loop.

That pretty sums up what I think, and probably what other people think here
:)

--

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

<div dir=3D"ltr">I have some things to add to the conversation: first of al=
l, I don't like the syntax. At all. As many people here, I prefere the tupl=
e unpacking and std::enumerate solution. I agree that it is subjective befo=
re anything else, but I just don't like it, sorry for that :(. However, no =
matter how subjective something is, if 90% of the people don't like a solut=
ion and prefer an alternative, the alternative will probably be chosen inst=
ead.<br><br>Why did the current for loop made its way to the standard? Firs=
t of all, people didn't really like the iterator boilerplate in the traditi=
onal for loop. Library solutions have been proposed (BOOST_FOREACH for exam=
ple) and it seems that it wasn't really satisfying, so a language solution =
was needed to reduce the syntax. By the way, the syntax is roughly the same=
 as the one used in Java's foreach loops, so this solution already exists s=
omewhere else, and many people are already used to it.<br><br>Why do we thi=
nk that tuple unpacking and std::enumerate is a better alternative? First o=
f all, as it has already been said, tuple unpacking is a much wanted featur=
e, not only to solve this problem, but because it would help in other areas=
 too. Moreover, tuple unpacking exists in many programming languages with a=
 similar syntax than the one proposed. Moreover, Python already uses a buil=
t-in function named "enumerate" to iterate over a container and provide an =
index along with the element. Actually, the proposed std::enumerate functio=
n would be almost exactly the same as the Python one, so it's already well =
understood, and there are probably many Python developpers around. There ar=
e also many C++(11) versions of enumerate available all around the internet=
 (they generally yield std::pair&lt;size_t, T&gt; values). The only thing n=
eeded for such a function to be *really* cool is tuple unpacking.<br><br>Wh=
y don't I like your solution? First of all, I always found that the C-style=
 for loop was no more than a hack around a regular while. The only differen=
ce is the place of the declaration and of the increment, as well as the sco=
pe of the declared variable (and we can get around that by putting a while =
loop in a new scope). The range-based for loop offers a new level of abstra=
ction, so I wouldn't want of a "new" loop that still forces me to write the=
 iterator increment stuff by hand. At least, std::enumerate automagically p=
roduces the indices, we don't have to compute them by hand. Moreover, while=
 "enumerate" is easy to find with a searching tool, your proposed syntax is=
 rather hard to find, and if one reads too fast, they may think it is a reg=
ular C-style for loop.<br><br>That pretty sums up what I think, and probabl=
y what other people think here :)<br></div>

<p></p>

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

------=_Part_536_9265200.1401391508386--

.

------=_Part_3_19978017.1401404087651
Content-Type: text/plain; charset=UTF-8



On Friday, May 30, 2014 7:25:08 AM UTC+12, morw...@gmail.com wrote:
>
> I have some things to add to the conversation: first of all, I don't like
> the syntax. At all. As many people here,
>

Yes many. But we really need to get beyond the focus on the
syntax while people are not showing example alternative code or
libraries that demonstrably provides the same feature set I have mentioned,
that we all know the original for loop provides.



> I prefere the tuple unpacking and std::enumerate solution. I agree that it
> is subjective before anything else, but I just don't like it, sorry for
> that :(. However, no matter how subjective something is, if 90% of the
> people don't like a solution and prefer an alternative, the alternative
> will probably be chosen instead.
>

I don't quite see how tuple unpacking  relates to this, it may do, but
that's exactly why example code is needed, to demonstrate that part too.


>
> Why did the current for loop made its way to the standard? First of all,
> people didn't really like the iterator boilerplate in the traditional for
> loop. Library solutions have been proposed (BOOST_FOREACH for example) and
> it seems that it wasn't really satisfying, so a language solution was
> needed to reduce the syntax. By the way, the syntax is roughly the same as
> the one used in Java's foreach loops, so this solution already exists
> somewhere else, and many people are already used to it.
>

Agreed, but I'm not taking that away from them or forcing them to use the
new parts I'm suggesting. in fact what I'm suggesting might even help with
that.

Since my proposal extends the new loop with real features that you don't
have to use nor pay for if you don't, some kind of fancy std::enumerate
solution is still available to you. But you still have to demonstrate it.
My extension may even offer new opportunities to any suggested
std::enumerate scenario or a variation of it, if it's also extending the
new loop, but with no such library or code actually being demonstrated here
to contrast against my proposal, who knows?

>
> Why do we think that tuple unpacking and std::enumerate is a better
> alternative? First of all, as it has already been said, tuple unpacking is
> a much wanted feature,
>
Not by me, see my comments in the related thread.


> not only to solve this problem, but because it would help in other areas
> too.
>

Not sure why we are talking about it here then, but ok, I don't mind the
distraction.


> Moreover, tuple unpacking exists in many programming languages with a
> similar syntax than the one proposed. Moreover, Python already uses a
> built-in function named "enumerate" to iterate over a container and provide
> an index along with the element. Actually, the proposed std::enumerate
> function would be almost exactly the same as the Python one, so it's
> already well understood, and there are probably many Python developpers
> around. There are also many C++(11) versions of enumerate available all
> around the internet (they generally yield std::pair<size_t, T> values). The
> only thing needed for such a function to be *really* cool is tuple
> unpacking.
>

Yes, but a single index isn't the only thing people track or do in their
step and it doesn't have to be + 1 or even an increment at all.

What your imaginary library offers me isn't guaranteed to exactly relate to
what I want or be sufficient. But with my proposal being an extension to
yours (it would seem), you can still use what your library provides if it
is sufficient or augment it if it isn't with mine.


> Why don't I like your solution? First of all, I always found that the
> C-style for loop was no more than a hack around a regular while.
>

That's a bit harsh. If it's true, people have used that hack in preference
to while for many years and I still use for more than while by far in my
code today. That was as true for me in C as it is C++.


> The only difference is the place of the declaration and of the increment,
> as well as the scope of the declared variable (and we can get around that
> by putting a while loop in a new scope). The range-based for loop offers a
> new level of abstraction, so I wouldn't want of a "new" loop that still
> forces me to write the iterator increment stuff by hand.
>

Wait, wait. Where have I ever mentioned something in my proposal that
forces anything?

Quite the contrary I've actually explained why alternative proposals are
doing the forcing if anything so I'm not sure where you get this idea?

All I've demonstrated is that a hybrid of the two loops lets everybody get
the best of both loops exactly so nobody is forced to do anything, they
just pick and mix.


> At least, std::enumerate automagically produces the indices, we don't have
> to compute them by hand.
>

Again, that assumes there is just one index, it's +1 or that you even want
to increment anything at all in the step.


> Moreover, while "enumerate" is easy to find with a searching tool, your
> proposed syntax is rather hard to find, and if one reads too fast, they may
> think it is a regular C-style for loop.
>

Is that a real argument? I've seen whole pages of C++ code that looks like
C for that to be a worry or any confusion! lol Only half the time does that
bother me. That's the real worry!! lol

>
> That pretty sums up what I think, and probably what other people think
> here :)
>

I don't think anyone has attacked this proposal on substance yet, so I'm
not concerned by that yet. If they succeed, I'll be happy, I just want a
better mouse trap.

But to do that you've got to start talking features and examples that show
that and also why this proposal can't augment the alternative too.

So far I'm still not seeing that.

--

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

<div dir=3D"ltr"><br><br>On Friday, May 30, 2014 7:25:08 AM UTC+12, morw...=
@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">I have some =
things to add to the conversation: first of all, I don't like the syntax. A=
t all. As many people here, </div></blockquote><div><br></div><div>Yes many=
.. But we really need to get beyond the focus on the syntax&nbsp;while&nbsp;=
people are not showing&nbsp;example alternative code or libraries&nbsp;that=
 demonstrably provides the same feature set I have mentioned, that we all k=
now the original for loop provides.<br></div><div><br></div><div>&nbsp;</di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; pad=
ding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1=
px; border-left-style: solid;"><div dir=3D"ltr">I prefere the tuple unpacki=
ng and std::enumerate solution. I agree that it is subjective before anythi=
ng else, but I just don't like it, sorry for that :(. However, no matter ho=
w subjective something is, if 90% of the people don't like a solution and p=
refer an alternative, the alternative will probably be chosen instead.<br><=
/div></blockquote><div><br></div><div>I&nbsp;don't quite see how tuple unpa=
cking&nbsp; relates to this, it may do, but that's exactly why example code=
 is needed, to demonstrate that part too.<br></div><div>&nbsp;</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;"><div dir=3D"ltr"><br>Why did the current for loop mad=
e its way to the standard? First of all, people didn't really like the iter=
ator boilerplate in the traditional for loop. Library solutions have been p=
roposed (BOOST_FOREACH for example) and it seems that it wasn't really sati=
sfying, so a language solution was needed to reduce the syntax. By the way,=
 the syntax is roughly the same as the one used in Java's foreach loops, so=
 this solution already exists somewhere else, and many people are already u=
sed to it.<br></div></blockquote><div><br></div><div>Agreed, but I'm not ta=
king that away from them or forcing them to use the new parts I'm suggestin=
g. in fact what I'm suggesting might even help with that.</div><div><br></d=
iv><div>Since my proposal extends the new loop with real features that you =
don't have to use nor pay for if you don't, some kind of fancy std::enumera=
te solution is still available to you. But you still have to demonstrate it=
.. My extension may even offer new opportunities to&nbsp;any suggested std::=
enumerate scenario or a variation of it, if it's also extending the new loo=
p, but with no such library or code actually being demonstrated here to con=
trast against my proposal, who knows?</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color:=
 rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><di=
v dir=3D"ltr"><br>Why do we think that tuple unpacking and std::enumerate i=
s a better alternative? First of all, as it has already been said, tuple un=
packing is a much wanted feature, </div></blockquote><div>Not by me, see my=
 comments in the related thread.</div><div>&nbsp;</div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border=
-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style:=
 solid;"><div dir=3D"ltr">not only to solve this problem, but because it wo=
uld help in other areas too. </div></blockquote><div><br></div><div>Not sur=
e why we are talking about it here then, but ok, I don't mind the distracti=
on.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 20=
4); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">Mor=
eover, tuple unpacking exists in many programming languages with a similar =
syntax than the one proposed. Moreover, Python already uses a built-in func=
tion named "enumerate" to iterate over a container and provide an index alo=
ng with the element. Actually, the proposed std::enumerate function would b=
e almost exactly the same as the Python one, so it's already well understoo=
d, and there are probably many Python developpers around. There are also ma=
ny C++(11) versions of enumerate available all around the internet (they ge=
nerally yield std::pair&lt;size_t, T&gt; values). The only thing needed for=
 such a function to be *really* cool is tuple unpacking.<br></div></blockqu=
ote><div><br></div><div>Yes,&nbsp;but&nbsp;a single&nbsp;index isn't the on=
ly thing people track or do in their step and it doesn't have to be&nbsp;+ =
1&nbsp;or even an increment at all. </div><div><br></div><div>What&nbsp;you=
r imaginary&nbsp;library offers me isn't guaranteed to exactly relate to wh=
at I want or be sufficient. But&nbsp;with my proposal being an extension&nb=
sp;to yours (it would seem),&nbsp;you can&nbsp;still&nbsp;use what your lib=
rary provides if it is sufficient or augment it if it isn't with mine.</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br>Why don't=
 I like your solution? First of all, I always found that the C-style for lo=
op was no more than a hack around a regular while. </div></blockquote><div>=
&nbsp;</div><div>That's a bit harsh. If&nbsp;it's true, people have used th=
at hack in preference to while for many years and I still use for more than=
 while by far in my code today. That was as&nbsp;true for me&nbsp;in C&nbsp=
;as it is&nbsp;C++.&nbsp;</div><div>&nbsp;</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-c=
olor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;=
"><div dir=3D"ltr">The only difference is the place of the declaration and =
of the increment, as well as the scope of the declared variable (and we can=
 get around that by putting a while loop in a new scope). The range-based f=
or loop offers a new level of abstraction, so I wouldn't want of a "new" lo=
op that still forces me&nbsp;to write the iterator increment stuff by hand.=
 </div></blockquote><div><br></div><div>Wait, wait. Where have I ever menti=
oned something in my proposal that forces anything?</div><div><br></div><di=
v>Quite the contrary I've actually explained why alternative proposals&nbsp=
;are doing the forcing if anything so I'm not sure where you get this idea?=
</div><div><br></div><div>All I've demonstrated is that a hybrid of the two=
 loops lets everybody get the best of both loops exactly so nobody is force=
d to do anything, they just pick and mix.</div><div>&nbsp;</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1e=
x; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-le=
ft-style: solid;"><div dir=3D"ltr">At least, std::enumerate automagically p=
roduces the indices, we don't have to compute them by hand.</div></blockquo=
te><div><br></div><div>Again, that assumes there is just one index, it's +1=
 or that you even want to increment anything at all in the step.</div><div>=
&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;"><div dir=3D"ltr"> Moreover, while =
"enumerate" is easy to find with a searching tool, your proposed syntax is =
rather hard to find, and if one reads too fast, they may think it is a regu=
lar C-style for loop.<br></div></blockquote><div><br></div><div>Is that a r=
eal argument? I've seen&nbsp;whole&nbsp;pages of&nbsp;C++ code that looks l=
ike C&nbsp;for that to be a worry or any confusion! lol&nbsp;Only half the =
time does that bother me. That's the real worry!! lol</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bo=
rder-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-st=
yle: solid;"><div dir=3D"ltr"><br>That pretty sums up what I think, and pro=
bably what other people think here :)<br></div></blockquote><div><br></div>=
<div>I don't think anyone has attacked this proposal on substance yet, so&n=
bsp;I'm not&nbsp;concerned by that yet. If they succeed, I'll be happy, I j=
ust want a better mouse trap.</div><div><br></div><div>But to do that you'v=
e got to&nbsp;start talking features and examples that show that and also w=
hy this proposal can't augment the&nbsp;alternative too.</div><div><br></di=
v><div>So far I'm still not seeing that.</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_3_19978017.1401404087651--

.

------=_Part_83_1158815.1401414090403
Content-Type: text/plain; charset=UTF-8


On Thursday, May 29, 2014 6:54:48 PM UTC-4, gmis...@gmail.com wrote:

> But we really need to get beyond the focus on the syntax while people are
> not showing example alternative code or libraries that demonstrably
> provides the same feature set I have mentioned, that we all know the
> original for loop provides.
>
>
You have repeatedly suggested the syntax is not important but I strongly
disagree, because your proposal doesn't actually allow anything new. The
code:

for (size_t i = 0; const auto& e : v; ++i )
 do_something(i, e);

appears to be equivalent to the currently legal:

size_t i = 0;
for (const auto& e : v) do_something(i++, e);

or even if you couldn't use ++/-- because you need to increment by
something other than one, it would just be:

size_t i = 0;
for (const auto& e : v) {
    do_something(i, e);
    i += 2;
}

You don't need any libraries or new language features to write code that
does exactly the same thing, so your proposal is nothing more than syntax
sugar, therefore the syntax is not only important, it seems to be the
entire issue. If people don't like the syntax or think it's confusing, that
*is* a problem, because programming is more than writing code, it's also
reading code. Even if the people that don't like it, don't use it, they
will still be affected because they will inevitably have to work with or
maintain code written by people who do use it.



> I don't quite see how tuple unpacking  relates to this, it may do, but
> that's exactly why example code is needed, to demonstrate that part too.
> ...
> Yes, but a single index isn't the only thing people track or do in their
> step and it doesn't have to be + 1 or even an increment at all.
>
>
Tuple unpacking would allow the same one-line convenience if every sequence
was turned into an iterable object, which might look something like:

for(<int i,const auto &e> = zip(count(0,5), v)) do_something(i, e);

The "<type1 name1,type2 name2,...> = x" syntax would introduce name1, name2
and etc into the the current scope and assign to each std::get<0>(x),
std::get<1>(x) and etc (there isn't a consensus on the syntax, however).

"template<typename T> unspecified_t count(T start=0,T step=1)" would be a
function that returns an iterable (either an iterator or an object with
begin() and end()) that would yield start, start+step, start+step*2 and so
forth.

"template<typename... T1,typename... Tn> unspecified2_t zip(T&& x1,T&&...
xn)" would take one or more iterables and returns an iterable object that
yields a tuple that groups the values from the individual iterators, until
one of the iterables is exhausted.

This is typical of the way things are done in Python
<https://www.python.org>, which doesn't have the "for(init; check; step)"
form, and yet is very nice to work with.

--

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

<div dir=3D"ltr"><br>On Thursday, May 29, 2014 6:54:48 PM UTC-4, gmis...@gm=
ail.com wrote:<br><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>But we really need to get beyond the focus on the syntax&nbsp;whi=
le&nbsp;people are not showing&nbsp;example alternative code or libraries&n=
bsp;that demonstrably provides the same feature set I have mentioned, that =
we all know the original for loop provides.<br></div><div><br></div></div><=
/blockquote><div><br>You have repeatedly suggested the syntax is not import=
ant but I strongly disagree, because your proposal doesn't actually allow a=
nything new. The code:<br><br><div class=3D"prettyprint" style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">for</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">size_t =
i </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">const</span><span style=3D"color: #000;" 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;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
e </span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> v</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">++</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">i </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>&nbsp;do_something</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">i</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> e</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code>=
</div><div><br>appears to be equivalent to the currently legal:<br><br><div=
 class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-w=
rap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #000;" class=3D"styled-by-prettify">size_t i </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">for</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> e </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> v</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> do_something</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">++,</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> e</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v><br>or even if you couldn't use ++/-- because you need to increment by so=
mething other than one, it would just be:<br><br>size_t i =3D 0;<br>for (co=
nst auto&amp; e : v) {<br>&nbsp;&nbsp;&nbsp; do_something(i, e);<br>&nbsp;&=
nbsp;&nbsp; i +=3D 2;<br>}<br><br>You don't need any libraries or new langu=
age features to write code that does exactly the same thing, so your propos=
al is nothing more than syntax sugar, therefore the syntax is not only impo=
rtant, it seems to be the entire issue. If people don't like the syntax or =
think it's confusing, that <i>is</i> a problem, because programming is more=
 than writing code, it's also reading code. Even if the people that don't l=
ike it, don't use it, they will still be affected because they will inevita=
bly have to work with or maintain code written by people who do use it.<br>=
</div><br>&nbsp;</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><div>I&nbsp;don't quite see how tuple unpacking&nbsp; r=
elates to this, it may do, but that's exactly why example code is needed, t=
o demonstrate that part too.<br></div>...<br><div>Yes,&nbsp;but&nbsp;a sing=
le&nbsp;index isn't the only thing people track or do in their step and it =
doesn't have to be&nbsp;+ 1&nbsp;or even an increment at all. </div><div><b=
r></div></div></blockquote><div><br>Tuple unpacking would allow the same on=
e-line convenience if every sequence was turned into an iterable object, wh=
ich might look something like:<br><br><div class=3D"prettyprint" style=3D"b=
ackground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bord=
er-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"=
prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">for</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(&lt;</span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">e</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> zip</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">count</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span styl=
e=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #066;"=
 class=3D"styled-by-prettify">5</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">),</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> v</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">))</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> do=
_something</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-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> e</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span></div></code></div><br>The "<spa=
n style=3D"font-family: courier new,monospace;">&lt;type1 name1,type2 name2=
,...&gt; =3D x</span>" syntax would introduce <span style=3D"font-family: c=
ourier new,monospace;">name1</span>, <span style=3D"font-family: courier ne=
w,monospace;">name2</span> and etc into the the current scope and assign to=
 each <span style=3D"font-family: courier new,monospace;">std::get&lt;0&gt;=
(x)</span>, <span style=3D"font-family: courier new,monospace;">std::get&lt=
;1&gt;(x)</span> and etc (there isn't a consensus on the syntax, however).<=
br><br>"<span style=3D"font-family: courier new,monospace;">template&lt;typ=
ename T&gt; unspecified_t count(T start=3D0,T step=3D1)</span>" would be a =
function that returns an iterable (either an iterator or an object with <sp=
an style=3D"font-family: courier new,monospace;">begin()</span> and <span s=
tyle=3D"font-family: courier new,monospace;">end()</span>) that would yield=
 <span style=3D"font-family: courier new,monospace;">start</span>, <span st=
yle=3D"font-family: courier new,monospace;">start+step</span>, <span style=
=3D"font-family: courier new,monospace;">start+step*2</span> and so forth.<=
br><br>"<span style=3D"font-family: courier new,monospace;">template&lt;typ=
ename... T1,typename... Tn&gt; unspecified2_t zip(T&amp;&amp; x1,T&amp;&amp=
;... xn)</span>" would take one or more iterables and returns an iterable o=
bject that yields a tuple that groups the values from the individual iterat=
ors, until one of the iterables is exhausted.<br><br>This is typical of the=
 way things are done in <a href=3D"https://www.python.org">Python</a>, whic=
h doesn't have the "for(init; check; step)" form, and yet is very nice to w=
ork with.<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_83_1158815.1401414090403--

.

------=_Part_289_23846063.1401427567301
Content-Type: text/plain; charset=UTF-8


On Friday, May 30, 2014 1:41:30 PM UTC+12, rouslank...@gmail.com wrote:
>
>
> On Thursday, May 29, 2014 6:54:48 PM UTC-4, gmis...@gmail.com wrote:
>
>> But we really need to get beyond the focus on the syntax while people are
>> not showing example alternative code or libraries that demonstrably
>> provides the same feature set I have mentioned, that we all know the
>> original for loop provides.
>>
>>
> You have repeatedly suggested the syntax is not important but I strongly
> disagree, because your proposal doesn't actually allow anything new.
>

But I have never said that syntax isn't important and have never used those
words? Your characterization is completely untrue.

What I've argued is that syntax has been the main focus and at the expense
of talking about comparing real features and benefits, or code examples.
Without that, what is anyone comparing my proposal against and what is
there to refute or to agree with?

If the original for (e:c) syntax had been evaluated in such a light manner,
it would never have been introduced.

I even had someone comment I was forcing them to do something. When my
proposal forces nothing. So we need to be realistic here.


> The code:
>
> for (size_t i = 0; const auto& e : v; ++i )
>  do_something(i, e);
>
> appears to be equivalent to the currently legal
>
> size_t i = 0;
> for (const auto& e : v) do_something(i++, e);
>
>
But it's not equivalent. At least you have a real code example so we can
talk features now.  As I mentioned previously in this thread, the issue
with your example is that 'I' is pulled into a scope that we don't want.

Your loop just conveys the scope benefit onto  'e'  but why should 'I'
not gain the same benefit?
If you move the loop, you'll likely break it, with 'i' being wrong or
un-initialized.

And after the loop has finished, we're as done with 'i' as we are with
'e'. Yet  'i' lingers while 'e' does not. Why do we want that?


> or even if you couldn't use ++/-- because you need to increment by
> something other than one, it would just be:
>
> size_t i = 0;
> for (const auto& e : v) {
>     do_something(i, e);
>     i += 2;
> }
>

That example too suffers from something I've already mentioned.

size_t i = 0;
for (const auto& e : v) {
    do_something(i, e);
    if (don't_do_something_else())
        continue; // Woops, I+=2 not happening now. I forgot about that.
    something_else();
    i += 2;
}

With my loop, that wouldn't be a mistake as easily made and it's one line
less and clear from the outset:
for (size_t i = 0; const auto& e : v; I +=2)
    do_something(i, e);
    if (don't_do_something_else())
        continue; // Mistake avoided.
    something_else();
}


> You don't need any libraries or new language features to write code that
> does exactly the same thing, so your proposal is nothing more than syntax
> sugar, therefore the syntax is not only important, it seems to be the
> entire issue. If people don't like the syntax or think it's confusing, that
> *is* a problem, because programming is more than writing code, it's also
> reading code. Even if the people that don't like it, don't use it, they
> will still be affected because they will inevitably have to work with or
> maintain code written by people who do use it.
>

That analysis is premature and history has examples that refute your
case as much as make it. When the original for loop gained the ability to
put a declaration in it, you could already do this:
f()
{
    {
    int I;
    for ( I = 0; I < 10; ++I) doSomething(I)
    }
}

But that didn't stop people thinking this had more appeal and voting for it:
f()
{
    for ( int I = 0; I < 10; ++I) doSomething(I)
}

Did it? So you're analysis means nothing definitive.

I agree my proposal is no more than an attempt to give the new for loop the
features of the old for loop. That's not a bad thing, That's a virtue.

Nobody said it was new sliced bread. It's just an admission that the old
sliced bread had something going for it and that the people who voted the
old loop's feature set might still value those same features in the new
loop. You trail the idea and you see and you give people a while to take it
all in. Heck, I might drop the idea once I see what my options are.
Trailing this stuff flushes those ideas and options out.

But until we see all the alternatives compared in full with real examples,
we don't know. If someone comes up with an even better idea than this, I'll
be happy and I'll still have played my part in flushing those ideas out.


>
>
>
>> I don't quite see how tuple unpacking  relates to this, it may do, but
>> that's exactly why example code is needed, to demonstrate that part too.
>> ...
>> Yes, but a single index isn't the only thing people track or do in their
>> step and it doesn't have to be + 1 or even an increment at all.
>>
>>
> Tuple unpacking would allow the same one-line convenience if every
> sequence was turned into an iterable object, which might look something
> like:
>
> for(<int i,const auto &e> = zip(count(0,5), v)) do_something(i, e);
>

I don't know if that = should be a : or what. But my proposal doesn't
change what's possible here. Where's the problem?

And like pair<int,int>(x,y) was never going to be Point(x,y), tuples suffer
from the same problem so tuples don't impress me much, as the song goes.


>
>
> The "<type1 name1,type2 name2,...> = x" syntax would introduce name1,
> name2 and etc into the the current scope and assign to each std::get<0>(x),
> std::get<1>(x) and etc (there isn't a consensus on the syntax, however).
>
> "template<typename T> unspecified_t count(T start=0,T step=1)" would be a
> function that returns an iterable (either an iterator or an object with
> begin() and end()) that would yield start, start+step, start+step*2 and
> so forth.
>
> "template<typename... T1,typename... Tn> unspecified2_t zip(T&& x1,T&&...
> xn)" would take one or more iterables and returns an iterable object that
> yields a tuple that groups the values from the individual iterators, until
> one of the iterables is exhausted.
>
> This is typical of the way things are done in Python
> <https://www.python.org>, which doesn't have the "for(init; check; step)"
> form, and yet is very nice to work with.
>


I'm waiting to be impressed by the power of tuples. I've never seen a tuple
well used yet. It usually lasts for about a week and then needs to be
replaced with a real type. Lambda's often suffer from the same problem but
they give me a whole lot more to make up for it and are right at least 50%
of the time.

But I don't see how my proposal here detracts from someone who wants to use
a tuple regardless, it only augments what's possible. So I don't see a
problem still.

Thanks

--

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

<div dir=3D"ltr"><br>On Friday, May 30, 2014 1:41:30 PM UTC+12, rouslank...=
@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><br>On Thurs=
day, May 29, 2014 6:54:48 PM UTC-4, <a>gmis...@gmail.com</a> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-l=
eft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bo=
rder-left-style: solid;"><div dir=3D"ltr"><div>But we really need to get be=
yond the focus on the syntax&nbsp;while&nbsp;people are not showing&nbsp;ex=
ample alternative code or libraries&nbsp;that demonstrably provides the sam=
e feature set I have mentioned, that we all know the original for loop prov=
ides.<br></div><div><br></div></div></blockquote><div><br>You have repeated=
ly suggested the syntax is not important but I strongly disagree, because y=
our proposal doesn't actually allow anything new.</div></div></blockquote><=
div><br></div><div>But I have never said that syntax isn't&nbsp;important a=
nd have never used those words? Your characterization is completely untrue.=
</div><div><br></div><div>What I've argued is that syntax has been the main=
&nbsp;focus&nbsp;and at the expense of talking about comparing real feature=
s and benefits,&nbsp;or&nbsp;code examples. Without that, what is anyone&nb=
sp;comparing my proposal against and what is there to refute or to agree wi=
th?</div><div><br></div><div>If the original for (e:c) syntax&nbsp;had been=
 evaluated in such a light manner, it would never have been introduced.</di=
v><div><br></div><div>I even had someone comment I was forcing them to do s=
omething. When my proposal forces nothing. So we need to be realistic here.=
</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204);=
 border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div> =
The code:<br><br><div style=3D"border: 1px solid rgb(187, 187, 187); border=
-image: none; -ms-word-wrap: break-word; background-color: rgb(250, 250, 25=
0);"><code><div><span style=3D"color: rgb(0, 0, 136);">for</span><span styl=
e=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 102, 0);"=
>(</span><span style=3D"color: rgb(0, 0, 0);">size_t i </span><span style=
=3D"color: rgb(102, 102, 0);">=3D</span><span style=3D"color: rgb(0, 0, 0);=
"> </span><span style=3D"color: rgb(0, 102, 102);">0</span><span style=3D"c=
olor: rgb(102, 102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);"> </sp=
an><span style=3D"color: rgb(0, 0, 136);">const</span><span style=3D"color:=
 rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">auto</span><=
span style=3D"color: rgb(102, 102, 0);">&amp;</span><span style=3D"color: r=
gb(0, 0, 0);"> e </span><span style=3D"color: rgb(102, 102, 0);">:</span><s=
pan style=3D"color: rgb(0, 0, 0);"> v</span><span style=3D"color: rgb(102, =
102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=
=3D"color: rgb(102, 102, 0);">++</span><span style=3D"color: rgb(0, 0, 0);"=
>i </span><span style=3D"color: rgb(102, 102, 0);">)</span><span style=3D"c=
olor: rgb(0, 0, 0);"><br>&nbsp;do_something</span><span style=3D"color: rgb=
(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 0);">i</span><span =
style=3D"color: rgb(102, 102, 0);">,</span><span style=3D"color: rgb(0, 0, =
0);"> e</span><span style=3D"color: rgb(102, 102, 0);">);</span><span style=
=3D"color: rgb(0, 0, 0);"><br></span></div></code></div><div><br>appears to=
 be equivalent to the currently legal<br><br><div style=3D"border: 1px soli=
d rgb(187, 187, 187); border-image: none; -ms-word-wrap: break-word; backgr=
ound-color: rgb(250, 250, 250);"><code><div><span style=3D"color: rgb(0, 0,=
 0);">size_t i </span><span style=3D"color: rgb(102, 102, 0);">=3D</span><s=
pan style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 102=
, 102);">0</span><span style=3D"color: rgb(102, 102, 0);">;</span><span sty=
le=3D"color: rgb(0, 0, 0);"><br></span><span style=3D"color: rgb(0, 0, 136)=
;">for</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"co=
lor: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 136);">cons=
t</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: =
rgb(0, 0, 136);">auto</span><span style=3D"color: rgb(102, 102, 0);">&amp;<=
/span><span style=3D"color: rgb(0, 0, 0);"> e </span><span style=3D"color: =
rgb(102, 102, 0);">:</span><span style=3D"color: rgb(0, 0, 0);"> v</span><s=
pan style=3D"color: rgb(102, 102, 0);">)</span><span style=3D"color: rgb(0,=
 0, 0);"> do_something</span><span style=3D"color: rgb(102, 102, 0);">(</sp=
an><span style=3D"color: rgb(0, 0, 0);">i</span><span style=3D"color: rgb(1=
02, 102, 0);">++,</span><span style=3D"color: rgb(0, 0, 0);"> e</span><span=
 style=3D"color: rgb(102, 102, 0);">);</span><span style=3D"color: rgb(0, 0=
, 0);"><br></span></div></code></div><br></div></div></div></blockquote><di=
v><br></div><div>But it's not equivalent.&nbsp;At least&nbsp;you have&nbsp;=
a real code example&nbsp;so we can talk features now.&nbsp; As&nbsp;I&nbsp;=
mentioned previously in this thread, the&nbsp;issue with your example is th=
at 'I' is&nbsp;pulled into a scope that we don't want.</div><div><br></div>=
<div>Your loop&nbsp;just conveys the&nbsp;scope benefit onto &nbsp;'e'&nbsp=
;&nbsp;but why&nbsp;should 'I' not&nbsp;gain the same benefit?</div><div>If=
 you move the loop, you'll&nbsp;likely break it, with 'i' being wrong or un=
-initialized.</div><div><br></div><div>And after the loop has finished, we'=
re as done with 'i' as we are with 'e'.&nbsp;Yet &nbsp;'i' lingers&nbsp;whi=
le&nbsp;'e' does not. Why do we want that?</div><div>&nbsp;</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1=
ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-l=
eft-style: solid;"><div dir=3D"ltr"><div><div>or even if you couldn't use +=
+/-- because you need to increment by something other than one, it would ju=
st be:<br><br>size_t i =3D 0;<br>for (const auto&amp; e : v) {<br>&nbsp;&nb=
sp;&nbsp; do_something(i, e);<br>&nbsp;&nbsp;&nbsp; i +=3D 2;<br>}<br></div=
></div></div></blockquote><div><br></div><div>That example too suffers from=
 something I've already mentioned.</div><div><br></div><div>size_t i =3D 0;=
<br>for (const auto&amp; e : v) {<br>&nbsp;&nbsp;&nbsp; do_something(i, e);=
</div><div>&nbsp;&nbsp;&nbsp; if (don't_do_something_else())</div><div>&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; continue; // Woops, I+=3D2 not happe=
ning now. I forgot about that.</div><div>&nbsp;&nbsp;&nbsp; something_else(=
);<br>&nbsp;&nbsp;&nbsp; i +=3D 2;<br>}</div><div><br></div><div>With my lo=
op, that wouldn't be a mistake as easily made and it's one line less and cl=
ear from the outset:</div><div><div>for (size_t i =3D 0;&nbsp;const auto&am=
p; e : v; I +=3D2)<br>&nbsp;&nbsp;&nbsp; do_something(i, e);</div><div>&nbs=
p;&nbsp;&nbsp; if (don't_do_something_else())</div><div>&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp; continue; //&nbsp;Mistake avoided.</div><div>&nbsp;=
&nbsp;&nbsp; something_else();<br>}</div><div><br></div></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex;=
 border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left=
-style: solid;"><div dir=3D"ltr"><div><div><br>You don't need any libraries=
 or new language features to write code that does exactly the same thing, s=
o your proposal is nothing more than syntax sugar, therefore the syntax is =
not only important, it seems to be the entire issue. If people don't like t=
he syntax or think it's confusing, that <i>is</i> a problem,&nbsp;because p=
rogramming is more than writing code, it's also reading code. Even if the p=
eople that don't like it, don't use it, they will still be affected because=
 they will inevitably have to work with or maintain code written by people =
who do use it.<br></div></div></div></blockquote><div><br></div><div>That a=
nalysis is premature and history has examples that refute&nbsp;your case&nb=
sp;as much as make it. When the original for loop gained the ability to put=
 a declaration in it, you could already do this:</div><div>f()</div><div>{<=
/div><div>&nbsp;&nbsp;&nbsp; {</div><div>&nbsp;&nbsp;&nbsp; int I;</div><di=
v>&nbsp;&nbsp;&nbsp; for ( I =3D 0; I &lt; 10; ++I) doSomething(I)</div><di=
v>&nbsp;&nbsp;&nbsp; }</div><div>}</div><div><br></div><div>But that didn't=
 stop people thinking this had more appeal and voting for it:</div><div><di=
v>f()</div><div>{</div><div>&nbsp;&nbsp;&nbsp; for ( int I =3D 0; I &lt; 10=
; ++I) doSomething(I)</div><div>}</div><div><br></div><div>Did it? So you'r=
e analysis means nothing definitive.</div><div><br></div></div><div>I agree=
 my&nbsp;proposal is no more than an attempt to give the new for loop the f=
eatures of the old for loop.&nbsp;That's not a bad thing, That's&nbsp;a vir=
tue.</div><div><br></div><div>Nobody said it was&nbsp;new sliced bread. It'=
s just an&nbsp;admission that the old sliced bread had something going for =
it and that the people who voted&nbsp;the old loop's&nbsp;feature set&nbsp;=
might still value those same features in the new loop. You trail the idea a=
nd you see and you give people a while to take it all in. Heck, I might dro=
p the idea once I see what my options are. Trailing this stuff flushes thos=
e ideas and options out.</div><div><br></div><div>But until we see all the =
alternatives compared in full with real examples, we don't know. If&nbsp;so=
meone&nbsp;comes up with an even better idea than this, I'll be happy and I=
'll still have played my part in flushing those ideas out.</div><div>&nbsp;=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
 padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-widt=
h: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div></div><br>&nb=
sp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8=
ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-w=
idth: 1px; border-left-style: solid;"><div dir=3D"ltr"><div></div><div>I&nb=
sp;don't quite see how tuple unpacking&nbsp; relates to this, it may do, bu=
t that's exactly why example code is needed, to demonstrate that part too.<=
br></div>...<br><div>Yes,&nbsp;but&nbsp;a single&nbsp;index isn't the only =
thing people track or do in their step and it doesn't have to be&nbsp;+ 1&n=
bsp;or even an increment at all. </div><div><br></div></div></blockquote><d=
iv><br>Tuple unpacking would allow the same one-line convenience if every s=
equence was turned into an iterable object, which might look something like=
:<br><br><div style=3D"border: 1px solid rgb(187, 187, 187); border-image: =
none; -ms-word-wrap: break-word; background-color: rgb(250, 250, 250);"><co=
de><div><span style=3D"color: rgb(0, 0, 136);">for</span><span style=3D"col=
or: rgb(102, 102, 0);">(&lt;</span><span style=3D"color: rgb(0, 0, 136);">i=
nt</span><span style=3D"color: rgb(0, 0, 0);"> i</span><span style=3D"color=
: rgb(102, 102, 0);">,</span><span style=3D"color: rgb(0, 0, 136);">const</=
span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb=
(0, 0, 136);">auto</span><span style=3D"color: rgb(0, 0, 0);"> </span><span=
 style=3D"color: rgb(102, 102, 0);">&amp;</span><span style=3D"color: rgb(0=
, 0, 0);">e</span><span style=3D"color: rgb(102, 102, 0);">&gt;</span><span=
 style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 102,=
 0);">=3D</span><span style=3D"color: rgb(0, 0, 0);"> zip</span><span style=
=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 0);">=
count</span><span style=3D"color: rgb(102, 102, 0);">(</span><span style=3D=
"color: rgb(0, 102, 102);">0</span><span style=3D"color: rgb(102, 102, 0);"=
>,</span><span style=3D"color: rgb(0, 102, 102);">5</span><span style=3D"co=
lor: rgb(102, 102, 0);">),</span><span style=3D"color: rgb(0, 0, 0);"> v</s=
pan><span style=3D"color: rgb(102, 102, 0);">))</span><span style=3D"color:=
 rgb(0, 0, 0);"> do_something</span><span style=3D"color: rgb(102, 102, 0);=
">(</span><span style=3D"color: rgb(0, 0, 0);">i</span><span style=3D"color=
: rgb(102, 102, 0);">,</span><span style=3D"color: rgb(0, 0, 0);"> e</span>=
<span style=3D"color: rgb(102, 102, 0);">);</span></div></code></div></div>=
</div></blockquote><div><br></div><div>I don't know if that =3D should be a=
 : or what. But my proposal doesn't change what's possible here. Where's th=
e problem?</div><div><div><br></div><div>And like pair&lt;int,int&gt;(x,y) =
was never going to&nbsp;be&nbsp;Point(x,y), tuples suffer from the same pro=
blem so tuples don't impress me much, as the song goes.</div></div><div>&nb=
sp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8=
ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-w=
idth: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div style=3D"b=
order: 1px solid rgb(187, 187, 187); border-image: none; -ms-word-wrap: bre=
ak-word; background-color: rgb(250, 250, 250);"><code><div><span style=3D"c=
olor: rgb(0, 0, 0);"><br></span></div></code></div><br>The "<span style=3D"=
font-family: courier new,monospace;">&lt;type1 name1,type2 name2,...&gt; =
=3D x</span>" syntax would introduce <span style=3D"font-family: courier ne=
w,monospace;">name1</span>, <span style=3D"font-family: courier new,monospa=
ce;">name2</span> and etc into the the current scope and assign to each <sp=
an style=3D"font-family: courier new,monospace;">std::get&lt;0&gt;(x)</span=
>, <span style=3D"font-family: courier new,monospace;">std::get&lt;1&gt;(x)=
</span> and etc (there isn't a consensus on the syntax, however).<br><br>"<=
span style=3D"font-family: courier new,monospace;">template&lt;typename T&g=
t; unspecified_t count(T start=3D0,T step=3D1)</span>" would be a function =
that returns an iterable (either an iterator or an object with <span style=
=3D"font-family: courier new,monospace;">begin()</span> and <span style=3D"=
font-family: courier new,monospace;">end()</span>) that would yield <span s=
tyle=3D"font-family: courier new,monospace;">start</span>, <span style=3D"f=
ont-family: courier new,monospace;">start+step</span>, <span style=3D"font-=
family: courier new,monospace;">start+step*2</span> and so forth.<br><br>"<=
span style=3D"font-family: courier new,monospace;">template&lt;typename... =
T1,typename... Tn&gt; unspecified2_t zip(T&amp;&amp; x1,T&amp;&amp;... xn)<=
/span>" would take one or more iterables and returns an iterable object tha=
t yields a tuple that groups the values from the individual iterators, unti=
l one of the iterables is exhausted.<br><br>This is typical of the way thin=
gs are done in <a onmousedown=3D"this.href=3D'https://www.google.com/url?q\=
75https%3A%2F%2Fwww.python.org\46sa\75D\46sntz\0751\46usg\75AFQjCNGd1GegLcC=
PHlZIZmhj6N--mEMqEA';return true;" onclick=3D"this.href=3D'https://www.goog=
le.com/url?q\75https%3A%2F%2Fwww.python.org\46sa\75D\46sntz\0751\46usg\75AF=
QjCNGd1GegLcCPHlZIZmhj6N--mEMqEA';return true;" href=3D"https://www.python.=
org" target=3D"_blank">Python</a>, which doesn't have the "for(init; check;=
 step)" form, and yet is very nice to work with.<br></div></div></blockquot=
e><div><br></div><div><br></div><div>I'm waiting to be impressed by the pow=
er of tuples. I've never seen a tuple well used yet. It usually lasts for a=
bout a week and then needs to be replaced with a real type. Lambda's often =
suffer from the same problem but they give me a whole lot more to make up f=
or it and are right at least 50% of the time.</div><div><br></div><div>But =
I don't&nbsp;see how my proposal here detracts from&nbsp;someone who wants =
to use a tuple regardless, it only augments what's possible. So I don't see=
 a problem still.</div><div><br></div><div>Thanks</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_289_23846063.1401427567301--

.

------=_Part_195_15442793.1401432029197
Content-Type: text/plain; charset=UTF-8


On Friday, May 30, 2014 1:26:07 AM UTC-4, gmis...@gmail.com wrote:
>
>
> On Friday, May 30, 2014 1:41:30 PM UTC+12, rouslank...@gmail.com wrote:
>>
>>
>> On Thursday, May 29, 2014 6:54:48 PM UTC-4, gmis...@gmail.com wrote:
>>
>>> But we really need to get beyond the focus on the syntax while people
>>> are not showing example alternative code or libraries that demonstrably
>>> provides the same feature set I have mentioned, that we all know the
>>> original for loop provides.
>>>
>>>
>> You have repeatedly suggested the syntax is not important but I strongly
>> disagree, because your proposal doesn't actually allow anything new.
>>
>
> But I have never said that syntax isn't important and have never used
> those words? Your characterization is completely untrue.
>
>
I said you suggested *the* syntax is not important, i.e. the particular
syntax in your proposal, not the general concept of syntax. I may have
misunderstood, but that's the impression I got.

What I've argued is that syntax has been the main focus and at the expense
> of talking about comparing real features and benefits, or code examples.
> Without that, what is anyone comparing my proposal against and what is
> there to refute or to agree with?
> ...
>
The code:
>>
>> for (size_t i = 0; const auto& e : v; ++i )
>>  do_something(i, e);
>>
>> appears to be equivalent to the currently legal
>>
>> size_t i = 0;
>> for (const auto& e : v) do_something(i++, e);
>>
>>
> But it's not equivalent. At least you have a real code example so we can
> talk features now.  As I mentioned previously in this thread, the issue
> with your example is that 'I' is pulled into a scope that we don't want.
>
> Your loop just conveys the scope benefit onto  'e'  but why should 'I'
> not gain the same benefit?
> If you move the loop, you'll likely break it, with 'i' being wrong or
> un-initialized.
>
> And after the loop has finished, we're as done with 'i' as we are with
> 'e'. Yet  'i' lingers while 'e' does not. Why do we want that?
>
>

{
    size_t i = 0;
    for (const auto& e : v) do_something(i++, e);
}

problem solved.

I'm not sure why you didn't see this coming since you even mentioned:

.... When the original for loop gained the ability to put a declaration in
> it, you could already do this:
> f()
> {
>     {
>     int I;
>     for ( I = 0; I < 10; ++I) doSomething(I)
>     }
> }
>

Anyway...


> size_t i = 0;
> for (const auto& e : v) {
>     do_something(i, e);
>     if (don't_do_something_else())
>         continue; // Woops, I+=2 not happening now. I forgot about that.
>     something_else();
>     i += 2;
> }
>
> With my loop, that wouldn't be a mistake as easily made and it's one line
> less and clear from the outset:
> for (size_t i = 0; const auto& e : v; I +=2)
>     do_something(i, e);
>     if (don't_do_something_else())
>         continue; // Mistake avoided.
>     something_else();
> }
>

Same with the tuple unpacking version. Do we need both?


>
>> You don't need any libraries or new language features to write code that
>> does exactly the same thing, so your proposal is nothing more than syntax
>> sugar, therefore the syntax is not only important, it seems to be the
>> entire issue. If people don't like the syntax or think it's confusing, that
>> *is* a problem, because programming is more than writing code, it's also
>> reading code. Even if the people that don't like it, don't use it, they
>> will still be affected because they will inevitably have to work with or
>> maintain code written by people who do use it.
>>
>
> That analysis is premature and history has examples that refute your
> case as much as make it. When the original for loop gained the ability to
> put a declaration in it, you could already do this:
> f()
> {
>     {
>     int I;
>     for ( I = 0; I < 10; ++I) doSomething(I)
>     }
> }
>
> But that didn't stop people thinking this had more appeal and voting for
> it:
> f()
> {
>     for ( int I = 0; I < 10; ++I) doSomething(I)
> }
>
> Did it? So you're analysis means nothing definitive.
>

But my point was that people *don't* seem to think your proposal has more
appeal.


Tuple unpacking would allow the same one-line convenience if every sequence
>> was turned into an iterable object, which might look something like:
>>
>> for(<int i,const auto &e> = zip(count(0,5), v)) do_something(i, e);
>>
>
> I don't know if that = should be a : or what. But my proposal doesn't
> change what's possible here. Where's the problem?
> ...
>
And like pair<int,int>(x,y) was never going to be Point(x,y), tuples suffer
> from the same problem so tuples don't impress me much, as the song goes.
> ...
> I'm waiting to be impressed by the power of tuples. I've never seen a
> tuple well used yet. It usually lasts for about a week and then needs to be
> replaced with a real type. Lambda's often suffer from the same problem but
> they give me a whole lot more to make up for it and are right at least 50%
> of the time.
>
> But I don't see how my proposal here detracts from someone who wants to
> use a tuple regardless, it only augments what's possible. So I don't see a
> problem still.
>
>
Yes, that should have been ":" (and I botched the declaration of zip in the
second last line even worse). Anyway, this is supposed to be a solution,
not a problem. I don't think you fully understood what that code would do.
It would be equivalent to:

{
  auto i_itr = count(0,5);
  for(auto e_itr = v.begin(); e_itr != v.end(); ++i_itr, ++e_itr) {
        int i = *i_itr;
        const auto &e = *e_itr;

        do_something(i,e);
    }
}

The whole point of tuple unpacking is to *not* deal with tuples. It lets
you call a function that returns multiple values and assign them to
multiple variables in a single line. If you could do that, then you
wouldn't need special syntax for extra initialization and step elements
because you could just pack multiple iterables into one and unpack the
values into seperate variables in one line of code.

--

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

<div dir=3D"ltr"><br>On Friday, May 30, 2014 1:26:07 AM UTC-4, gmis...@gmai=
l.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
br>On Friday, May 30, 2014 1:41:30 PM UTC+12, <a>rouslank...@gmail.com</a> =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;p=
adding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bo=
rder-left-style:solid"><div dir=3D"ltr"><br>On Thursday, May 29, 2014 6:54:=
48 PM UTC-4, <a>gmis...@gmail.com</a> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color=
:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=
=3D"ltr"><div>But we really need to get beyond the focus on the syntax&nbsp=
;while&nbsp;people are not showing&nbsp;example alternative code or librari=
es&nbsp;that demonstrably provides the same feature set I have mentioned, t=
hat we all know the original for loop provides.<br></div><div><br></div></d=
iv></blockquote><div><br>You have repeatedly suggested the syntax is not im=
portant but I strongly disagree, because your proposal doesn't actually all=
ow anything new.</div></div></blockquote><div><br></div><div>But I have nev=
er said that syntax isn't&nbsp;important and have never used those words? Y=
our characterization is completely untrue.</div><div><br></div></div></bloc=
kquote><div><br>I said you suggested <b>the</b> syntax is not important, i.=
e. the particular syntax in your proposal, not the general concept of synta=
x. I may have misunderstood, but that's the impression I got.<br><br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><d=
iv>What I've argued is that syntax has been the main&nbsp;focus&nbsp;and at=
 the expense of talking about comparing real features and benefits,&nbsp;or=
&nbsp;code examples. Without that, what is anyone&nbsp;comparing my proposa=
l against and what is there to refute or to agree with?</div><div>... <br><=
/div></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1=
px;border-left-style:solid"><div dir=3D"ltr"><div> The code:<br><br><div st=
yle=3D"border:1px solid rgb(187,187,187);background-color:rgb(250,250,250)"=
><code><div><span style=3D"color:rgb(0,0,136)">for</span><span style=3D"col=
or:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">(</span><span s=
tyle=3D"color:rgb(0,0,0)">size_t i </span><span style=3D"color:rgb(102,102,=
0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color=
:rgb(0,102,102)">0</span><span style=3D"color:rgb(102,102,0)">;</span><span=
 style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0,0,136)">cons=
t</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(0=
,0,136)">auto</span><span style=3D"color:rgb(102,102,0)">&amp;</span><span =
style=3D"color:rgb(0,0,0)"> e </span><span style=3D"color:rgb(102,102,0)">:=
</span><span style=3D"color:rgb(0,0,0)"> v</span><span style=3D"color:rgb(1=
02,102,0)">;</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"=
color:rgb(102,102,0)">++</span><span style=3D"color:rgb(0,0,0)">i </span><s=
pan style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"=
><br>&nbsp;do_something</span><span style=3D"color:rgb(102,102,0)">(</span>=
<span style=3D"color:rgb(0,0,0)">i</span><span style=3D"color:rgb(102,102,0=
)">,</span><span style=3D"color:rgb(0,0,0)"> e</span><span style=3D"color:r=
gb(102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"><br></span></div><=
/code></div><div><br>appears to be equivalent to the currently legal<br><br=
><div style=3D"border:1px solid rgb(187,187,187);background-color:rgb(250,2=
50,250)"><code><div><span style=3D"color:rgb(0,0,0)">size_t i </span><span =
style=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> =
</span><span style=3D"color:rgb(0,102,102)">0</span><span style=3D"color:rg=
b(102,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br></span><span sty=
le=3D"color:rgb(0,0,136)">for</span><span style=3D"color:rgb(0,0,0)"> </spa=
n><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0=
,136)">const</span><span style=3D"color:rgb(0,0,0)"> </span><span style=3D"=
color:rgb(0,0,136)">auto</span><span style=3D"color:rgb(102,102,0)">&amp;</=
span><span style=3D"color:rgb(0,0,0)"> e </span><span style=3D"color:rgb(10=
2,102,0)">:</span><span style=3D"color:rgb(0,0,0)"> v</span><span style=3D"=
color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> do_somethin=
g</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:r=
gb(0,0,0)">i</span><span style=3D"color:rgb(102,102,0)">++,</span><span sty=
le=3D"color:rgb(0,0,0)"> e</span><span style=3D"color:rgb(102,102,0)">);</s=
pan><span style=3D"color:rgb(0,0,0)"><br></span></div></code></div><br></di=
v></div></div></blockquote><div><br></div><div>But it's not equivalent.&nbs=
p;At least&nbsp;you have&nbsp;a real code example&nbsp;so we can talk featu=
res now.&nbsp; As&nbsp;I&nbsp;mentioned previously in this thread, the&nbsp=
;issue with your example is that 'I' is&nbsp;pulled into a scope that we do=
n't want.</div><div><br></div><div>Your loop&nbsp;just conveys the&nbsp;sco=
pe benefit onto &nbsp;'e'&nbsp;&nbsp;but why&nbsp;should 'I' not&nbsp;gain =
the same benefit?</div><div>If you move the loop, you'll&nbsp;likely break =
it, with 'i' being wrong or un-initialized.</div><div><br></div><div>And af=
ter the loop has finished, we're as done with 'i' as we are with 'e'.&nbsp;=
Yet &nbsp;'i' lingers&nbsp;while&nbsp;'e' does not. Why do we want that?</d=
iv><div>&nbsp;</div></div></blockquote><div><br><div style=3D"border:1px so=
lid rgb(187,187,187);background-color:rgb(250,250,250)"><code><div><span st=
yle=3D"color:rgb(0,0,0)">{<br>&nbsp;&nbsp;&nbsp; size_t i </span><span styl=
e=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </sp=
an><span style=3D"color:rgb(0,102,102)">0</span><span style=3D"color:rgb(10=
2,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=
=3D"color:rgb(0,0,136)">&nbsp;&nbsp;&nbsp; for</span><span style=3D"color:r=
gb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">(</span><span style=
=3D"color:rgb(0,0,136)">const</span><span style=3D"color:rgb(0,0,0)"> </spa=
n><span style=3D"color:rgb(0,0,136)">auto</span><span style=3D"color:rgb(10=
2,102,0)">&amp;</span><span style=3D"color:rgb(0,0,0)"> e </span><span styl=
e=3D"color:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"> v</spa=
n><span style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0=
,0)"> do_something</span><span style=3D"color:rgb(102,102,0)">(</span><span=
 style=3D"color:rgb(0,0,0)">i</span><span style=3D"color:rgb(102,102,0)">++=
,</span><span style=3D"color:rgb(0,0,0)"> e</span><span style=3D"color:rgb(=
102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"><br>}<br></span></div=
></code></div><br>problem solved.<br><br>I'm not sure why you didn't see th=
is coming since you even mentioned:<br><br><blockquote style=3D"margin: 0px=
 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1e=
x;" class=3D"gmail_quote"><div>... When the original for loop gained=20
the ability to put a declaration in it, you could already do this:</div><di=
v>f()</div><div>{</div><div>&nbsp;&nbsp;&nbsp; {</div><div>&nbsp;&nbsp;&nbs=
p; int I;</div><div>&nbsp;&nbsp;&nbsp; for ( I =3D 0; I &lt; 10; ++I) doSom=
ething(I)</div><div>&nbsp;&nbsp;&nbsp; }</div><div>}</div></blockquote>&nbs=
p;<br>Anyway...<br>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div></div><div>size_t i =3D 0;<br>for (const auto&amp; e=
 : v) {<br>&nbsp;&nbsp;&nbsp; do_something(i, e);</div><div>&nbsp;&nbsp;&nb=
sp; if (don't_do_something_else())</div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; continue; // Woops, I+=3D2 not happening now. I forgot about t=
hat.</div><div>&nbsp;&nbsp;&nbsp; something_else();<br>&nbsp;&nbsp;&nbsp; i=
 +=3D 2;<br>}</div><div><br></div><div>With my loop, that wouldn't be a mis=
take as easily made and it's one line less and clear from the outset:</div>=
<div><div>for (size_t i =3D 0;&nbsp;const auto&amp; e : v; I +=3D2)<br>&nbs=
p;&nbsp;&nbsp; do_something(i, e);</div><div>&nbsp;&nbsp;&nbsp; if (don't_d=
o_something_else())</div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; co=
ntinue; //&nbsp;Mistake avoided.</div><div>&nbsp;&nbsp;&nbsp; something_els=
e();<br>}</div></div></div></blockquote><div><br>Same with the tuple unpack=
ing version. Do we need both?<br>&nbsp;</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204=
);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div><div=
><br>You don't need any libraries or new language features to write code th=
at does exactly the same thing, so your proposal is nothing more than synta=
x sugar, therefore the syntax is not only important, it seems to be the ent=
ire issue. If people don't like the syntax or think it's confusing, that <i=
>is</i> a problem,&nbsp;because programming is more than writing code, it's=
 also reading code. Even if the people that don't like it, don't use it, th=
ey will still be affected because they will inevitably have to work with or=
 maintain code written by people who do use it.<br></div></div></div></bloc=
kquote><div><br></div><div>That analysis is premature and history has examp=
les that refute&nbsp;your case&nbsp;as much as make it. When the original f=
or loop gained the ability to put a declaration in it, you could already do=
 this:</div><div>f()</div><div>{</div><div>&nbsp;&nbsp;&nbsp; {</div><div>&=
nbsp;&nbsp;&nbsp; int I;</div><div>&nbsp;&nbsp;&nbsp; for ( I =3D 0; I &lt;=
 10; ++I) doSomething(I)</div><div>&nbsp;&nbsp;&nbsp; }</div><div>}</div><d=
iv><br></div><div>But that didn't stop people thinking this had more appeal=
 and voting for it:</div><div><div>f()</div><div>{</div><div>&nbsp;&nbsp;&n=
bsp; for ( int I =3D 0; I &lt; 10; ++I) doSomething(I)</div><div>}</div><di=
v><br></div><div>Did it? So you're analysis means nothing definitive.</div>=
</div></div></blockquote><div><br>But my point was that people <i>don't</i>=
 seem to think your proposal has more appeal.<br></div><div>&nbsp;<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1e=
x;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-styl=
e:solid"><div dir=3D"ltr">Tuple unpacking would allow the same one-line con=
venience if every sequence was turned into an iterable object, which might =
look something like:<br><div><br><div style=3D"border:1px solid rgb(187,187=
,187);background-color:rgb(250,250,250)"><code><div><span style=3D"color:rg=
b(0,0,136)">for</span><span style=3D"color:rgb(102,102,0)">(&lt;</span><spa=
n style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(0,0,0)"> =
i</span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"color:r=
gb(0,0,136)">const</span><span style=3D"color:rgb(0,0,0)"> </span><span sty=
le=3D"color:rgb(0,0,136)">auto</span><span style=3D"color:rgb(0,0,0)"> </sp=
an><span style=3D"color:rgb(102,102,0)">&amp;</span><span style=3D"color:rg=
b(0,0,0)">e</span><span style=3D"color:rgb(102,102,0)">&gt;</span><span sty=
le=3D"color:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">=3D</s=
pan><span style=3D"color:rgb(0,0,0)"> zip</span><span style=3D"color:rgb(10=
2,102,0)">(</span><span style=3D"color:rgb(0,0,0)">count</span><span style=
=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,102,102)">0</s=
pan><span style=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0=
,102,102)">5</span><span style=3D"color:rgb(102,102,0)">),</span><span styl=
e=3D"color:rgb(0,0,0)"> v</span><span style=3D"color:rgb(102,102,0)">))</sp=
an><span style=3D"color:rgb(0,0,0)"> do_something</span><span style=3D"colo=
r:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">i</span><span st=
yle=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> e</s=
pan><span style=3D"color:rgb(102,102,0)">);</span></div></code></div></div>=
</div></blockquote><div><br></div><div>I don't know if that =3D should be a=
 : or what. But my proposal doesn't change what's possible here. Where's th=
e problem?</div><div><div>...<br></div></div></div></blockquote><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div></div><div>And=
 like pair&lt;int,int&gt;(x,y) was never going to&nbsp;be&nbsp;Point(x,y), =
tuples suffer from the same problem so tuples don't impress me much, as the=
 song goes.</div></div><div>...<br></div><div>I'm waiting to be impressed b=
y the power of tuples. I've never seen a tuple well used yet. It usually la=
sts for about a week and then needs to be replaced with a real type. Lambda=
's often suffer from the same problem but they give me a whole lot more to =
make up for it and are right at least 50% of the time.</div><div><br></div>=
<div>But I don't&nbsp;see how my proposal here detracts from&nbsp;someone w=
ho wants to use a tuple regardless, it only augments what's possible. So I =
don't see a problem still.</div><div><br></div></div></blockquote><div><br>=
Yes, that should have been ":" (and I botched the declaration of zip in the=
 second last line even worse). Anyway, this is supposed to be a solution, n=
ot a problem. I don't think you fully understood what that code would do. I=
t would be equivalent to:<br><div class=3D"prettyprint" style=3D"background=
-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style:=
 solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypri=
nt"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i_=
itr </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> count</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #066;=
" class=3D"styled-by-prettify">5</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>&nbsp; </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">for</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> e_it=
r </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> v</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"=
color: #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"> e_itr </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">!=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> v</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">.</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">end</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 s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">i_itr</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">e_itr</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; =
&nbsp; &nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> i </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">i_itr</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">e </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">e_itr</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br><br>&nbsp; &nbsp; &nbs=
p; &nbsp; do_something</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">e</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span></div></code></div><br>The whole poin=
t of tuple unpacking is to <i>not</i> deal with tuples. It lets you call a =
function that returns multiple values and assign them to multiple variables=
 in a single line. If you could do that, then you wouldn't need special syn=
tax for extra initialization and step elements because you could just pack =
multiple iterables into one and unpack the values into seperate variables i=
n one line of code.<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_195_15442793.1401432029197--

.

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

Le vendredi 30 mai 2014 00:54:48 UTC+2, gmis...@gmail.com a =C3=A9crit :
>
>
>
> On Friday, May 30, 2014 7:25:08 AM UTC+12, morw...@gmail.com wrote:
>>
>> I have some things to add to the conversation: first of all, I don't lik=
e=20
>> the syntax. At all. As many people here,=20
>>
>
> Yes many. But we really need to get beyond the focus on the=20
> syntax while people are not showing example alternative code or=20
> libraries that demonstrably provides the same feature set I have mentione=
d,=20
> that we all know the original for loop provides.
>

The example given by another answer here is an exact alternative code that=
=20
works just as well:

{
    size_t i =3D 0;
    for (const auto& e : v) do_something(i++, e);
}
=20

> =20
>
>> I prefere the tuple unpacking and std::enumerate solution. I agree that=
=20
>> it is subjective before anything else, but I just don't like it, sorry f=
or=20
>> that :(. However, no matter how subjective something is, if 90% of the=
=20
>> people don't like a solution and prefer an alternative, the alternative=
=20
>> will probably be chosen instead.
>>
>
> I don't quite see how tuple unpacking  relates to this, it may do, but=20
> that's exactly why example code is needed, to demonstrate that part too.
>

A simple example of the same example with Python then:

for i, e in enumerate(v):
    do_something(i, e)

Here, enumerate returns what would be a tuple<int, T> which is directly=20
unpacked into i and e (as it was said, the tuple is actually hidden by the=
=20
tuple unpacking syntax). This allows to write something that is both clear=
=20
and clean. enumerate being a library function, the only change to the=20
language is tuple unpacking, which is often used on the client side when a=
=20
function returns a tuple (in other words, whenever a function has several=
=20
values to return). Sometimes, we can't return a structure that makes sense=
=20
from a function, so we return a pair, a small array or a tuple. For=20
example, it wouldn't make sense to have a specific structure to return from=
=20
a quadratic equation solver since there wouldn't be any meaningful name, so=
=20
we return a tuple. Tuple unpacking would allow to write something along the=
=20
lines of:

auto (res1, res2) =3D quadratic(a, b, c);

There are countless examples of function in mathematics that return=20
multiple values that relate with each other but that are still "some=20
values" and not "some values that form a meaningful structure". That is why=
=20
mathematical scripting languages allow their functions to "return multiple=
=20
values", which be seen as an unpacked tuple of values. While we could try=
=20
to allow C++ functions to return multiple values, we would have to define=
=20
what it means, so it's easier to return tuples and allow them to be=20
unpacked.

This paragraph may seem a little bit off-topic, but it at least gives a=20
reason why I want tuple unpacking, and probably why other people want tuple=
=20
unpacking too. That also gives you the example code you wanted. I will skip=
=20
your other questions about tuple unpacking since I think that I just=20
answered them :)

Yes, but a single index isn't the only thing people track or do in their=20
> step and it doesn't have to be + 1 or even an increment at all.=20
>

I agree that many people do many things in the step part of the for-loop.=
=20
However, putting things other than an increment in the step part is often=
=20
viewed as bad practice. I can't find a suitable reference to support that,=
=20
but I often read "the step part of the loop exists to put the step in, if=
=20
you have some other things to put in it, put them at the end of the block".=
=20
We could probably write a while for loop and put almost anything in the=20
step part of the loop, separated by commas. Is it good practice? I don't=20
think so. IMHO, it is close to using operator&& instead of a if statement:=
=20
operator&& is great in a condition, can be used almost anywhere, but we=20
don't want to use it everywhere.

What your imaginary library offers me isn't guaranteed to exactly relate to=
=20
> what I want or be sufficient. But with my proposal being an extension to=
=20
> yours (it would seem), you can still use what your library provides if it=
=20
> is sufficient or augment it if it isn't with mine.
>

Here is my turn to request an example. I gave some examples of why I think=
=20
we only need tuple unpacking and a function to replace the typical use case=
=20
of your construct. Now, I want an example of what your construct can do=20
that isn't covered by tuple unpacking + functions and that is easier to=20
read than a regular for loop.

Why don't I like your solution? First of all, I always found that the=20
>> C-style for loop was no more than a hack around a regular while.=20
>
> =20
> That's a bit harsh. If it's true, people have used that hack in preferenc=
e=20
> to while for many years and I still use for more than while by far in my=
=20
> code today. That was as true for me in C as it is C++.
>
=20
We use for loops because they are *a little bit cleaner* than plain while=
=20
loops to iterate, but it does not offer much abstraction (I still don't=20
find that harsh to call them a hack). However, more and more C++ people=20
have started to request Python-like range, zip, reversed and enumerate=20
function to use in range-based for loops. People simply don't want to use=
=20
indices when they don't need them, they want another abstraction level to=
=20
hide indices and iterators, unless they are really needed. Python does not=
=20
even have a regular for loop, its for loop is a foreach loop; nobody ever=
=20
asked for a C-style loop, it is simply uneeded. I know, I don't stop=20
talking about Python and we are in a C++ mailing list, but its iterating=20
tools are good enough to be used as examples, and modern C++ is more about=
=20
iterators and less about indices anyway.

The only difference is the place of the declaration and of the increment,=
=20
>> as well as the scope of the declared variable (and we can get around tha=
t=20
>> by putting a while loop in a new scope). The range-based for loop offers=
 a=20
>> new level of abstraction, so I wouldn't want of a "new" loop that still=
=20
>> forces me to write the iterator increment stuff by hand.=20
>>
>
> Wait, wait. Where have I ever mentioned something in my proposal that=20
> forces anything?
>
Quite the contrary I've actually explained why alternative proposals are=20
> doing the forcing if anything so I'm not sure where you get this idea?
>
All I've demonstrated is that a hybrid of the two loops lets everybody get=
=20
> the best of both loops exactly so nobody is forced to do anything, they=
=20
> just pick and mix.
>
=20
You are right. My use of "force" wasn't for the better. What I meant is=20
that I think that only one of the solutions to the typical problem (iterate=
=20
with index and elem) will be chosen in the end. Since, if accepted, your=20
proposal would be considered the idiomatic way to do that, I would in the=
=20
end be "forced" to used it to write idiomatic C++ code.

At least, std::enumerate automagically produces the indices, we don't have=
=20
>> to compute them by hand.
>>
>
> Again, that assumes there is just one index, it's +1 or that you even wan=
t=20
> to increment anything at all in the step.
>
=20
If we want something that is not "+1", the idiomatic C++ way would be to=20
write an iterator that does something else (and there are several tools to=
=20
efficiently write iterators, Boost.Iterator being one of them). Then, we=20
apply "++" to the iterator.

Moreover, while "enumerate" is easy to find with a searching tool, your=20
>> proposed syntax is rather hard to find, and if one reads too fast, they =
may=20
>> think it is a regular C-style for loop.
>>
>
> Is that a real argument? I've seen whole pages of C++ code that looks lik=
e=20
> C for that to be a worry or any confusion! lol Only half the time does th=
at=20
> bother me. That's the real worry!! lol
>

Half the time can already be pretty much of a concern. The search tool=20
argument was already used as a weakness for the static if proposal, so=20
yeah, it may be a valid argument.

I don't think anyone has attacked this proposal on substance yet, so I'm=20
> not concerned by that yet. If they succeed, I'll be happy, I just want a=
=20
> better mouse trap.
> But to do that you've got to start talking features and examples that sho=
w=20
> that and also why this proposal can't augment the alternative too.
> So far I'm still not seeing that.
>

 I don't want to sound harsh again (or do I?) but there isn't that much=20
substance in the first place to attack. Your proposal is no more than a=20
mere syntactic enhancement and most (?) of us don't even see it as an=20
enhancement. We provided an alternative for the most common use case, which=
=20
can be used to improve other areas than foreach loops, and are still=20
waiting for use cases and are still waiting for examples of code where your=
=20
proposal would make enough of a difference to deserve its language change.

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

<div dir=3D"ltr">Le vendredi 30 mai 2014 00:54:48 UTC+2, gmis...@gmail.com =
a =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><br><br>On Friday, May 30, 2014 7:25:08 AM UTC+12, <a>morw...@gmail.c=
om</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width=
:1px;border-left-style:solid"><div dir=3D"ltr">I have some things to add to=
 the conversation: first of all, I don't like the syntax. At all. As many p=
eople here, </div></blockquote><div><br></div><div>Yes many. But we really =
need to get beyond the focus on the syntax&nbsp;while&nbsp;people are not s=
howing&nbsp;example alternative code or libraries&nbsp;that demonstrably pr=
ovides the same feature set I have mentioned, that we all know the original=
 for loop provides.<br></div></div></blockquote><div><br>The example given =
by another answer here is an exact alternative code that works just as well=
:<br><br><div style=3D"margin-left: 40px;"><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #660;=
" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>&nbsp; &nbsp; size_t i </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" clas=
s=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">for</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> e </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> v</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> do_something</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">i</span><span style=3D"color: #660;" class=3D"styled-by-prettify">++,</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> e</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span></div></code></div></div>&nbsp;<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></d=
iv><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-lef=
t-width:1px;border-left-style:solid"><div dir=3D"ltr">I prefere the tuple u=
npacking and std::enumerate solution. I agree that it is subjective before =
anything else, but I just don't like it, sorry for that :(. However, no mat=
ter how subjective something is, if 90% of the people don't like a solution=
 and prefer an alternative, the alternative will probably be chosen instead=
..<br></div></blockquote><div><br></div><div>I&nbsp;don't quite see how tupl=
e unpacking&nbsp; relates to this, it may do, but that's exactly why exampl=
e code is needed, to demonstrate that part too.<br></div></div></blockquote=
><div dir=3D"ltr"><br>A simple example of the same example with Python then=
:<br><br><div style=3D"margin-left: 40px;"><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">for</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> e </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
in</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> enumera=
te</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">v</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">):</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; do_something</sp=
an><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-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> e</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span></div></code></div><br></div>Here, enumerate re=
turns what would be a tuple&lt;int, T&gt; which is directly unpacked into i=
 and e (as it was said, the tuple is actually hidden by the tuple unpacking=
 syntax). This allows to write something that is both clear and clean. enum=
erate being a library function, the only change to the language is tuple un=
packing, which is often used on the client side when a function returns a t=
uple (in other words, whenever a function has several values to return). So=
metimes, we can't return a structure that makes sense from a function, so w=
e return a pair, a small array or a tuple. For example, it wouldn't make se=
nse to have a specific structure to return from a quadratic equation solver=
 since there wouldn't be any meaningful name, so we return a tuple. Tuple u=
npacking would allow to write something along the lines of:<br><br><div cla=
ss=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-co=
lor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap:=
 break-word; margin-left: 40px;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">a=
uto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">res1</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> res2</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> quadratic</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> c</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span></div></code></div><br>There are countle=
ss examples of function in mathematics that return multiple values that rel=
ate with each other but that are still "some values" and not "some values t=
hat form a meaningful structure". That is why mathematical scripting langua=
ges allow their functions to "return multiple values", which be seen as an =
unpacked tuple of values. While we could try to allow C++ functions to retu=
rn multiple values, we would have to define what it means, so it's easier t=
o return tuples and allow them to be unpacked.<br><br>This paragraph may se=
em a little bit off-topic, but it at least gives a reason why I want tuple =
unpacking, and probably why other people want tuple unpacking too. That als=
o gives you the example code you wanted. I will skip your other questions a=
bout tuple unpacking since I think that I just answered them :)<br><div><br=
></div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px sol=
id rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><div>Yes,&=
nbsp;but&nbsp;a single&nbsp;index isn't the only thing people track or do i=
n their step and it doesn't have to be&nbsp;+ 1&nbsp;or even an increment a=
t all. </div></blockquote><div><br>I agree that many people do many things =
in the step part of the for-loop. However, putting things other than an inc=
rement in the step part is often viewed as bad practice. I can't find a sui=
table reference to support that, but I often read "the step part of the loo=
p exists to put the step in, if you have some other things to put in it, pu=
t them at the end of the block". We could probably write a while for loop a=
nd put almost anything in the step part of the loop, separated by commas. I=
s it good practice? I don't think so. IMHO, it is close to using operator&a=
mp;&amp; instead of a if statement: operator&amp;&amp; is great in a condit=
ion, can be used almost anywhere, but we don't want to use it everywhere.<b=
r><br></div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1p=
x solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><div>=
What&nbsp;your imaginary&nbsp;library offers me isn't guaranteed to exactly=
 relate to what I want or be sufficient. But&nbsp;with my proposal being an=
 extension&nbsp;to yours (it would seem),&nbsp;you can&nbsp;still&nbsp;use =
what your library provides if it is sufficient or augment it if it isn't wi=
th mine.</div></blockquote><div dir=3D"ltr"><br>Here is my turn to request =
an example. I gave some examples of why I think we only need tuple unpackin=
g and a function to replace the typical use case of your construct. Now, I =
want an example of what your construct can do that isn't covered by tuple u=
npacking + functions and that is easier to read than a regular for loop.<br=
><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid=
 rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><blockquote =
style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 20=
4); padding-left: 1ex;" class=3D"gmail_quote">Why don't I like your solutio=
n? First of all, I always found that the C-style for loop was no more than =
a hack around a regular while. </blockquote></blockquote></div><blockquote =
style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 20=
4); padding-left: 1ex;" class=3D"gmail_quote"><div>&nbsp;</div><div>That's =
a bit harsh. If&nbsp;it's true, people have used that hack in preference to=
 while for many years and I still use for more than while by far in my code=
 today. That was as&nbsp;true for me&nbsp;in C&nbsp;as it is&nbsp;C++.</div=
></blockquote><div>&nbsp;<br>We use for loops because they are <i>a little =
bit cleaner</i> than plain while loops to iterate, but it does not offer mu=
ch abstraction (I still don't find that harsh to call them a hack). However=
, more and more C++ people have started to request Python-like range, zip, =
reversed and enumerate function to use in range-based for loops. People sim=
ply don't want to use indices when they don't need them, they want another =
abstraction level to hide indices and iterators, unless they are really nee=
ded. Python does not even have a regular for loop, its for loop is a foreac=
h loop; nobody ever asked for a C-style loop, it is simply uneeded. I know,=
 I don't stop talking about Python and we are in a C++ mailing list, but it=
s iterating tools are good enough to be used as examples, and modern C++ is=
 more about iterators and less about indices anyway.<br><br></div><blockquo=
te style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204,=
 204); padding-left: 1ex;" class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-colo=
r:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=
=3D"ltr">The only difference is the place of the declaration and of the inc=
rement, as well as the scope of the declared variable (and we can get aroun=
d that by putting a while loop in a new scope). The range-based for loop of=
fers a new level of abstraction, so I wouldn't want of a "new" loop that st=
ill forces me&nbsp;to write the iterator increment stuff by hand. </div></b=
lockquote></blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_q=
uote"><div><br></div><div>Wait, wait. Where have I ever mentioned something=
 in my proposal that forces anything?</div></blockquote><blockquote style=
=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;" class=3D"gmail_quote"><div>Quite the contrary I've actua=
lly explained why alternative proposals&nbsp;are doing the forcing if anyth=
ing so I'm not sure where you get this idea?</div></blockquote><blockquote =
style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 20=
4); padding-left: 1ex;" class=3D"gmail_quote"><div>All I've demonstrated is=
 that a hybrid of the two loops lets everybody get the best of both loops e=
xactly so nobody is forced to do anything, they just pick and mix.</div></b=
lockquote><div>&nbsp;<br>You are right. My use of "force" wasn't for the be=
tter. What I meant is that I think that only one of the solutions to the ty=
pical problem (iterate with index and elem) will be chosen in the end. Sinc=
e, if accepted, your proposal would be considered the idiomatic way to do t=
hat, I would in the end be "forced" to used it to write idiomatic C++ code.=
<br><br></div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: =
1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-le=
ft:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left=
-style:solid"><div dir=3D"ltr">At least, std::enumerate automagically produ=
ces the indices, we don't have to compute them by hand.</div></blockquote><=
/blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1p=
x solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><div>=
<br></div><div>Again, that assumes there is just one index, it's +1 or that=
 you even want to increment anything at all in the step.</div></blockquote>=
<div>&nbsp;<br>If we want something that is not "+1", the idiomatic C++ way=
 would be to write an iterator that does something else (and there are seve=
ral tools to efficiently write iterators, Boost.Iterator being one of them)=
.. Then, we apply "++" to the iterator.<br><br></div><blockquote style=3D"ma=
rgin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding=
-left: 1ex;" class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"> More=
over, while "enumerate" is easy to find with a searching tool, your propose=
d syntax is rather hard to find, and if one reads too fast, they may think =
it is a regular C-style for loop.<br></div></blockquote></blockquote><block=
quote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 2=
04, 204); padding-left: 1ex;" class=3D"gmail_quote"><div><br></div><div>Is =
that a real argument? I've seen&nbsp;whole&nbsp;pages of&nbsp;C++ code that=
 looks like C&nbsp;for that to be a worry or any confusion! lol&nbsp;Only h=
alf the time does that bother me. That's the real worry!! lol</div></blockq=
uote><div><br>Half the time can already be pretty much of a concern. The se=
arch tool argument was already used as a weakness for the static if proposa=
l, so yeah, it may be a valid argument.<br><br></div><blockquote style=3D"m=
argin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); paddin=
g-left: 1ex;" class=3D"gmail_quote"><div>I don't think anyone has attacked =
this proposal on substance yet, so&nbsp;I'm not&nbsp;concerned by that yet.=
 If they succeed, I'll be happy, I just want a better mouse trap.</div><div=
>But to do that you've got to&nbsp;start talking features and examples that=
 show that and also why this proposal can't augment the&nbsp;alternative to=
o.</div><div>So far I'm still not seeing that.</div></blockquote><div><br>&=
nbsp;I don't want to sound harsh again (or do I?) but there isn't that much=
 substance in the first place to attack. Your proposal is no more than a me=
re syntactic enhancement and most (?) of us don't even see it as an enhance=
ment. We provided an alternative for the most common use case, which can be=
 used to improve other areas than foreach loops, and are still waiting for =
use cases and are still waiting for examples of code where your proposal wo=
uld make enough of a difference to deserve its language change.<br></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_278_30902894.1401445394038--

.

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



On Friday, May 30, 2014 10:23:14 PM UTC+12, morw...@gmail.com wrote:
>
> Le vendredi 30 mai 2014 00:54:48 UTC+2, gmis...@gmail.com a =C3=A9crit :
>>
>>
>>
>> On Friday, May 30, 2014 7:25:08 AM UTC+12, morw...@gmail.com wrote:
>>>
>>> I have some things to add to the conversation: first of all, I don't=20
>>> like the syntax. At all. As many people here,=20
>>>
>>
>> Yes many. But we really need to get beyond the focus on the=20
>> syntax while people are not showing example alternative code or=20
>> libraries that demonstrably provides the same feature set I have mention=
ed,=20
>> that we all know the original for loop provides.
>>
>
> The example given by another answer here is an exact alternative code tha=
t=20
> works just as well:
>
> {
>     size_t i =3D 0;
>     for (const auto& e : v) do_something(i++, e);
> }
>

Yes it works ok.  But you miss my point about what I was answering. My=20
point was that we already had the potential to do this:
{ int I; for (I =3D 0; I < 10;++I) do_something() }
when despite that, the committee later saw fit to introduce a small=20
language change to allow simply this:
for (int I =3D0; I < 10; ++I) do_something();
My change is for much the same thing for the new for loop.

So I was making the point to the person who was arguing with such=20
confidence that no one would/should change the language for such a small=20
change when it just enables something that we can already do, to not be so=
=20
premature in that confidence about what people or the committee might or=20
might not do because history has already shown they might vote for it=20
because they did before in very much these same circumstances.

I'm not saying they would again, but that was my point. I see nothing wrong=
=20
in that point of view.

> =20
>>
>>> I prefere the tuple unpacking and std::enumerate solution. I agree that=
=20
>>> it is subjective before anything else, but I just don't like it, sorry =
for=20
>>> that :(. However, no matter how subjective something is, if 90% of the=
=20
>>> people don't like a solution and prefer an alternative, the alternative=
=20
>>> will probably be chosen instead.
>>>
>>
>> I don't quite see how tuple unpacking  relates to this, it may do, but=
=20
>> that's exactly why example code is needed, to demonstrate that part too.
>>
>
> A simple example of the same example with Python then:
>
> for i, e in enumerate(v):
>     do_something(i, e)
>
> Here, enumerate returns what would be a tuple<int, T> which is directly=
=20
> unpacked into i and e (as it was said, the tuple is actually hidden by th=
e=20
> tuple unpacking syntax). This allows to write something that is both clea=
r=20
> and clean. enumerate being a library function, the only change to the=20
> language is tuple unpacking, which is often used on the client side when =
a=20
> function returns a tuple (in other words, whenever a function has several=
=20
> values to return). Sometimes, we can't return a structure that makes sens=
e=20
> from a function, so we return a pair, a small array or a tuple. For=20
> example, it wouldn't make sense to have a specific structure to return fr=
om=20
> a quadratic equation solver since there wouldn't be any meaningful name, =
so=20
> we return a tuple. Tuple unpacking would allow to write something along t=
he=20
> lines of:
>
> auto (res1, res2) =3D quadratic(a, b, c);
>
> There are countless examples of function in mathematics that return=20
> multiple values that relate with each other but that are still "some=20
> values" and not "some values that form a meaningful structure". That is w=
hy=20
> mathematical scripting languages allow their functions to "return multipl=
e=20
> values", which be seen as an unpacked tuple of values. While we could try=
=20
> to allow C++ functions to return multiple values, we would have to define=
=20
> what it means, so it's easier to return tuples and allow them to be=20
> unpacked.
>
> This paragraph may seem a little bit off-topic, but it at least gives a=
=20
> reason why I want tuple unpacking, and probably why other people want tup=
le=20
> unpacking too. That also gives you the example code you wanted. I will sk=
ip=20
> your other questions about tuple unpacking since I think that I just=20
> answered them :)
>

You may be right I don't work in a mathematical heavy domain so I don't see=
=20
that need often. Mostly I see people using tuples like how I see pair gets=
=20
overused. People think they just want to return a couple of values so they=
=20
hijack pair, then forever more I'm looking at .first .second. And that's=20
never useful. It's always really x, y or something where a name would=20
convey something. I see people abusing tuple the same way, get<n> is never=
=20
more useful than the name and usually a type name conveys even more with=20
that. That's why I find std::tuple mostly useless and state that something=
=20
better is needed. What that better is, I don't know yet. I just=20
hope whatever it is, it doesn't encourage tuples to be used where a real=20
type is more appropriate. That's another reason why I was keen to see real=
=20
examples of tuple use. When you just see res1, res2, it's hard to know=20
people are trying to achieve with them.

With my for loop construct, everyone knows what that's all about because=20
it's the same for loop concept as we already have, it needs no introduction=
..
=20

>
> Yes, but a single index isn't the only thing people track or do in their=
=20
>> step and it doesn't have to be + 1 or even an increment at all.=20
>>
>
> I agree that many people do many things in the step part of the for-loop.=
=20
> However, putting things other than an increment in the step part is often=
=20
> viewed as bad practice. I can't find a suitable reference to support that=
,=20
> but I often read "the step part of the loop exists to put the step in, if=
=20
> you have some other things to put in it, put them at the end of the block=
".=20
> We could probably write a while for loop and put almost anything in the=
=20
> step part of the loop, separated by commas. Is it good practice? I don't=
=20
> think so. IMHO, it is close to using operator&& instead of a if statement=
:=20
> operator&& is great in a condition, can be used almost anywhere, but we=
=20
> don't want to use it everywhere.
>

I partly agree, but that's not the only factor. "continue" doesn't hit the=
=20
end of the block and my examples were demonstrating that deficiency. And=20
for simple increments that aren't a step of 1, it's handy to have the=20
options to get the best of both worlds where you use it carefully.  Seeing=
=20
the step at the top is a nice thing. These are all features of my proposal=
=20
never the less.

>
> What your imaginary library offers me isn't guaranteed to exactly relate=
=20
>> to what I want or be sufficient. But with my proposal being an extension=
 to=20
>> yours (it would seem), you can still use what your library provides if i=
t=20
>> is sufficient or augment it if it isn't with mine.
>>
>
> Here is my turn to request an example. I gave some examples of why I thin=
k=20
> we only need tuple unpacking and a function to replace the typical use ca=
se=20
> of your construct. Now, I want an example of what your construct can do=
=20
> that isn't covered by tuple unpacking + functions and that is easier to=
=20
> read than a regular for loop.
>
=20
We already know what the abilities are of my proposal are. I've just=20
articulated them again anyway if we didn't, like continue etc.: it's the=20
same as the abilities of a regular for loop, plus the abilities of the=20
enhanced loop - features we already have, but combined. That's it.

When you can add your tuple unpacking thing in there too, my loop will be=
=20
somewhat useful there too if you feel you need it, nothing spectacular but=
=20
it doesn't subtract from it either. There isn't more of a story to tell=20
here. We all know what the loop features do, mine is just the superset.=20
That's it.

>
> Why don't I like your solution? First of all, I always found that the=20
>>> C-style for loop was no more than a hack around a regular while.=20
>>
>> =20
>> That's a bit harsh. If it's true, people have used that hack in=20
>> preference to while for many years and I still use for more than while b=
y=20
>> far in my code today. That was as true for me in C as it is C++.
>>
> =20
> We use for loops because they are *a little bit cleaner* than plain while=
=20
> loops to iterate, but it does not offer much abstraction (I still don't=
=20
> find that harsh to call them a hack). However, more and more C++ people=
=20
> have started to request Python-like range, zip, reversed and enumerate=20
> function to use in range-based for loops. People simply don't want to use=
=20
> indices when they don't need them, they want another abstraction level to=
=20
> hide indices and iterators, unless they are really needed. Python does no=
t=20
> even have a regular for loop, its for loop is a foreach loop; nobody ever=
=20
> asked for a C-style loop, it is simply uneeded. I know, I don't stop=20
> talking about Python and we are in a C++ mailing list, but its iterating=
=20
> tools are good enough to be used as examples, and modern C++ is more abou=
t=20
> iterators and less about indices anyway.
>
=20
Agreed. I haven't proposed anything that will stop the evolution of that.=
=20
If you don't find the feature useful, you don't use it and it doesn't force=
=20
itself on you.

To digress, I actually think some of these ideas go too far and make some=
=20
of this easier than it actually is, whether it be "iterator" or the "C++=20
way" or whatever. For instance, the new file system library has a recursive=
=20
file system iterator that suggests you just go (something like):=20
for( recursive_file_system_iterator it; it !=3D end; ++it)
{
 puts(it->filename);
}

But in actual practice, it'll likely never ever be like that in practice=20
because of the amount of error checking you actually need to process a=20
whole file system taking into account file permissions etc. etc. The above=
=20
loop would crash in two seconds in real life, yet I often see stuff=20
suggesting copy_directory(directory_iterator) blah blah is just as simple=
=20
as it looks. But such idealised chaining doesn't actually work in practice=
=20
when you deal with things that fail. Which is nearly everything. Especially=
=20
when a network or file system is in the way. So real life means a lot of=20
this chained code that looks great in an example, often isn't real.

>
> The only difference is the place of the declaration and of the increment,=
=20
>>> as well as the scope of the declared variable (and we can get around th=
at=20
>>> by putting a while loop in a new scope). The range-based for loop offer=
s a=20
>>> new level of abstraction, so I wouldn't want of a "new" loop that still=
=20
>>> forces me to write the iterator increment stuff by hand.=20
>>>
>>
>> Wait, wait. Where have I ever mentioned something in my proposal that=20
>> forces anything?
>>
> Quite the contrary I've actually explained why alternative proposals are=
=20
>> doing the forcing if anything so I'm not sure where you get this idea?
>>
> All I've demonstrated is that a hybrid of the two loops lets everybody ge=
t=20
>> the best of both loops exactly so nobody is forced to do anything, they=
=20
>> just pick and mix.
>>
> =20
> You are right. My use of "force" wasn't for the better. What I meant is=
=20
> that I think that only one of the solutions to the typical problem (itera=
te=20
> with index and elem) will be chosen in the end. Since, if accepted, your=
=20
> proposal would be considered the idiomatic way to do that, I would in the=
=20
> end be "forced" to used it to write idiomatic C++ code.
>

I don't agree. You've stretched your concern about my proposal too far in=
=20
this suggestion in my opinion. There simply is no forcing here. Use the=20
bits you need as you need them. Where it doesn't make sense, don't. If you=
=20
pick the right loop or tuple or whatever to begin with for your=20
solution, nobody is going to argue with you. It's not template wars here or=
=20
nearly anything so complicated.

>
> At least, std::enumerate automagically produces the indices, we don't hav=
e=20
>>> to compute them by hand.
>>>
>>
>> Again, that assumes there is just one index, it's +1 or that you even=20
>> want to increment anything at all in the step.
>>
> =20
> If we want something that is not "+1", the idiomatic C++ way would be to=
=20
> write an iterator that does something else (and there are several tools t=
o=20
> efficiently write iterators, Boost.Iterator being one of them). Then, we=
=20
> apply "++" to the iterator.
>
> Moreover, while "enumerate" is easy to find with a searching tool, your=
=20
>>> proposed syntax is rather hard to find, and if one reads too fast, they=
 may=20
>>> think it is a regular C-style for loop.
>>>
>>
>> Is that a real argument? I've seen whole pages of C++ code that looks=20
>> like C for that to be a worry or any confusion! lol Only half the time d=
oes=20
>> that bother me. That's the real worry!! lol
>>
>
> Half the time can already be pretty much of a concern. The search tool=20
> argument was already used as a weakness for the static if proposal, so=20
> yeah, it may be a valid argument.
>

I missed your point about searching, I would agree with that statement but=
=20
people should be putting their loops into functions anyway that serve the=
=20
purpose not just inline looping everywhere so your argument is overblown.

The proof is that I've never ever search for a for as a keyword search, who=
=20
has? I search for find_customer or find_person or whatever and the loop is=
=20
inside that. Anyone who does different is in the wrong job and no enumerate=
=20
is going to help them.


> I don't think anyone has attacked this proposal on substance yet, so I'm=
=20
>> not concerned by that yet. If they succeed, I'll be happy, I just want a=
=20
>> better mouse trap.
>> But to do that you've got to start talking features and examples that=20
>> show that and also why this proposal can't augment the alternative too.
>> So far I'm still not seeing that.
>>
>
>  I don't want to sound harsh again (or do I?) but there isn't that much=
=20
> substance in the first place to attack. Your proposal is no more than a=
=20
> mere syntactic enhancement and most (?) of us don't even see it as an=20
> enhancement. We provided an alternative for the most common use case, whi=
ch=20
> can be used to improve other areas than foreach loops, and are still=20
> waiting for use cases and are still waiting for examples of code where yo=
ur=20
> proposal would make enough of a difference to deserve its language change=
..
>

You are right, this proposal isn't a proposal of massive substance, but I=
=20
never suggested it was? It is what I've always maintained it was, a simple=
=20
extension to graft the features of the existing for loop onto the newer for=
=20
loop to make the superset.

No mega examples are required to demonstrate something so simple. Even less=
=20
so when it's just the combination of two features we already have and that=
=20
aren't hard to grasp to begin with.

But when people are attacking that proposal with, "it won't work" and "I=20
don't like the syntax" and then "your proposal is forcing me to do=20
whatever" all I can do is answer that and say what nonsense most of that is=
=20
and that's what I've done.

And when you move on to (effectively saying) "I think some tuple thing is=
=20
better", all I can do is say, fine, show me your tuple thing, but then=20
the onus is on you to have examples to demonstrate that because you're=20
proposing something much more complicated than my proposal; so you need the=
=20
examples, not me.

So with that all said, I think I've covered enough ground in this=20
discussion about what my proposal is and isn't and cleared up a few of=20
the mischaracterizations on that which might have confuse peopled. So I=20
think my duty is done here. There should be sufficient information here now=
=20
that I shouldn't need to add anything further for the time being, if at all=
..

The proposal appeals or non appeal is better now left to interested or=20
disinterested parties to discuss it between them. I'll just=20
watch how that pans out for a while. It's not an earth shattering proposal=
=20
so I don't expect much. But all the info is here now. It just needs to sink=
=20
or swim on it's own.

Thanks for the discussion.=20

The tuple stuff looks interesting but it's really separate to my proposal=
=20
as my proposal here isn't dependent on them at all. So I'll be keen to=20
follow that more in the appropriate threads I've seen pop up. I admit=20
I'm not keen on tuples for the reasons I've given but I am keen to have=20
that view swayed so it will be interesting for me. Thanks for the maths=20
domain suggestion about them. That at least gives me a bit of=20
an insight into why the fascination with them is so high in some sections=
=20
of the community and less in others. I wonder if there are any math's=20
wizards who are less than enamoured by tuples. I look forward to hearing=20
either type of person add their views in those threads. Interesting stuff.

Thanks

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

<div dir=3D"ltr"><br><br>On Friday, May 30, 2014 10:23:14 PM UTC+12, morw..=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">Le vendredi=
 30 mai 2014 00:54:48 UTC+2, <a>gmis...@gmail.com</a> a =C3=A9crit&nbsp;:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding=
-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; =
border-left-style: solid;"><div dir=3D"ltr"><br><br>On Friday, May 30, 2014=
 7:25:08 AM UTC+12, <a>morw...@gmail.com</a> wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-lef=
t-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: sol=
id;"><div dir=3D"ltr">I have some things to add to the conversation: first =
of all, I don't like the syntax. At all. As many people here, </div></block=
quote><div><br></div><div>Yes many. But we really need to get beyond the fo=
cus on the syntax&nbsp;while&nbsp;people are not showing&nbsp;example alter=
native code or libraries&nbsp;that demonstrably provides the same feature s=
et I have mentioned, that we all know the original for loop provides.<br></=
div></div></blockquote><div><br>The example given by another answer here is=
 an exact alternative code that works just as well:<br><br><div style=3D"ma=
rgin-left: 40px;"><div style=3D"border: 1px solid rgb(187, 187, 187); borde=
r-image: none; -ms-word-wrap: break-word; background-color: rgb(250, 250, 2=
50);"><code><div><span style=3D"color: rgb(102, 102, 0);">{</span><span sty=
le=3D"color: rgb(0, 0, 0);"><br>&nbsp; &nbsp; size_t i </span><span style=
=3D"color: rgb(102, 102, 0);">=3D</span><span style=3D"color: rgb(0, 0, 0);=
"> </span><span style=3D"color: rgb(0, 102, 102);">0</span><span style=3D"c=
olor: rgb(102, 102, 0);">;</span><span style=3D"color: rgb(0, 0, 0);"><br>&=
nbsp; &nbsp; </span><span style=3D"color: rgb(0, 0, 136);">for</span><span =
style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 102, =
0);">(</span><span style=3D"color: rgb(0, 0, 136);">const</span><span style=
=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);">au=
to</span><span style=3D"color: rgb(102, 102, 0);">&amp;</span><span style=
=3D"color: rgb(0, 0, 0);"> e </span><span style=3D"color: rgb(102, 102, 0);=
">:</span><span style=3D"color: rgb(0, 0, 0);"> v</span><span style=3D"colo=
r: rgb(102, 102, 0);">)</span><span style=3D"color: rgb(0, 0, 0);"> do_some=
thing</span><span style=3D"color: rgb(102, 102, 0);">(</span><span style=3D=
"color: rgb(0, 0, 0);">i</span><span style=3D"color: rgb(102, 102, 0);">++,=
</span><span style=3D"color: rgb(0, 0, 0);"> e</span><span style=3D"color: =
rgb(102, 102, 0);">);</span><span style=3D"color: rgb(0, 0, 0);"><br></span=
><span style=3D"color: rgb(102, 102, 0);">}</span><span style=3D"color: rgb=
(0, 0, 0);"><br></span></div></code></div></div></div></div></blockquote><d=
iv><br></div><div>Yes it works ok.&nbsp; But&nbsp;you miss my point about w=
hat I was answering.&nbsp;My point was that we already had the potential to=
 do this:</div><div>{ int I; for (I =3D 0; I &lt; 10;++I) do_something() }<=
/div><div>when despite that, the committee later saw fit&nbsp;to introduce =
a small language change to allow simply this:</div><div>for (int I =3D0; I =
&lt; 10; ++I) do_something();</div><div>My change is for much the same thin=
g for the new for loop.</div><div><br></div><div>So I was&nbsp;making the&n=
bsp;point&nbsp;to the person&nbsp;who was arguing with such confidence that=
&nbsp;no one&nbsp;would/should&nbsp;change the language&nbsp;for such a sma=
ll change&nbsp;when it just enables something that we can already do, to&nb=
sp;not be so premature in that confidence about what people or the committe=
e&nbsp;might or might not do because history has already shown they might v=
ote for it because they did before in&nbsp;very much&nbsp;these same circum=
stances.</div><div><br></div><div>I'm not saying they would again, but that=
 was my point.&nbsp;I see nothing wrong in that point of view.</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb=
(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div di=
r=3D"ltr"><div></div><div>&nbsp;</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(=
204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr">I prefere the tuple unpacking and std::enumerate solution. I agree=
 that it is subjective before anything else, but I just don't like it, sorr=
y for that :(. However, no matter how subjective something is, if 90% of th=
e people don't like a solution and prefer an alternative, the alternative w=
ill probably be chosen instead.<br></div></blockquote><div><br></div><div>I=
&nbsp;don't quite see how tuple unpacking&nbsp; relates to this, it may do,=
 but that's exactly why example code is needed, to demonstrate that part to=
o.<br></div></div></blockquote><div dir=3D"ltr"><br>A simple example of the=
 same example with Python then:<br><br><div style=3D"margin-left: 40px;"><d=
iv style=3D"border: 1px solid rgb(187, 187, 187); border-image: none; -ms-w=
ord-wrap: break-word; background-color: rgb(250, 250, 250);"><code><div><sp=
an style=3D"color: rgb(0, 0, 136);">for</span><span style=3D"color: rgb(0, =
0, 0);"> i</span><span style=3D"color: rgb(102, 102, 0);">,</span><span sty=
le=3D"color: rgb(0, 0, 0);"> e </span><span style=3D"color: rgb(0, 0, 136);=
">in</span><span style=3D"color: rgb(0, 0, 0);"> enumerate</span><span styl=
e=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 0);"=
>v</span><span style=3D"color: rgb(102, 102, 0);">):</span><span style=3D"c=
olor: rgb(0, 0, 0);"><br>&nbsp; &nbsp; do_something</span><span style=3D"co=
lor: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 0);">i</spa=
n><span style=3D"color: rgb(102, 102, 0);">,</span><span style=3D"color: rg=
b(0, 0, 0);"> e</span><span style=3D"color: rgb(102, 102, 0);">)</span><spa=
n style=3D"color: rgb(0, 0, 0);"><br></span></div></code></div><br></div>He=
re, enumerate returns what would be a tuple&lt;int, T&gt; which is directly=
 unpacked into i and e (as it was said, the tuple is actually hidden by the=
 tuple unpacking syntax). This allows to write something that is both clear=
 and clean. enumerate being a library function, the only change to the lang=
uage is tuple unpacking, which is often used on the client side when a func=
tion returns a tuple (in other words, whenever a function has several value=
s to return). Sometimes, we can't return a structure that makes sense from =
a function, so we return a pair, a small array or a tuple. For example, it =
wouldn't make sense to have a specific structure to return from a quadratic=
 equation solver since there wouldn't be any meaningful name, so we return =
a tuple. Tuple unpacking would allow to write something along the lines of:=
<br><br><div style=3D"border: 1px solid rgb(187, 187, 187); border-image: n=
one; margin-left: 40px; -ms-word-wrap: break-word; background-color: rgb(25=
0, 250, 250);"><code><div><span style=3D"color: rgb(0, 0, 136);">auto</span=
><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102=
, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 0);">res1</span><span s=
tyle=3D"color: rgb(102, 102, 0);">,</span><span style=3D"color: rgb(0, 0, 0=
);"> res2</span><span style=3D"color: rgb(102, 102, 0);">)</span><span styl=
e=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 102, 0);"=
>=3D</span><span style=3D"color: rgb(0, 0, 0);"> quadratic</span><span styl=
e=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 0);"=
>a</span><span style=3D"color: rgb(102, 102, 0);">,</span><span style=3D"co=
lor: rgb(0, 0, 0);"> b</span><span style=3D"color: rgb(102, 102, 0);">,</sp=
an><span style=3D"color: rgb(0, 0, 0);"> c</span><span style=3D"color: rgb(=
102, 102, 0);">);</span><span style=3D"color: rgb(0, 0, 0);"><br></span></d=
iv></code></div><br>There are countless examples of function in mathematics=
 that return multiple values that relate with each other but that are still=
 "some values" and not "some values that form a meaningful structure". That=
 is why mathematical scripting languages allow their functions to "return m=
ultiple values", which be seen as an unpacked tuple of values. While we cou=
ld try to allow C++ functions to return multiple values, we would have to d=
efine what it means, so it's easier to return tuples and allow them to be u=
npacked.<br><br>This paragraph may seem a little bit off-topic, but it at l=
east gives a reason why I want tuple unpacking, and probably why other peop=
le want tuple unpacking too. That also gives you the example code you wante=
d. I will skip your other questions about tuple unpacking since I think tha=
t I just answered them :)<br></div></div></blockquote><div><br></div><div>Y=
ou may be right I don't work in a mathematical heavy domain so I don't see =
that need often. Mostly I see people using tuples like how&nbsp;I see pair =
gets overused. People think they just want to return a couple of values so =
they hijack&nbsp;pair, then forever more I'm looking at .first .second. And=
 that's never useful. It's always really x, y or something where a name wou=
ld convey something. I see people abusing tuple the same way, get&lt;n&gt; =
is never more useful than the name and usually a type name conveys even mor=
e with that. That's why I find std::tuple mostly&nbsp;useless and state tha=
t something better is needed. What that better is, I don't know yet. I just=
 hope&nbsp;whatever it is, it&nbsp;doesn't encourage tuples to be used wher=
e a real type is more appropriate. That's another reason why I was keen to =
see real examples of tuple use. When you just see res1, res2, it's hard to =
know people are trying to achieve with them.</div><div><br></div><div>With =
my for loop construct, everyone knows what that's all about because it's th=
e same for loop concept as we already have, it needs no introduction.</div>=
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div dir=3D"=
ltr"><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bo=
rder-left-width: 1px; border-left-style: solid;"><div>Yes,&nbsp;but&nbsp;a =
single&nbsp;index isn't the only thing people track or do in their step and=
 it doesn't have to be&nbsp;+ 1&nbsp;or even an increment at all. </div></b=
lockquote><div><br>I agree that many people do many things in the step part=
 of the for-loop. However, putting things other than an increment in the st=
ep part is often viewed as bad practice. I can't find a suitable reference =
to support that, but I often read "the step part of the loop exists to put =
the step in, if you have some other things to put in it, put them at the en=
d of the block". We could probably write a while for loop and put almost an=
ything in the step part of the loop, separated by commas. Is it good practi=
ce? I don't think so. IMHO, it is close to using operator&amp;&amp; instead=
 of a if statement: operator&amp;&amp; is great in a condition, can be used=
 almost anywhere, but we don't want to use it everywhere.<br></div></div></=
div></blockquote><div><br></div><div>I partly agree,&nbsp;but that's not th=
e only factor. "continue" doesn't hit the end of the block and my examples =
were&nbsp;demonstrating that deficiency.&nbsp;And for simple increments tha=
t aren't a step of 1, it's handy to have the options to get the best of bot=
h worlds where you use it carefully.&nbsp;&nbsp;Seeing the step at the top =
is a nice thing. These are&nbsp;all features of my proposal never the less.=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
 padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-widt=
h: 1px; border-left-style: solid;"><div dir=3D"ltr"><div dir=3D"ltr"><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8=
ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-w=
idth: 1px; border-left-style: solid;"><div>What&nbsp;your imaginary&nbsp;li=
brary offers me isn't guaranteed to exactly relate to what I want or be suf=
ficient. But&nbsp;with my proposal being an extension&nbsp;to yours (it wou=
ld seem),&nbsp;you can&nbsp;still&nbsp;use what your library provides if it=
 is sufficient or augment it if it isn't with mine.</div></blockquote><div =
dir=3D"ltr"><br>Here is my turn to request an example. I gave some examples=
 of why I think we only need tuple unpacking and a function to replace the =
typical use case of your construct. Now, I want an example of what your con=
struct can do that isn't covered by tuple unpacking + functions and that is=
 easier to read than a regular for loop.<br></div></div></div></blockquote>=
<div>&nbsp;</div><div>We already know what the abilities are of my proposal=
 are. I've just articulated them again anyway if we didn't, like continue e=
tc.:&nbsp;it's the same as the abilities of a regular for loop, plus the ab=
ilities of the enhanced loop - features we already have, but combined. That=
's it.</div><div><br></div><div>When you can add your tuple unpacking thing=
 in there too,&nbsp;my loop will be somewhat&nbsp;useful there too if you f=
eel&nbsp;you need it, nothing spectacular&nbsp;but it doesn't subtract from=
 it either. There isn't&nbsp;more of a&nbsp;story to tell here. We all know=
 what&nbsp;the loop features do, mine is just the superset. That's it.</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padd=
ing-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1p=
x; border-left-style: solid;"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D=
"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-=
width: 1px; border-left-style: solid;"><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb=
(204, 204, 204); border-left-width: 1px; border-left-style: solid;">Why don=
't I like your solution? First of all, I always found that the C-style for =
loop was no more than a hack around a regular while. </blockquote></blockqu=
ote></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-=
width: 1px; border-left-style: solid;"><div>&nbsp;</div><div>That's a bit h=
arsh. If&nbsp;it's true, people have used that hack in preference to while =
for many years and I still use for more than while by far in my code today.=
 That was as&nbsp;true for me&nbsp;in C&nbsp;as it is&nbsp;C++.</div></bloc=
kquote><div>&nbsp;<br>We use for loops because they are <i>a little bit cle=
aner</i> than plain while loops to iterate, but it does not offer much abst=
raction (I still don't find that harsh to call them a hack). However, more =
and more C++ people have started to request Python-like range, zip, reverse=
d and enumerate function to use in range-based for loops. People simply don=
't want to use indices when they don't need them, they want another abstrac=
tion level to hide indices and iterators, unless they are really needed. Py=
thon does not even have a regular for loop, its for loop is a foreach loop;=
 nobody ever asked for a C-style loop, it is simply uneeded. I know, I don'=
t stop talking about Python and we are in a C++ mailing list, but its itera=
ting tools are good enough to be used as examples, and modern C++ is more a=
bout iterators and less about indices anyway.<br></div></div></div></blockq=
uote><div>&nbsp;</div><div>Agreed. I haven't proposed anything that will st=
op the evolution of that. If you don't find the feature useful, you don't u=
se it and it doesn't force itself on you.</div><div><br></div><div>To digre=
ss, I actually think some of these ideas go too far and make some of this e=
asier than it actually is, whether it be "iterator" or&nbsp;the "C++ way" o=
r whatever. For instance, the new file system&nbsp;library has a recursive =
file system iterator that&nbsp;suggests you just go (something like):&nbsp;=
</div><div>for( recursive_file_system_iterator&nbsp;it; it !=3D end; ++it)<=
/div><div>{</div><div>&nbsp;puts(it-&gt;filename);<br>}</div><div><br></div=
><div>But in actual practice, it'll likely never ever be like that in pract=
ice because of the amount of error checking you actually need to process a =
whole file system taking into account file permissions etc. etc. The above =
loop would crash in two seconds in real life, yet I often see stuff suggest=
ing copy_directory(directory_iterator) blah blah is just as simple as it lo=
oks. But such idealised chaining doesn't actually work in practice when you=
 deal with things that fail. Which is nearly everything. Especially when a =
network or file system is in the way. So real life means a lot of this chai=
ned code that looks great in an example, often isn't real.</div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1e=
x; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-le=
ft-style: solid;"><div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left:=
 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border=
-left-style: solid;"><blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">The only=
 difference is the place of the declaration and of the increment, as well a=
s the scope of the declared variable (and we can get around that by putting=
 a while loop in a new scope). The range-based for loop offers a new level =
of abstraction, so I wouldn't want of a "new" loop that still forces me&nbs=
p;to write the iterator increment stuff by hand. </div></blockquote></block=
quote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
 padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-widt=
h: 1px; border-left-style: solid;"><div><br></div><div>Wait, wait. Where ha=
ve I ever mentioned something in my proposal that forces anything?</div></b=
lockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.=
8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-=
width: 1px; border-left-style: solid;"><div>Quite the contrary I've actuall=
y explained why alternative proposals&nbsp;are doing the forcing if anythin=
g so I'm not sure where you get this idea?</div></blockquote><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; =
border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-=
style: solid;"><div>All I've demonstrated is that a hybrid of the two loops=
 lets everybody get the best of both loops exactly so nobody is forced to d=
o anything, they just pick and mix.</div></blockquote><div>&nbsp;<br>You ar=
e right. My use of "force" wasn't for the better. What I meant is that I th=
ink that only one of the solutions to the typical problem (iterate with ind=
ex and elem) will be chosen in the end. Since, if accepted, your proposal w=
ould be considered the idiomatic way to do that, I would in the end be "for=
ced" to used it to write idiomatic C++ code.<br></div></div></div></blockqu=
ote><div><br></div><div>I don't agree.&nbsp;You've stretched your concern a=
bout my proposal too far in this suggestion in&nbsp;my opinion. There simpl=
y is no forcing here. Use the bits you need as you need them. Where it does=
n't make sense, don't. If you pick the right loop or tuple or whatever to b=
egin with for your solution,&nbsp;nobody is going to argue with you. It's n=
ot template wars here or nearly anything so complicated.</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex;=
 border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left=
-style: solid;"><div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1=
ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-l=
eft-style: solid;"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">At least, =
std::enumerate automagically produces the indices, we don't have to compute=
 them by hand.</div></blockquote></blockquote><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-col=
or: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">=
<div><br></div><div>Again, that assumes there is just one index, it's +1 or=
 that you even want to increment anything at all in the step.</div></blockq=
uote><div>&nbsp;<br>If we want something that is not "+1", the idiomatic C+=
+ way would be to write an iterator that does something else (and there are=
 several tools to efficiently write iterators, Boost.Iterator being one of =
them). Then, we apply "++" to the iterator.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;"><div dir=3D"ltr"> Moreover, while =
"enumerate" is easy to find with a searching tool, your proposed syntax is =
rather hard to find, and if one reads too fast, they may think it is a regu=
lar C-style for loop.<br></div></blockquote></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div><br></div><div>Is that a real argument? I've seen&nbsp;who=
le&nbsp;pages of&nbsp;C++ code that looks like C&nbsp;for that to be a worr=
y or any confusion! lol&nbsp;Only half the time does that bother me. That's=
 the real worry!! lol</div></blockquote><div><br>Half the time can already =
be pretty much of a concern. The search tool argument was already used as a=
 weakness for the static if proposal, so yeah, it may be a valid argument.<=
br></div></div></div></blockquote><div><br></div><div>I missed&nbsp;your po=
int about searching, I would agree with that statement but people should be=
 putting their loops into functions anyway that serve the purpose not just =
inline looping everywhere so your argument&nbsp;is&nbsp;overblown.</div><di=
v><br></div><div>The proof is that I've never ever search for a for as a ke=
yword search, who has? I search for find_customer or find_person or whateve=
r and the loop is inside that. Anyone who does different is in the wrong jo=
b&nbsp;and no enumerate is going to help them.</div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left:=
 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border=
-left-style: solid;"><div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-le=
ft: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bor=
der-left-style: solid;"><div>I don't think anyone has attacked this proposa=
l on substance yet, so&nbsp;I'm not&nbsp;concerned by that yet. If they suc=
ceed, I'll be happy, I just want a better mouse trap.</div><div>But to do t=
hat you've got to&nbsp;start talking features and examples that show that a=
nd also why this proposal can't augment the&nbsp;alternative too.</div><div=
>So far I'm still not seeing that.</div></blockquote><div><br>&nbsp;I don't=
 want to sound harsh again (or do I?) but there isn't that much substance i=
n the first place to attack. Your proposal is no more than a mere syntactic=
 enhancement and most (?) of us don't even see it as an enhancement. We pro=
vided an alternative for the most common use case, which can be used to imp=
rove other areas than foreach loops, and are still waiting for use cases an=
d are still waiting for examples of code where your proposal would make eno=
ugh of a difference to deserve its language change.<br></div></div></div></=
blockquote><div><br></div><div>You are right,&nbsp;this proposal isn't a pr=
oposal of massive substance, but I never suggested it was? It is&nbsp;what =
I've always maintained&nbsp;it was, a&nbsp;simple extension to graft&nbsp;t=
he features of the existing for loop&nbsp;onto the newer for loop&nbsp;to m=
ake&nbsp;the superset.</div><div><br></div><div>No mega examples are requir=
ed to demonstrate something so simple. Even less so when it's just the comb=
ination of two features we already have and that aren't hard to grasp to be=
gin with.</div><div><br></div><div>But when people are attacking that propo=
sal with,&nbsp;"it won't work" and "I don't like the syntax" and then "your=
 proposal is forcing me to do whatever" all I can do is answer that and say=
 what nonsense most of that is and that's what I've done.</div><div><br></d=
iv><div>And when you move on to (effectively saying)&nbsp;"I think some tup=
le thing is better", all I can do is say, fine, show me your tuple thing, b=
ut then the&nbsp;onus is on you to&nbsp;have examples&nbsp;to&nbsp;demonstr=
ate that because you're proposing something much more complicated than my p=
roposal; so you need the examples, not me.</div><div><br></div><div>So with=
 that all said,&nbsp;I think&nbsp;I've&nbsp;covered enough ground in this d=
iscussion about what&nbsp;my proposal is and isn't and cleared up&nbsp;a fe=
w of the&nbsp;mischaracterizations&nbsp;on that which might&nbsp;have confu=
se peopled. So&nbsp;I think my duty is done here. There&nbsp;should be&nbsp=
;sufficient information here now that&nbsp;I&nbsp;shouldn't&nbsp;need to ad=
d anything further for the time being, if at all.</div><div><br></div><div>=
The proposal&nbsp;appeals&nbsp;or non appeal is better now left to&nbsp;int=
erested or disinterested parties to discuss it between them.&nbsp;I'll just=
 watch&nbsp;how&nbsp;that&nbsp;pans out for a while. It's not an earth shat=
tering proposal so I don't expect much. But all the info is here now. It ju=
st needs&nbsp;to sink or swim on it's own.</div><div><br></div><div>Thanks&=
nbsp;for the discussion. </div><div><br></div><div>The tuple stuff&nbsp;loo=
ks interesting&nbsp;but it's really separate to my proposal as my proposal&=
nbsp;here isn't dependent on them at all.&nbsp;So I'll be keen to follow th=
at&nbsp;more in the appropriate threads I've seen pop up. I admit I'm&nbsp;=
not keen on tuples for the reasons I've given but I am keen to have that vi=
ew swayed so it will be&nbsp;interesting for me. Thanks for the maths domai=
n suggestion about them. That at least gives me a&nbsp;bit of an&nbsp;insig=
ht&nbsp;into why&nbsp;the fascination with them is so high in some sections=
 of the community&nbsp;and less in others. I&nbsp;wonder if there&nbsp;are =
any math's wizards who are less&nbsp;than enamoured by tuples. I look forwa=
rd to hearing either type of person add their views in those threads. Inter=
esting stuff.</div><div><br></div><div>Thanks</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_780_13855721.1401459359770--

.

On 2014-05-30 06:23, morwenn29@gmail.com wrote:
> Python does not even have a regular for loop, its for loop is a
> foreach loop; nobody ever asked for a C-style loop, it is simply
> uneeded.

In fairness, 'for n in xrange(...)' basically *is* the "regular" for
loop. And, for that matter, you could write most things that a "regular"
for loop would do (including more esoteric things) with a locally
defined generator function.

And if we could just get index_range (or count, or whatever) into the
standard library, then C++ would hardly need them either :-).

(Already I would much rather write 'for(auto x : range(count))' than an
old-style loop. It's just so much more natural to read, and I don't need
to write the usual start-at-zero, increment-by-one boilerplate.)

--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

Foreach syntax give you enough freedom to do anointing you want and made it=
=20
simple. You can create helper function that return fat iterator that store=
=20
original one and current loop position:
for(auto a : Index(vec)) do_something(a.i, a.v);
different start point or step?
for(auto a : Index(vec, 1, 2)) do_something(a.i, a.v); // i =3D 1, 3, 5, 7,=
=20
....
Nest it?
for(auto a : Index(Index(vec), 1, 2)) do_something(a.i, a.v.v); // i =3D 1,=
=20
3, 5, 7, ...; v.i =3D 0, 1, 2, 3, ...
If you very fancy you could even add lambda to it:
for(auto a : Index(vec, 0, [](int& i) { i -=3D 1; } )) do_something(a.i, a.=
v);=20
// i =3D 0, -1, -2, -3, ...;

Implementing this function isnt any problem in C++11, you can have it=20
today, not waiting for C++17.
Another problem with changing syntax is compiler support, it can end up=20
that compiler what you use or need be compatible, will not support this new=
=20
feature.
You will force to not us it at all. If new syntax dont give us something=20
new or simplify harder tasks, nobody will be interesting in adding this.
C++11 foreach syntax give us that.

On Friday, May 30, 2014 4:16:00 PM UTC+2, gmis...@gmail.com wrote:
>
>
>
> On Friday, May 30, 2014 10:23:14 PM UTC+12, morw...@gmail.com wrote:
>>
>> Le vendredi 30 mai 2014 00:54:48 UTC+2, gmis...@gmail.com a =C3=A9crit :
>>>
>>>
>>>
>>> On Friday, May 30, 2014 7:25:08 AM UTC+12, morw...@gmail.com wrote:
>>>>
>>>> I have some things to add to the conversation: first of all, I don't=
=20
>>>> like the syntax. At all. As many people here,=20
>>>>
>>>
>>> Yes many. But we really need to get beyond the focus on the=20
>>> syntax while people are not showing example alternative code or=20
>>> libraries that demonstrably provides the same feature set I have mentio=
ned,=20
>>> that we all know the original for loop provides.
>>>
>>
>> The example given by another answer here is an exact alternative code=20
>> that works just as well:
>>
>> {
>>     size_t i =3D 0;
>>     for (const auto& e : v) do_something(i++, e);
>> }
>>
>
> Yes it works ok.  But you miss my point about what I was answering. My=20
> point was that we already had the potential to do this:
> { int I; for (I =3D 0; I < 10;++I) do_something() }
> when despite that, the committee later saw fit to introduce a small=20
> language change to allow simply this:
> for (int I =3D0; I < 10; ++I) do_something();
> My change is for much the same thing for the new for loop.
>
> So I was making the point to the person who was arguing with such=20
> confidence that no one would/should change the language for such a small=
=20
> change when it just enables something that we can already do, to not be s=
o=20
> premature in that confidence about what people or the committee might or=
=20
> might not do because history has already shown they might vote for it=20
> because they did before in very much these same circumstances.
>
> I'm not saying they would again, but that was my point. I see nothing=20
> wrong in that point of view.
>
>> =20
>>>
>>>> I prefere the tuple unpacking and std::enumerate solution. I agree tha=
t=20
>>>> it is subjective before anything else, but I just don't like it, sorry=
 for=20
>>>> that :(. However, no matter how subjective something is, if 90% of the=
=20
>>>> people don't like a solution and prefer an alternative, the alternativ=
e=20
>>>> will probably be chosen instead.
>>>>
>>>
>>> I don't quite see how tuple unpacking  relates to this, it may do, but=
=20
>>> that's exactly why example code is needed, to demonstrate that part too=
..
>>>
>>
>> A simple example of the same example with Python then:
>>
>> for i, e in enumerate(v):
>>     do_something(i, e)
>>
>> Here, enumerate returns what would be a tuple<int, T> which is directly=
=20
>> unpacked into i and e (as it was said, the tuple is actually hidden by t=
he=20
>> tuple unpacking syntax). This allows to write something that is both cle=
ar=20
>> and clean. enumerate being a library function, the only change to the=20
>> language is tuple unpacking, which is often used on the client side when=
 a=20
>> function returns a tuple (in other words, whenever a function has severa=
l=20
>> values to return). Sometimes, we can't return a structure that makes sen=
se=20
>> from a function, so we return a pair, a small array or a tuple. For=20
>> example, it wouldn't make sense to have a specific structure to return f=
rom=20
>> a quadratic equation solver since there wouldn't be any meaningful name,=
 so=20
>> we return a tuple. Tuple unpacking would allow to write something along =
the=20
>> lines of:
>>
>> auto (res1, res2) =3D quadratic(a, b, c);
>>
>> There are countless examples of function in mathematics that return=20
>> multiple values that relate with each other but that are still "some=20
>> values" and not "some values that form a meaningful structure". That is =
why=20
>> mathematical scripting languages allow their functions to "return multip=
le=20
>> values", which be seen as an unpacked tuple of values. While we could tr=
y=20
>> to allow C++ functions to return multiple values, we would have to defin=
e=20
>> what it means, so it's easier to return tuples and allow them to be=20
>> unpacked.
>>
>> This paragraph may seem a little bit off-topic, but it at least gives a=
=20
>> reason why I want tuple unpacking, and probably why other people want tu=
ple=20
>> unpacking too. That also gives you the example code you wanted. I will s=
kip=20
>> your other questions about tuple unpacking since I think that I just=20
>> answered them :)
>>
>
> You may be right I don't work in a mathematical heavy domain so I don't=
=20
> see that need often. Mostly I see people using tuples like how I see pair=
=20
> gets overused. People think they just want to return a couple of values s=
o=20
> they hijack pair, then forever more I'm looking at .first .second. And=20
> that's never useful. It's always really x, y or something where a name=20
> would convey something. I see people abusing tuple the same way, get<n> i=
s=20
> never more useful than the name and usually a type name conveys even more=
=20
> with that. That's why I find std::tuple mostly useless and state that=20
> something better is needed. What that better is, I don't know yet. I just=
=20
> hope whatever it is, it doesn't encourage tuples to be used where a real=
=20
> type is more appropriate. That's another reason why I was keen to see rea=
l=20
> examples of tuple use. When you just see res1, res2, it's hard to know=20
> people are trying to achieve with them.
>
> With my for loop construct, everyone knows what that's all about because=
=20
> it's the same for loop concept as we already have, it needs no introducti=
on.
> =20
>
>>
>> Yes, but a single index isn't the only thing people track or do in their=
=20
>>> step and it doesn't have to be + 1 or even an increment at all.=20
>>>
>>
>> I agree that many people do many things in the step part of the for-loop=
..=20
>> However, putting things other than an increment in the step part is ofte=
n=20
>> viewed as bad practice. I can't find a suitable reference to support tha=
t,=20
>> but I often read "the step part of the loop exists to put the step in, i=
f=20
>> you have some other things to put in it, put them at the end of the bloc=
k".=20
>> We could probably write a while for loop and put almost anything in the=
=20
>> step part of the loop, separated by commas. Is it good practice? I don't=
=20
>> think so. IMHO, it is close to using operator&& instead of a if statemen=
t:=20
>> operator&& is great in a condition, can be used almost anywhere, but we=
=20
>> don't want to use it everywhere.
>>
>
> I partly agree, but that's not the only factor. "continue" doesn't hit th=
e=20
> end of the block and my examples were demonstrating that deficiency. And=
=20
> for simple increments that aren't a step of 1, it's handy to have the=20
> options to get the best of both worlds where you use it carefully.  Seein=
g=20
> the step at the top is a nice thing. These are all features of my proposa=
l=20
> never the less.
>
>>
>> What your imaginary library offers me isn't guaranteed to exactly relate=
=20
>>> to what I want or be sufficient. But with my proposal being an extensio=
n to=20
>>> yours (it would seem), you can still use what your library provides if =
it=20
>>> is sufficient or augment it if it isn't with mine.
>>>
>>
>> Here is my turn to request an example. I gave some examples of why I=20
>> think we only need tuple unpacking and a function to replace the typical=
=20
>> use case of your construct. Now, I want an example of what your construc=
t=20
>> can do that isn't covered by tuple unpacking + functions and that is eas=
ier=20
>> to read than a regular for loop.
>>
> =20
> We already know what the abilities are of my proposal are. I've just=20
> articulated them again anyway if we didn't, like continue etc.: it's the=
=20
> same as the abilities of a regular for loop, plus the abilities of the=20
> enhanced loop - features we already have, but combined. That's it.
>
> When you can add your tuple unpacking thing in there too, my loop will be=
=20
> somewhat useful there too if you feel you need it, nothing spectacular bu=
t=20
> it doesn't subtract from it either. There isn't more of a story to tell=
=20
> here. We all know what the loop features do, mine is just the superset.=
=20
> That's it.
>
>>
>> Why don't I like your solution? First of all, I always found that the=20
>>>> C-style for loop was no more than a hack around a regular while.=20
>>>
>>> =20
>>> That's a bit harsh. If it's true, people have used that hack in=20
>>> preference to while for many years and I still use for more than while =
by=20
>>> far in my code today. That was as true for me in C as it is C++.
>>>
>> =20
>> We use for loops because they are *a little bit cleaner* than plain=20
>> while loops to iterate, but it does not offer much abstraction (I still=
=20
>> don't find that harsh to call them a hack). However, more and more C++=
=20
>> people have started to request Python-like range, zip, reversed and=20
>> enumerate function to use in range-based for loops. People simply don't=
=20
>> want to use indices when they don't need them, they want another=20
>> abstraction level to hide indices and iterators, unless they are really=
=20
>> needed. Python does not even have a regular for loop, its for loop is a=
=20
>> foreach loop; nobody ever asked for a C-style loop, it is simply uneeded=
.. I=20
>> know, I don't stop talking about Python and we are in a C++ mailing list=
,=20
>> but its iterating tools are good enough to be used as examples, and mode=
rn=20
>> C++ is more about iterators and less about indices anyway.
>>
> =20
> Agreed. I haven't proposed anything that will stop the evolution of that.=
=20
> If you don't find the feature useful, you don't use it and it doesn't for=
ce=20
> itself on you.
>
> To digress, I actually think some of these ideas go too far and make some=
=20
> of this easier than it actually is, whether it be "iterator" or the "C++=
=20
> way" or whatever. For instance, the new file system library has a recursi=
ve=20
> file system iterator that suggests you just go (something like):=20
> for( recursive_file_system_iterator it; it !=3D end; ++it)
> {
>  puts(it->filename);
> }
>
> But in actual practice, it'll likely never ever be like that in practice=
=20
> because of the amount of error checking you actually need to process a=20
> whole file system taking into account file permissions etc. etc. The abov=
e=20
> loop would crash in two seconds in real life, yet I often see stuff=20
> suggesting copy_directory(directory_iterator) blah blah is just as simple=
=20
> as it looks. But such idealised chaining doesn't actually work in practic=
e=20
> when you deal with things that fail. Which is nearly everything. Especial=
ly=20
> when a network or file system is in the way. So real life means a lot of=
=20
> this chained code that looks great in an example, often isn't real.
>
>>
>> The only difference is the place of the declaration and of the increment=
,=20
>>>> as well as the scope of the declared variable (and we can get around t=
hat=20
>>>> by putting a while loop in a new scope). The range-based for loop offe=
rs a=20
>>>> new level of abstraction, so I wouldn't want of a "new" loop that stil=
l=20
>>>> forces me to write the iterator increment stuff by hand.=20
>>>>
>>>
>>> Wait, wait. Where have I ever mentioned something in my proposal that=
=20
>>> forces anything?
>>>
>> Quite the contrary I've actually explained why alternative proposals are=
=20
>>> doing the forcing if anything so I'm not sure where you get this idea?
>>>
>> All I've demonstrated is that a hybrid of the two loops lets everybody=
=20
>>> get the best of both loops exactly so nobody is forced to do anything, =
they=20
>>> just pick and mix.
>>>
>> =20
>> You are right. My use of "force" wasn't for the better. What I meant is=
=20
>> that I think that only one of the solutions to the typical problem (iter=
ate=20
>> with index and elem) will be chosen in the end. Since, if accepted, your=
=20
>> proposal would be considered the idiomatic way to do that, I would in th=
e=20
>> end be "forced" to used it to write idiomatic C++ code.
>>
>
> I don't agree. You've stretched your concern about my proposal too far in=
=20
> this suggestion in my opinion. There simply is no forcing here. Use the=
=20
> bits you need as you need them. Where it doesn't make sense, don't. If yo=
u=20
> pick the right loop or tuple or whatever to begin with for your=20
> solution, nobody is going to argue with you. It's not template wars here =
or=20
> nearly anything so complicated.
>
>>
>> At least, std::enumerate automagically produces the indices, we don't=20
>>>> have to compute them by hand.
>>>>
>>>
>>> Again, that assumes there is just one index, it's +1 or that you even=
=20
>>> want to increment anything at all in the step.
>>>
>> =20
>> If we want something that is not "+1", the idiomatic C++ way would be to=
=20
>> write an iterator that does something else (and there are several tools =
to=20
>> efficiently write iterators, Boost.Iterator being one of them). Then, we=
=20
>> apply "++" to the iterator.
>>
>> Moreover, while "enumerate" is easy to find with a searching tool, your=
=20
>>>> proposed syntax is rather hard to find, and if one reads too fast, the=
y may=20
>>>> think it is a regular C-style for loop.
>>>>
>>>
>>> Is that a real argument? I've seen whole pages of C++ code that looks=
=20
>>> like C for that to be a worry or any confusion! lol Only half the time =
does=20
>>> that bother me. That's the real worry!! lol
>>>
>>
>> Half the time can already be pretty much of a concern. The search tool=
=20
>> argument was already used as a weakness for the static if proposal, so=
=20
>> yeah, it may be a valid argument.
>>
>
> I missed your point about searching, I would agree with that statement bu=
t=20
> people should be putting their loops into functions anyway that serve the=
=20
> purpose not just inline looping everywhere so your argument is overblown.
>
> The proof is that I've never ever search for a for as a keyword search,=
=20
> who has? I search for find_customer or find_person or whatever and the lo=
op=20
> is inside that. Anyone who does different is in the wrong job and no=20
> enumerate is going to help them.
>
>
>> I don't think anyone has attacked this proposal on substance yet, so I'm=
=20
>>> not concerned by that yet. If they succeed, I'll be happy, I just want =
a=20
>>> better mouse trap.
>>> But to do that you've got to start talking features and examples that=
=20
>>> show that and also why this proposal can't augment the alternative too.
>>> So far I'm still not seeing that.
>>>
>>
>>  I don't want to sound harsh again (or do I?) but there isn't that much=
=20
>> substance in the first place to attack. Your proposal is no more than a=
=20
>> mere syntactic enhancement and most (?) of us don't even see it as an=20
>> enhancement. We provided an alternative for the most common use case, wh=
ich=20
>> can be used to improve other areas than foreach loops, and are still=20
>> waiting for use cases and are still waiting for examples of code where y=
our=20
>> proposal would make enough of a difference to deserve its language chang=
e.
>>
>
> You are right, this proposal isn't a proposal of massive substance, but I=
=20
> never suggested it was? It is what I've always maintained it was, a simpl=
e=20
> extension to graft the features of the existing for loop onto the newer f=
or=20
> loop to make the superset.
>
> No mega examples are required to demonstrate something so simple. Even=20
> less so when it's just the combination of two features we already have an=
d=20
> that aren't hard to grasp to begin with.
>
> But when people are attacking that proposal with, "it won't work" and "I=
=20
> don't like the syntax" and then "your proposal is forcing me to do=20
> whatever" all I can do is answer that and say what nonsense most of that =
is=20
> and that's what I've done.
>
> And when you move on to (effectively saying) "I think some tuple thing is=
=20
> better", all I can do is say, fine, show me your tuple thing, but then=20
> the onus is on you to have examples to demonstrate that because you're=20
> proposing something much more complicated than my proposal; so you need t=
he=20
> examples, not me.
>
> So with that all said, I think I've covered enough ground in this=20
> discussion about what my proposal is and isn't and cleared up a few of=20
> the mischaracterizations on that which might have confuse peopled. So I=
=20
> think my duty is done here. There should be sufficient information here n=
ow=20
> that I shouldn't need to add anything further for the time being, if at a=
ll.
>
> The proposal appeals or non appeal is better now left to interested or=20
> disinterested parties to discuss it between them. I'll just=20
> watch how that pans out for a while. It's not an earth shattering proposa=
l=20
> so I don't expect much. But all the info is here now. It just needs to si=
nk=20
> or swim on it's own.
>
> Thanks for the discussion.=20
>
> The tuple stuff looks interesting but it's really separate to my proposal=
=20
> as my proposal here isn't dependent on them at all. So I'll be keen to=20
> follow that more in the appropriate threads I've seen pop up. I admit=20
> I'm not keen on tuples for the reasons I've given but I am keen to have=
=20
> that view swayed so it will be interesting for me. Thanks for the maths=
=20
> domain suggestion about them. That at least gives me a bit of=20
> an insight into why the fascination with them is so high in some sections=
=20
> of the community and less in others. I wonder if there are any math's=20
> wizards who are less than enamoured by tuples. I look forward to hearing=
=20
> either type of person add their views in those threads. Interesting stuff=
..
>
> Thanks
>

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

<div dir=3D"ltr">Foreach syntax give you enough freedom to do anointing you=
 want and made
 it simple. You can create helper function that return fat iterator that
 store original one and current loop position:<br><div class=3D"prettyprint=
" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187=
, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #008;" class=3D"styled-by-prettify">for</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> a </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Index</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">vec</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">))</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> do_</span><code class=3D"prettyprin=
t"><code class=3D"prettyprint"><code class=3D"prettyprint"><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">something</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify"></span></code></code></code><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: #6=
60;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">i</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">v</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></d=
iv>different start point or step?<br><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><code class=3D"prettyprint"><code=
 class=3D"prettyprint"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">for</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> a </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">Index</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">vec, 1, 2</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">))</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> do_something</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">i</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">v</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> // i =3D 1, 3, 5, 7, ...</span></code></code><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify"></span></div></code></div>Nest it?<b=
r><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250);=
 border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; =
word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpretty=
print"><code class=3D"prettyprint"><code class=3D"prettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">for</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> a </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
Index</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an></code></code><code class=3D"prettyprint"><code class=3D"prettyprint"><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"><code class=3D"pret=
typrint"><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"=
styled-by-prettify"></span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Index</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">vec<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span></c=
ode></code></span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>, 1, 2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">))<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> do_</span>=
</code></code><code class=3D"prettyprint"><code class=3D"prettyprint"><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><code class=3D"prettyp=
rint"><code class=3D"prettyprint"><code class=3D"prettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">something</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"></span></code></code></code>=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">a</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">i</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-b=
y-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">v.v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> // i =3D 1,=
 3, 5, 7, ...; v.</span></code></code><span style=3D"color: #660;" class=3D=
"styled-by-prettify"></span>i =3D 0, 1, 2, 3, ...<br></div></code></div>If =
you very fancy you could even add lambda to it:<br><div class=3D"prettyprin=
t" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 18=
7, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><code class=3D"pret=
typrint"><code class=3D"prettyprint"><code class=3D"prettyprint"><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">for</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> a </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>Index</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan></code></code></code><code class=3D"prettyprint"><code class=3D"prettyp=
rint"><code class=3D"prettyprint"><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><code class=3D"prettyprint"><code class=3D"prettyprint"><c=
ode class=3D"prettyprint"><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><code class=3D"prettyprint"><code class=3D"prettyprint"><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify"></span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">vec</span></code></code></span></code=
></code></code></span></code></code></code>, 0, [](int&amp; i) { i -=3D 1; =
} ))<code class=3D"prettyprint"><code class=3D"prettyprint"><code class=3D"=
prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify"> do_=
</span></code></code></code><code class=3D"prettyprint"><code class=3D"pret=
typrint"><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><code class=3D"prettyprint"><code class=3D"prettyprint"=
><code class=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">something</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify"></span></code></code></code></span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">a</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">i</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 s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">v</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">); </span></code></code></code><code class=
=3D"prettyprint"><code class=3D"prettyprint"><code class=3D"prettyprint"><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">// i =3D 0, -1, -2,=
 -3, ...;</span></code></code></code></div></code></div><br>Implementing th=
is function isnt any problem in C++11, you can have it today, not waiting f=
or C++17.<br>Another
 problem with changing syntax is compiler support, it can end up that=20
compiler what you use or need be compatible, will not support this new=20
feature.<br>You will force to not us it at all. If new syntax dont give=20
us something new or simplify harder tasks, nobody will be interesting in
 adding this.<br>C++11 foreach syntax give us that.<br><br>On Friday, May 3=
0, 2014 4:16:00 PM UTC+2, gmis...@gmail.com wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><br><br>On Friday, May 30, 2014 10:23:=
14 PM UTC+12, <a>morw...@gmail.com</a> wrote:<blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rg=
b(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"l=
tr">Le vendredi 30 mai 2014 00:54:48 UTC+2, <a>gmis...@gmail.com</a> a =C3=
=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-widt=
h:1px;border-left-style:solid"><div dir=3D"ltr"><br><br>On Friday, May 30, =
2014 7:25:08 AM UTC+12, <a>morw...@gmail.com</a> wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-lef=
t-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><di=
v dir=3D"ltr">I have some things to add to the conversation: first of all, =
I don't like the syntax. At all. As many people here, </div></blockquote><d=
iv><br></div><div>Yes many. But we really need to get beyond the focus on t=
he syntax&nbsp;while&nbsp;people are not showing&nbsp;example alternative c=
ode or libraries&nbsp;that demonstrably provides the same feature set I hav=
e mentioned, that we all know the original for loop provides.<br></div></di=
v></blockquote><div><br>The example given by another answer here is an exac=
t alternative code that works just as well:<br><br><div style=3D"margin-lef=
t:40px"><div style=3D"border:1px solid rgb(187,187,187);background-color:rg=
b(250,250,250)"><code><div><span style=3D"color:rgb(102,102,0)">{</span><sp=
an style=3D"color:rgb(0,0,0)"><br>&nbsp; &nbsp; size_t i </span><span style=
=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> </spa=
n><span style=3D"color:rgb(0,102,102)">0</span><span style=3D"color:rgb(102=
,102,0)">;</span><span style=3D"color:rgb(0,0,0)"><br>&nbsp; &nbsp; </span>=
<span style=3D"color:rgb(0,0,136)">for</span><span style=3D"color:rgb(0,0,0=
)"> </span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"colo=
r:rgb(0,0,136)">const</span><span style=3D"color:rgb(0,0,0)"> </span><span =
style=3D"color:rgb(0,0,136)">auto</span><span style=3D"color:rgb(102,102,0)=
">&amp;</span><span style=3D"color:rgb(0,0,0)"> e </span><span style=3D"col=
or:rgb(102,102,0)">:</span><span style=3D"color:rgb(0,0,0)"> v</span><span =
style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> do=
_something</span><span style=3D"color:rgb(102,102,0)">(</span><span style=
=3D"color:rgb(0,0,0)">i</span><span style=3D"color:rgb(102,102,0)">++,</spa=
n><span style=3D"color:rgb(0,0,0)"> e</span><span style=3D"color:rgb(102,10=
2,0)">);</span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"c=
olor:rgb(102,102,0)">}</span><span style=3D"color:rgb(0,0,0)"><br></span></=
div></code></div></div></div></div></blockquote><div><br></div><div>Yes it =
works ok.&nbsp; But&nbsp;you miss my point about what I was answering.&nbsp=
;My point was that we already had the potential to do this:</div><div>{ int=
 I; for (I =3D 0; I &lt; 10;++I) do_something() }</div><div>when despite th=
at, the committee later saw fit&nbsp;to introduce a small language change t=
o allow simply this:</div><div>for (int I =3D0; I &lt; 10; ++I) do_somethin=
g();</div><div>My change is for much the same thing for the new for loop.</=
div><div><br></div><div>So I was&nbsp;making the&nbsp;point&nbsp;to the per=
son&nbsp;who was arguing with such confidence that&nbsp;no one&nbsp;would/s=
hould&nbsp;change the language&nbsp;for such a small change&nbsp;when it ju=
st enables something that we can already do, to&nbsp;not be so premature in=
 that confidence about what people or the committee&nbsp;might or might not=
 do because history has already shown they might vote for it because they d=
id before in&nbsp;very much&nbsp;these same circumstances.</div><div><br></=
div><div>I'm not saying they would again, but that was my point.&nbsp;I see=
 nothing wrong in that point of view.</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(=
204,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddi=
ng-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border=
-left-style:solid"><div dir=3D"ltr"><div></div><div>&nbsp;</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;b=
order-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:s=
olid"><div dir=3D"ltr">I prefere the tuple unpacking and std::enumerate sol=
ution. I agree that it is subjective before anything else, but I just don't=
 like it, sorry for that :(. However, no matter how subjective something is=
, if 90% of the people don't like a solution and prefer an alternative, the=
 alternative will probably be chosen instead.<br></div></blockquote><div><b=
r></div><div>I&nbsp;don't quite see how tuple unpacking&nbsp; relates to th=
is, it may do, but that's exactly why example code is needed, to demonstrat=
e that part too.<br></div></div></blockquote><div dir=3D"ltr"><br>A simple =
example of the same example with Python then:<br><br><div style=3D"margin-l=
eft:40px"><div style=3D"border:1px solid rgb(187,187,187);background-color:=
rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,136)">for</span><=
span style=3D"color:rgb(0,0,0)"> i</span><span style=3D"color:rgb(102,102,0=
)">,</span><span style=3D"color:rgb(0,0,0)"> e </span><span style=3D"color:=
rgb(0,0,136)">in</span><span style=3D"color:rgb(0,0,0)"> enumerate</span><s=
pan style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)"=
>v</span><span style=3D"color:rgb(102,102,0)">):</span><span style=3D"color=
:rgb(0,0,0)"><br>&nbsp; &nbsp; do_something</span><span style=3D"color:rgb(=
102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">i</span><span style=3D=
"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> e</span><s=
pan style=3D"color:rgb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"=
><br></span></div></code></div><br></div>Here, enumerate returns what would=
 be a tuple&lt;int, T&gt; which is directly unpacked into i and e (as it wa=
s said, the tuple is actually hidden by the tuple unpacking syntax). This a=
llows to write something that is both clear and clean. enumerate being a li=
brary function, the only change to the language is tuple unpacking, which i=
s often used on the client side when a function returns a tuple (in other w=
ords, whenever a function has several values to return). Sometimes, we can'=
t return a structure that makes sense from a function, so we return a pair,=
 a small array or a tuple. For example, it wouldn't make sense to have a sp=
ecific structure to return from a quadratic equation solver since there wou=
ldn't be any meaningful name, so we return a tuple. Tuple unpacking would a=
llow to write something along the lines of:<br><br><div style=3D"border:1px=
 solid rgb(187,187,187);margin-left:40px;background-color:rgb(250,250,250)"=
><code><div><span style=3D"color:rgb(0,0,136)">auto</span><span style=3D"co=
lor:rgb(0,0,0)"> </span><span style=3D"color:rgb(102,102,0)">(</span><span =
style=3D"color:rgb(0,0,0)">res1</span><span style=3D"color:rgb(102,102,0)">=
,</span><span style=3D"color:rgb(0,0,0)"> res2</span><span style=3D"color:r=
gb(102,102,0)">)</span><span style=3D"color:rgb(0,0,0)"> </span><span style=
=3D"color:rgb(102,102,0)">=3D</span><span style=3D"color:rgb(0,0,0)"> quadr=
atic</span><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"colo=
r:rgb(0,0,0)">a</span><span style=3D"color:rgb(102,102,0)">,</span><span st=
yle=3D"color:rgb(0,0,0)"> b</span><span style=3D"color:rgb(102,102,0)">,</s=
pan><span style=3D"color:rgb(0,0,0)"> c</span><span style=3D"color:rgb(102,=
102,0)">);</span><span style=3D"color:rgb(0,0,0)"><br></span></div></code><=
/div><br>There are countless examples of function in mathematics that retur=
n multiple values that relate with each other but that are still "some valu=
es" and not "some values that form a meaningful structure". That is why mat=
hematical scripting languages allow their functions to "return multiple val=
ues", which be seen as an unpacked tuple of values. While we could try to a=
llow C++ functions to return multiple values, we would have to define what =
it means, so it's easier to return tuples and allow them to be unpacked.<br=
><br>This paragraph may seem a little bit off-topic, but it at least gives =
a reason why I want tuple unpacking, and probably why other people want tup=
le unpacking too. That also gives you the example code you wanted. I will s=
kip your other questions about tuple unpacking since I think that I just an=
swered them :)<br></div></div></blockquote><div><br></div><div>You may be r=
ight I don't work in a mathematical heavy domain so I don't see that need o=
ften. Mostly I see people using tuples like how&nbsp;I see pair gets overus=
ed. People think they just want to return a couple of values so they hijack=
&nbsp;pair, then forever more I'm looking at .first .second. And that's nev=
er useful. It's always really x, y or something where a name would convey s=
omething. I see people abusing tuple the same way, get&lt;n&gt; is never mo=
re useful than the name and usually a type name conveys even more with that=
.. That's why I find std::tuple mostly&nbsp;useless and state that something=
 better is needed. What that better is, I don't know yet. I just hope&nbsp;=
whatever it is, it&nbsp;doesn't encourage tuples to be used where a real ty=
pe is more appropriate. That's another reason why I was keen to see real ex=
amples of tuple use. When you just see res1, res2, it's hard to know people=
 are trying to achieve with them.</div><div><br></div><div>With my for loop=
 construct, everyone knows what that's all about because it's the same for =
loop concept as we already have, it needs no introduction.</div><div>&nbsp;=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;p=
adding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bo=
rder-left-style:solid"><div dir=3D"ltr"><div dir=3D"ltr"><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-le=
ft:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left=
-style:solid"><div>Yes,&nbsp;but&nbsp;a single&nbsp;index isn't the only th=
ing people track or do in their step and it doesn't have to be&nbsp;+ 1&nbs=
p;or even an increment at all. </div></blockquote><div><br>I agree that man=
y people do many things in the step part of the for-loop. However, putting =
things other than an increment in the step part is often viewed as bad prac=
tice. I can't find a suitable reference to support that, but I often read "=
the step part of the loop exists to put the step in, if you have some other=
 things to put in it, put them at the end of the block". We could probably =
write a while for loop and put almost anything in the step part of the loop=
, separated by commas. Is it good practice? I don't think so. IMHO, it is c=
lose to using operator&amp;&amp; instead of a if statement: operator&amp;&a=
mp; is great in a condition, can be used almost anywhere, but we don't want=
 to use it everywhere.<br></div></div></div></blockquote><div><br></div><di=
v>I partly agree,&nbsp;but that's not the only factor. "continue" doesn't h=
it the end of the block and my examples were&nbsp;demonstrating that defici=
ency.&nbsp;And for simple increments that aren't a step of 1, it's handy to=
 have the options to get the best of both worlds where you use it carefully=
..&nbsp;&nbsp;Seeing the step at the top is a nice thing. These are&nbsp;all=
 features of my proposal never the less.</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:r=
gb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"=
ltr"><div dir=3D"ltr"><div><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,20=
4,204);border-left-width:1px;border-left-style:solid"><div>What&nbsp;your i=
maginary&nbsp;library offers me isn't guaranteed to exactly relate to what =
I want or be sufficient. But&nbsp;with my proposal being an extension&nbsp;=
to yours (it would seem),&nbsp;you can&nbsp;still&nbsp;use what your librar=
y provides if it is sufficient or augment it if it isn't with mine.</div></=
blockquote><div dir=3D"ltr"><br>Here is my turn to request an example. I ga=
ve some examples of why I think we only need tuple unpacking and a function=
 to replace the typical use case of your construct. Now, I want an example =
of what your construct can do that isn't covered by tuple unpacking + funct=
ions and that is easier to read than a regular for loop.<br></div></div></d=
iv></blockquote><div>&nbsp;</div><div>We already know what the abilities ar=
e of my proposal are. I've just articulated them again anyway if we didn't,=
 like continue etc.:&nbsp;it's the same as the abilities of a regular for l=
oop, plus the abilities of the enhanced loop - features we already have, bu=
t combined. That's it.</div><div><br></div><div>When you can add your tuple=
 unpacking thing in there too,&nbsp;my loop will be somewhat&nbsp;useful th=
ere too if you feel&nbsp;you need it, nothing spectacular&nbsp;but it doesn=
't subtract from it either. There isn't&nbsp;more of a&nbsp;story to tell h=
ere. We all know what&nbsp;the loop features do, mine is just the superset.=
 That's it.</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-w=
idth:1px;border-left-style:solid"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-widt=
h:1px;border-left-style:solid"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204)=
;border-left-width:1px;border-left-style:solid">Why don't I like your solut=
ion? First of all, I always found that the C-style for loop was no more tha=
n a hack around a regular while. </blockquote></blockquote></div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;=
border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:=
solid"><div>&nbsp;</div><div>That's a bit harsh. If&nbsp;it's true, people =
have used that hack in preference to while for many years and I still use f=
or more than while by far in my code today. That was as&nbsp;true for me&nb=
sp;in C&nbsp;as it is&nbsp;C++.</div></blockquote><div>&nbsp;<br>We use for=
 loops because they are <i>a little bit cleaner</i> than plain while loops =
to iterate, but it does not offer much abstraction (I still don't find that=
 harsh to call them a hack). However, more and more C++ people have started=
 to request Python-like range, zip, reversed and enumerate function to use =
in range-based for loops. People simply don't want to use indices when they=
 don't need them, they want another abstraction level to hide indices and i=
terators, unless they are really needed. Python does not even have a regula=
r for loop, its for loop is a foreach loop; nobody ever asked for a C-style=
 loop, it is simply uneeded. I know, I don't stop talking about Python and =
we are in a C++ mailing list, but its iterating tools are good enough to be=
 used as examples, and modern C++ is more about iterators and less about in=
dices anyway.<br></div></div></div></blockquote><div>&nbsp;</div><div>Agree=
d. I haven't proposed anything that will stop the evolution of that. If you=
 don't find the feature useful, you don't use it and it doesn't force itsel=
f on you.</div><div><br></div><div>To digress, I actually think some of the=
se ideas go too far and make some of this easier than it actually is, wheth=
er it be "iterator" or&nbsp;the "C++ way" or whatever. For instance, the ne=
w file system&nbsp;library has a recursive file system iterator that&nbsp;s=
uggests you just go (something like):&nbsp;</div><div>for( recursive_file_s=
ystem_<wbr>iterator&nbsp;it; it !=3D end; ++it)</div><div>{</div><div>&nbsp=
;puts(it-&gt;filename);<br>}</div><div><br></div><div>But in actual practic=
e, it'll likely never ever be like that in practice because of the amount o=
f error checking you actually need to process a whole file system taking in=
to account file permissions etc. etc. The above loop would crash in two sec=
onds in real life, yet I often see stuff suggesting copy_directory(director=
y_<wbr>iterator) blah blah is just as simple as it looks. But such idealise=
d chaining doesn't actually work in practice when you deal with things that=
 fail. Which is nearly everything. Especially when a network or file system=
 is in the way. So real life means a lot of this chained code that looks gr=
eat in an example, often isn't real.</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(2=
04,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"=
><div dir=3D"ltr"><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,20=
4);border-left-width:1px;border-left-style:solid"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-col=
or:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir=
=3D"ltr">The only difference is the place of the declaration and of the inc=
rement, as well as the scope of the declared variable (and we can get aroun=
d that by putting a while loop in a new scope). The range-based for loop of=
fers a new level of abstraction, so I wouldn't want of a "new" loop that st=
ill forces me&nbsp;to write the iterator increment stuff by hand. </div></b=
lockquote></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-=
left-width:1px;border-left-style:solid"><div><br></div><div>Wait, wait. Whe=
re have I ever mentioned something in my proposal that forces anything?</di=
v></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-wid=
th:1px;border-left-style:solid"><div>Quite the contrary I've actually expla=
ined why alternative proposals&nbsp;are doing the forcing if anything so I'=
m not sure where you get this idea?</div></blockquote><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left=
-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div=
>All I've demonstrated is that a hybrid of the two loops lets everybody get=
 the best of both loops exactly so nobody is forced to do anything, they ju=
st pick and mix.</div></blockquote><div>&nbsp;<br>You are right. My use of =
"force" wasn't for the better. What I meant is that I think that only one o=
f the solutions to the typical problem (iterate with index and elem) will b=
e chosen in the end. Since, if accepted, your proposal would be considered =
the idiomatic way to do that, I would in the end be "forced" to used it to =
write idiomatic C++ code.<br></div></div></div></blockquote><div><br></div>=
<div>I don't agree.&nbsp;You've stretched your concern about my proposal to=
o far in this suggestion in&nbsp;my opinion. There simply is no forcing her=
e. Use the bits you need as you need them. Where it doesn't make sense, don=
't. If you pick the right loop or tuple or whatever to begin with for your =
solution,&nbsp;nobody is going to argue with you. It's not template wars he=
re or nearly anything so complicated.</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(=
204,204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr=
"><div dir=3D"ltr"><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-=
color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div =
dir=3D"ltr">At least, std::enumerate automagically produces the indices, we=
 don't have to compute them by hand.</div></blockquote></blockquote><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1=
ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-sty=
le:solid"><div><br></div><div>Again, that assumes there is just one index, =
it's +1 or that you even want to increment anything at all in the step.</di=
v></blockquote><div>&nbsp;<br>If we want something that is not "+1", the id=
iomatic C++ way would be to write an iterator that does something else (and=
 there are several tools to efficiently write iterators, Boost.Iterator bei=
ng one of them). Then, we apply "++" to the iterator.<br><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1e=
x;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-styl=
e:solid"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px=
;border-left-style:solid"><div dir=3D"ltr"> Moreover, while "enumerate" is =
easy to find with a searching tool, your proposed syntax is rather hard to =
find, and if one reads too fast, they may think it is a regular C-style for=
 loop.<br></div></blockquote></blockquote><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(2=
04,204,204);border-left-width:1px;border-left-style:solid"><div><br></div><=
div>Is that a real argument? I've seen&nbsp;whole&nbsp;pages of&nbsp;C++ co=
de that looks like C&nbsp;for that to be a worry or any confusion! lol&nbsp=
;Only half the time does that bother me. That's the real worry!! lol</div><=
/blockquote><div><br>Half the time can already be pretty much of a concern.=
 The search tool argument was already used as a weakness for the static if =
proposal, so yeah, it may be a valid argument.<br></div></div></div></block=
quote><div><br></div><div>I missed&nbsp;your point about searching, I would=
 agree with that statement but people should be putting their loops into fu=
nctions anyway that serve the purpose not just inline looping everywhere so=
 your argument&nbsp;is&nbsp;overblown.</div><div><br></div><div>The proof i=
s that I've never ever search for a for as a keyword search, who has? I sea=
rch for find_customer or find_person or whatever and the loop is inside tha=
t. Anyone who does different is in the wrong job&nbsp;and no enumerate is g=
oing to help them.</div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,=
204,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><d=
iv dir=3D"ltr"><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);=
border-left-width:1px;border-left-style:solid"><div>I don't think anyone ha=
s attacked this proposal on substance yet, so&nbsp;I'm not&nbsp;concerned b=
y that yet. If they succeed, I'll be happy, I just want a better mouse trap=
..</div><div>But to do that you've got to&nbsp;start talking features and ex=
amples that show that and also why this proposal can't augment the&nbsp;alt=
ernative too.</div><div>So far I'm still not seeing that.</div></blockquote=
><div><br>&nbsp;I don't want to sound harsh again (or do I?) but there isn'=
t that much substance in the first place to attack. Your proposal is no mor=
e than a mere syntactic enhancement and most (?) of us don't even see it as=
 an enhancement. We provided an alternative for the most common use case, w=
hich can be used to improve other areas than foreach loops, and are still w=
aiting for use cases and are still waiting for examples of code where your =
proposal would make enough of a difference to deserve its language change.<=
br></div></div></div></blockquote><div><br></div><div>You are right,&nbsp;t=
his proposal isn't a proposal of massive substance, but I never suggested i=
t was? It is&nbsp;what I've always maintained&nbsp;it was, a&nbsp;simple ex=
tension to graft&nbsp;the features of the existing for loop&nbsp;onto the n=
ewer for loop&nbsp;to make&nbsp;the superset.</div><div><br></div><div>No m=
ega examples are required to demonstrate something so simple. Even less so =
when it's just the combination of two features we already have and that are=
n't hard to grasp to begin with.</div><div><br></div><div>But when people a=
re attacking that proposal with,&nbsp;"it won't work" and "I don't like the=
 syntax" and then "your proposal is forcing me to do whatever" all I can do=
 is answer that and say what nonsense most of that is and that's what I've =
done.</div><div><br></div><div>And when you move on to (effectively saying)=
&nbsp;"I think some tuple thing is better", all I can do is say, fine, show=
 me your tuple thing, but then the&nbsp;onus is on you to&nbsp;have example=
s&nbsp;to&nbsp;demonstrate that because you're proposing something much mor=
e complicated than my proposal; so you need the examples, not me.</div><div=
><br></div><div>So with that all said,&nbsp;I think&nbsp;I've&nbsp;covered =
enough ground in this discussion about what&nbsp;my proposal is and isn't a=
nd cleared up&nbsp;a few of the&nbsp;mischaracterizations&nbsp;on that whic=
h might&nbsp;have confuse peopled. So&nbsp;I think my duty is done here. Th=
ere&nbsp;should be&nbsp;sufficient information here now that&nbsp;I&nbsp;sh=
ouldn't&nbsp;need to add anything further for the time being, if at all.</d=
iv><div><br></div><div>The proposal&nbsp;appeals&nbsp;or non appeal is bett=
er now left to&nbsp;interested or disinterested parties to discuss it betwe=
en them.&nbsp;I'll just watch&nbsp;how&nbsp;that&nbsp;pans out for a while.=
 It's not an earth shattering proposal so I don't expect much. But all the =
info is here now. It just needs&nbsp;to sink or swim on it's own.</div><div=
><br></div><div>Thanks&nbsp;for the discussion. </div><div><br></div><div>T=
he tuple stuff&nbsp;looks interesting&nbsp;but it's really separate to my p=
roposal as my proposal&nbsp;here isn't dependent on them at all.&nbsp;So I'=
ll be keen to follow that&nbsp;more in the appropriate threads I've seen po=
p up. I admit I'm&nbsp;not keen on tuples for the reasons I've given but I =
am keen to have that view swayed so it will be&nbsp;interesting for me. Tha=
nks for the maths domain suggestion about them. That at least gives me a&nb=
sp;bit of an&nbsp;insight&nbsp;into why&nbsp;the fascination with them is s=
o high in some sections of the community&nbsp;and less in others. I&nbsp;wo=
nder if there&nbsp;are any math's wizards who are less&nbsp;than enamoured =
by tuples. I look forward to hearing either type of person add their views =
in those threads. Interesting stuff.</div><div><br></div><div>Thanks</div><=
/div></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 />

------=_Part_715_13274858.1401471214813--

.

------=_Part_409_8211723.1401488207264
Content-Type: text/plain; charset=UTF-8


On Friday, May 30, 2014 10:16:00 AM UTC-4, gmis...@gmail.com wrote:

> So I was making the point to the person who was arguing with such
> confidence that no one would/should change the language for such a small
> change when it just enables something that we can already do, to not be so
> premature in that confidence about what people or the committee might or
> might not do because history has already shown they might vote for it
> because they did before in very much these same circumstances.
>
>  I hate to beat a dead horse, but one little thing bugs me. Who made such
an argument? It's certainly not what I was saying.

--

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

<div dir=3D"ltr"><br>On Friday, May 30, 2014 10:16:00 AM UTC-4, gmis...@gma=
il.com wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>So I was&nbsp;making the&nbsp;point&nbsp;to the person&nbsp;who wa=
s arguing with such confidence that&nbsp;no one&nbsp;would/should&nbsp;chan=
ge the language&nbsp;for such a small change&nbsp;when it just enables some=
thing that we can already do, to&nbsp;not be so premature in that confidenc=
e about what people or the committee&nbsp;might or might not do because his=
tory has already shown they might vote for it because they did before in&nb=
sp;very much&nbsp;these same circumstances.</div><div><br></div></div></blo=
ckquote><div>&nbsp;I hate to beat a dead horse, but one little thing bugs m=
e. Who made such an argument? It's certainly not what I was saying.<br></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 />

------=_Part_409_8211723.1401488207264--

.