C++ core language extension proposal: "Allow Initializers Anywhere" (AIE)

For defining variables anywhere:
   [initializer-list]

The vars in the [initializer-list] are known only after their occurance, of=
=20
course.
The vars are known only in their scope, of course.

Applicable everywhere:
  if ([initializer-list] ...) ...

  switch ([initializer-list] ...) ...

  for ([initializer-list] ...; ...; ...) ...

  while ([initializer-list] ...) ...

  do [initializer-list] ... while ([initializer-list2] ...);
  // (initializer-list2 is limited in scope)

  [initializer-list]
  // (also anywhere w/o any association (of course then the braces are redu=
ndant))

Example in a for-loop:
   for ([const size_t bla_sz =3D bla.size(), cmp_val =3D bla[0]; bool f =3D=
 false;]
        size_t i =3D 1; !f && (i < bla_sz); ++i) ...

Alternative syntax (maybe):
  :initializer-list:

Notes:
   This a very powerful and easy to implement proposal. It allows to define=
=20
any type of variables, also different types,
   and also with attributes (ie. const, volatile etc.), practically anywher=
e=20
(ie. free of context).
   It generalizes and extends the "Initializers in if and switch statements=
"=20
of C++17 that was proposed
   by Thomas K=C3=B6ppe <tkoeppe@google.com> at=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r0.html
   (ISO/IEC JTC1 SC22 WG21 P00305r0, Date: 2016-03-14, To: EWG, CWG)

As I unfortunately don't have time to file an official proposal myself, I w=
ant=20
to encourage others to do it.
As said, it's very flexible and powerful (also for optimization), and at th=
e=20
same time very easy to implement into the core language as it's practically=
=20
context-free.



--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5B1D2AB5.4060409%40mutluit.com.

.

------=_Part_20204_40741770.1528642573381
Content-Type: multipart/alternative;
 boundary="----=_Part_20205_1723221406.1528642573382"

------=_Part_20205_1723221406.1528642573382
Content-Type: text/plain; charset="UTF-8"

You are suggesting two things.

First initializing every while, if etc where it is not the case already
(not sure what's left).

Second - to have multivariable, multitype declaration. This was already
suggested, multiple times, with various syntax.
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/lk5oLy6qM7Q/BlkVuhW3AwAJ

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/83695adf-1a44-44a9-a333-42a00a11f339%40isocpp.org.

------=_Part_20205_1723221406.1528642573382
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>You are suggesting two things.</div><div><br></div><d=
iv>First initializing every <font face=3D"courier new,monospace">while</fon=
t>, <font face=3D"courier new,monospace">if</font> etc where it is not the =
case already (not sure what&#39;s left).</div><div><br></div><div>Second - =
to have multivariable, multitype declaration. This was already suggested, m=
ultiple times, with various syntax.</div><div>https://groups.google.com/a/i=
socpp.org/d/msg/std-proposals/lk5oLy6qM7Q/BlkVuhW3AwAJ</div><div><br></div>=
</div>

<p></p>

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

------=_Part_20205_1723221406.1528642573382--

------=_Part_20204_40741770.1528642573381--

.

------=_Part_53934_815077626.1528644035797
Content-Type: multipart/alternative;
 boundary="----=_Part_53935_1942512792.1528644035797"

------=_Part_53935_1942512792.1528644035797
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sunday, June 10, 2018 at 9:42:32 AM UTC-4, U.Mutlu wrote:
>
> Example in a for-loop:=20
>    for ([const size_t bla_sz =3D bla.size(), cmp_val =3D bla[0]; bool f =
=3D=20
> false;]=20
>         size_t i =3D 1; !f && (i < bla_sz); ++i) ...=20
>

That is code which should *fail* code review. Is there a need to make it=20
easier to write bad code?

Notes:=20
>    This a very powerful and easy to implement proposal.


Irrelevant. The most important thing about any proposal is whether it=20
solves a problem that needs solving. Thus far, you haven't identified a=20
problem that needs solving.

Also, do you have sufficient experience in compiler writing to be able to=
=20
say that it's "easy to implement"?

It allows to define=20
> any type of variables, also different types,=20
>    and also with attributes (ie. const, volatile etc.), practically=20
> anywhere=20
> (ie. free of context).=20
>

Yes, it does. Why is this a good thing?

   It generalizes and extends the "Initializers in if and switch=20
> statements"=20
> of C++17 that was proposed=20
>    by Thomas K=C3=B6ppe <tko...@google.com <javascript:>> at=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r0.html=20
>    (ISO/IEC JTC1 SC22 WG21 P00305r0, Date: 2016-03-14, To: EWG, CWG)=20
>

Yes, it does. Why is that a good thing?

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/c3f72341-e2ed-4222-af78-0462fb22922a%40isocpp.or=
g.

------=_Part_53935_1942512792.1528644035797
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, June 10, 2018 at 9:42:32 AM UTC-4, U.Mutlu wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">Example in a for-loop:
<br>=C2=A0 =C2=A0for ([const size_t bla_sz =3D bla.size(), cmp_val =3D bla[=
0]; bool f =3D false;]
<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 size_t i =3D 1; !f &amp;&amp; (i &lt; bla_s=
z); ++i) ...
<br></blockquote><div><br></div><div>That is code which should <i>fail</i> =
code review. Is there a need to make it easier to write bad code?<br></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;">
Notes:
<br>=C2=A0 =C2=A0This a very powerful and easy to implement proposal.</bloc=
kquote><div><br></div><div>Irrelevant. The most important thing about any p=
roposal is whether it solves a problem that needs solving. Thus far, you ha=
ven&#39;t identified a problem that needs solving.</div><div><br></div><div=
>Also, do you have sufficient experience in compiler writing to be able to =
say that it&#39;s &quot;easy to implement&quot;?<br></div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">It allows to define=20
<br>any type of variables, also different types,
<br>=C2=A0 =C2=A0and also with attributes (ie. const, volatile etc.), pract=
ically anywhere=20
<br>(ie. free of context).
<br></blockquote><div><br></div><div>Yes, it does. Why is this a good thing=
?<br></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;">=C2=
=A0 =C2=A0It generalizes and extends the &quot;Initializers in if and switc=
h statements&quot;=20
<br>of C++17 that was proposed
<br>=C2=A0 =C2=A0by Thomas K=C3=B6ppe &lt;<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"MUj19QPJBQAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">tko...@google.com</a>&gt; at=20
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p030=
5r0.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc2=
2%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0305r0.html\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNF95advE2CXM1cgqRxc8C8j3r7sFw&#39;;return true;" onclick=3D"this=
..href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2=
Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0305r0.html\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNF95advE2CXM1cgqRxc8C8j3r7sFw&#39;;return true;">http=
://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0305r0.html<=
/a>
<br>=C2=A0 =C2=A0(ISO/IEC JTC1 SC22 WG21 P00305r0, Date: 2016-03-14, To: EW=
G, CWG)
<br></blockquote><div><br></div><div>Yes, it does. Why is that a good thing=
?</div></div>

<p></p>

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

------=_Part_53935_1942512792.1528644035797--

------=_Part_53934_815077626.1528644035797--

.

Nicol Bolas wrote on 06/10/2018 05:20 PM:
> On Sunday, June 10, 2018 at 9:42:32 AM UTC-4, U.Mutlu wrote:
>
>     Example in a for-loop:
>         for ([const size_t bla_sz =3D bla.size(), cmp_val =3D bla[0]; boo=
l f =3D
>     false;]
>              size_t i =3D 1; !f && (i < bla_sz); ++i) ...
>
> That is code which should /fail/ code review. Is there a need to make it
> easier to write bad code?

There's a good reason out there in the "field" for this proposed method.
Without this method one has to use either an own scope for the
temporary variables, or has to leak the variables into the ambient scope,
which of course is not desirable, IMO even both not desirable.

>     Notes:
>         This a very powerful and easy to implement proposal.
>
>
> Irrelevant. The most important thing about any proposal is whether it sol=
ves a
> problem that needs solving. Thus far, you haven't identified a problem th=
at
> needs solving.

The above for-loop example shows the power of the method.
Imagine the size of a vector is constant in the loop, then it makes sense
to use a constant instead of calling the size() method of the vector
with each increment/decrement of the loop variable (above "const size_t bla=
_sz=20
=3D bla.size() was used in the initializer,
and in the loop hdr just tested against that very constant --> performance =
gain).

> Also, do you have sufficient experience in compiler writing to be able to=
 say
> that it's "easy to implement"?

It's been long ago with yacc & lex / bison & flex etc. :-), but I know for=
=20
sure this is easy to implement.

>     It allows to define
>     any type of variables, also different types,
>         and also with attributes (ie. const, volatile etc.), practically =
anywhere
>     (ie. free of context).
>
>
> Yes, it does. Why is this a good thing?

Because it is, as demonstrated above.  :-)

>         It generalizes and extends the "Initializers in if and switch sta=
tements"
>     of C++17 that was proposed
>         by Thomas K=C3=B6ppe <tko...@google.com> at
>     http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r0.html
>     <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r0.html=
>
>         (ISO/IEC JTC1 SC22 WG21 P00305r0, Date: 2016-03-14, To: EWG, CWG)
>
>
> Yes, it does. Why is that a good thing?

Fast and safe code by implicit encapsulation, and the use of const.
And can be used practically everywhere, ie. "context-free",
also specifically extending the shown keywords (for, do, while, if, switch,=
 etc.).


Btw. an update (addition) to the given cases:

  if ([initializer-list] ...) ...; else [initializer-list2] ...;
  // (initializer-list2 is limited in scope, but initializer-list
  //  is accessible also in the else-block)




--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5B1D7CDA.8080009%40mutluit.com.

.

mihailnajdenov@gmail.com wrote on 06/10/2018 04:56 PM:
> You are suggesting two things.
>
> First initializing every while, if etc where it is not the case already (not
> sure what's left).

It's only optional to use. Without making use of it then everything is as before.

> Second - to have multivariable, multitype declaration. This was already
> suggested, multiple times, with various syntax.
> https://groups.google.com/a/isocpp.org/d/msg/std-proposals/lk5oLy6qM7Q/BlkVuhW3AwAJ

Thx, will browse.



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5B1D7E92.1040301%40mutluit.com.

.

On Sunday, 10 June 2018 20:32:42 IST U.Mutlu wrote:
> It's been long ago with yacc & lex / bison & flex etc. :-), but I know for
> sure this is easy to implement.

Can you provide a branch of Clang or GCC so we can test your proposal then?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6095275.zV8Ye357tj%40tjmaciei-mobl1.

.

------=_Part_91868_1847205074.1528666398674
Content-Type: multipart/alternative;
 boundary="----=_Part_91869_523370579.1528666398674"

------=_Part_91869_523370579.1528666398674
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sunday, June 10, 2018 at 3:32:56 PM UTC-4, U.Mutlu wrote:
>
> Nicol Bolas wrote on 06/10/2018 05:20 PM:=20
> > On Sunday, June 10, 2018 at 9:42:32 AM UTC-4, U.Mutlu wrote:=20
> >=20
> >     Example in a for-loop:=20
> >         for ([const size_t bla_sz =3D bla.size(), cmp_val =3D bla[0]; b=
ool f=20
> =3D=20
> >     false;]=20
> >              size_t i =3D 1; !f && (i < bla_sz); ++i) ...=20
> >=20
> > That is code which should /fail/ code review. Is there a need to make i=
t=20
> > easier to write bad code?=20
>
> There's a good reason out there in the "field" for this proposed method.=
=20
> Without this method one has to use either an own scope for the=20
> temporary variables, or has to leak the variables into the ambient scope,=
=20
> which of course is not desirable, IMO even both not desirable.
>

I don't see how this is better. Why is the following code so much worse=20
than what you wrote?

{
  const size_t cmp_val =3D bla[0];
  bool f =3D false;
  foo( size_t i =3D 1, bla_sz =3D bla.size(); !f && (i < bla_sz); ++i)
  {...}
}

By putting different variables on multiple lines, you separate out distinct=
=20
concerns. I don't know what `cmp_val` is for, (BTW, your use of variable=20
names is Godawful), but it certainly isn't a part of the actual loop, since=
=20
you aren't testing it against anything in the conditional statement. It's=
=20
merely a thing you want to use *within* the loop.

Similarly, `f` serves a different purpose from `bla_sz` to the loop itself;=
=20
one is used to exit the loop prematurely (I'll assume that `break` is not=
=20
acceptable for some reason), and the other is used to exit the loop=20
normally. Sticking each of these things on their own lines calls out their=
=20
distinct purposes towards the loop. The variables are all associated with=
=20
the loop (due to scoping), but they're all associated differently with the=
=20
loop.

And therefore, someone reading the loop to figure out what it is actually=
=20
doing can see what the logic of the loop is. You have an early termination=
=20
variable (so they should pay attention to where it gets set), you're=20
prematurely optimizing your loop by storing a size, and you have some other=
=20
value that you're using within the loop.

Your example with three variables all declared on one line is far less=20
easily digestible.

But here's the thing. Even if I agreed with you that your "stick everything=
=20
in one line and let the reader sort out what means what" approach were=20
objectively better... how often do you *really* need to write such=20
constructs? Out of every 100 loops you write, you *might* need to do this=
=20
for 5 of them. Maybe.

Do we really need a whole language feature just to serve such a narrow=20
need? Considering how rarely such code needs to be written, is having=20
inelegant loops appear inelegant really a problem that needs solving?

>     Notes:=20
> >         This a very powerful and easy to implement proposal.=20
> >=20
> >=20
> > Irrelevant. The most important thing about any proposal is whether it=
=20
> solves a=20
> > problem that needs solving. Thus far, you haven't identified a problem=
=20
> that=20
> > needs solving.=20
>
> The above for-loop example shows the power of the method.=20
> Imagine the size of a vector is constant in the loop, then it makes sense=
=20
> to use a constant instead of calling the size() method of the vector=20
> with each increment/decrement of the loop variable (above "const size_t=
=20
> bla_sz=20
> =3D bla.size() was used in the initializer,=20
> and in the loop hdr just tested against that very constant --> performanc=
e=20
> gain).
>

Or the compiler can optimize it away; they have a tendency to do that.=20
<https://godbolt.org/g/qV9ufZ> Or you can just use a proper range-based=20
`for` loop and not bother with checking the size at all.
=20

> > Also, do you have sufficient experience in compiler writing to be able=
=20
> to say=20
> > that it's "easy to implement"?=20
>
> It's been long ago with yacc & lex / bison & flex etc. :-), but I know fo=
r=20
> sure this is easy to implement.
>

.... are you *seriously* trying to say that your prior use of a couple of=20
parser building tools is sufficient evidence to know how hard it would be=
=20
to implement a feature in compilers? I mean, even if C++ compilers *did*=20
use these tools (which FYI, they do not), that just gets you to *parsing*=
=20
the syntax. Implementing said functionality is a *long* way away from=20
merely parsing the syntax.
=20

> >     It allows to define=20
> >     any type of variables, also different types,=20
> >         and also with attributes (ie. const, volatile etc.), practicall=
y=20
> anywhere=20
> >     (ie. free of context).=20
> >=20
> >=20
> > Yes, it does. Why is this a good thing?=20
>
> Because it is, as demonstrated above.  :-)=20
>

You "demonstrated above" terrible code that became more comprehensible when=
=20
you *stopped* using the feature you're asking for. You need to demonstrate=
=20
terrible code that we write now that becomes more compressible *with* your=
=20
feature, not the other way around.

Plus, you need to demonstrate that said terrible code is sufficiently=20
common to make your feature worthwhile.
=20

> >         It generalizes and extends the "Initializers in if and switch=
=20
> statements"=20
> >     of C++17 that was proposed=20
> >         by Thomas K=C3=B6ppe <tko...@google.com> at=20
> >     http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r0.htm=
l=20
> >     <
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r0.html>=20
> >         (ISO/IEC JTC1 SC22 WG21 P00305r0, Date: 2016-03-14, To: EWG,=20
> CWG)=20
> >=20
> >=20
> > Yes, it does. Why is that a good thing?=20
>
> Fast and safe code by implicit encapsulation, and the use of const.=20
> And can be used practically everywhere, ie. "context-free",=20
> also specifically extending the shown keywords (for, do, while, if,=20
> switch, etc.).
>

You're *describing the feature*, not explaining why it is a good thing. The=
=20
ability to define a sequence of variables anywhere is *not* a priori good.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/fdae1577-1b10-4377-8dba-0d290433860a%40isocpp.or=
g.

------=_Part_91869_523370579.1528666398674
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, June 10, 2018 at 3:32:56 PM UTC-4, U.Mutlu wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">Nicol Bolas wrote on 06/10/2=
018 05:20 PM:
<br>&gt; On Sunday, June 10, 2018 at 9:42:32 AM UTC-4, U.Mutlu wrote:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 Example in a for-loop:
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 for ([const size_t bla_sz =3D bla.size=
(), cmp_val =3D bla[0]; bool f =3D
<br>&gt; =C2=A0 =C2=A0 false;]
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0size_t i =3D 1; !f=
 &amp;&amp; (i &lt; bla_sz); ++i) ...
<br>&gt;
<br>&gt; That is code which should /fail/ code review. Is there a need to m=
ake it
<br>&gt; easier to write bad code?
<br>
<br>There&#39;s a good reason out there in the &quot;field&quot; for this p=
roposed method.
<br>Without this method one has to use either an own scope for the
<br>temporary variables, or has to leak the variables into the ambient scop=
e,
<br>which of course is not desirable, IMO even both not desirable.<br></blo=
ckquote><div><br></div><div>I don&#39;t see how this is better. Why is the =
following code so much worse than what you wrote?</div><div><br></div><div =
style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, =
187); border-style: solid; border-width: 1px; overflow-wrap: break-word;" c=
lass=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> size_t cmp_val </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> bla</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #06=
6;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">];</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">bool</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> f </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">false</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 foo</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</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" c=
lass=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> bla_sz </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> bla</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">size</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">!</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">f </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">i </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> bla_sz<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">++</span><span style=3D"colo=
r: #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"><br>=C2=A0 </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{...}</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">}</span></div></code></div><div><br></div><div>By putting diff=
erent variables on multiple lines, you separate out distinct concerns. I do=
n&#39;t know what `cmp_val` is for, (BTW, your use of variable names is God=
awful), but it certainly isn&#39;t a part of the actual loop, since you are=
n&#39;t testing it against anything in the conditional statement. It&#39;s =
merely a thing you want to use <i>within</i> the loop.</div><div><br></div>=
<div>Similarly, `f` serves a different purpose from `bla_sz` to the loop it=
self; one is used to exit the loop prematurely (I&#39;ll assume that `break=
` is not acceptable for some reason), and the other is used to exit the loo=
p normally. Sticking each of these things on their own lines calls out thei=
r distinct purposes towards the loop. The variables are all associated with=
 the loop (due to scoping), but they&#39;re all associated differently with=
 the loop.</div><div><br></div><div>And therefore, someone reading the loop=
 to figure out what it is actually doing can see what the logic of the loop=
 is. You have an early termination variable (so they should pay attention t=
o where it gets set), you&#39;re prematurely optimizing your loop by storin=
g a size, and you have some other value that you&#39;re using within the lo=
op.</div><div><br></div><div>Your example with three variables all declared=
 on one line is far less easily digestible.<br></div><div><br></div><div></=
div><div>But here&#39;s the thing. Even if I agreed with you that your &quo=
t;stick everything in one line and let the reader sort out what means what&=
quot; approach were objectively better... how often do you <i>really</i> ne=
ed to write such constructs? Out of every 100 loops you write, you <i>might=
</i> need to do this for 5 of them. Maybe.</div><div><br></div><div>Do we r=
eally need a whole language feature just to serve such a narrow need? Consi=
dering how rarely such code needs to be written, is having inelegant loops =
appear inelegant really a problem that needs solving?<br></div><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">
&gt; =C2=A0 =C2=A0 Notes:
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 This a very powerful and easy to imple=
ment proposal.
<br>&gt;
<br>&gt;
<br>&gt; Irrelevant. The most important thing about any proposal is whether=
 it solves a
<br>&gt; problem that needs solving. Thus far, you haven&#39;t identified a=
 problem that
<br>&gt; needs solving.
<br>
<br>The above for-loop example shows the power of the method.
<br>Imagine the size of a vector is constant in the loop, then it makes sen=
se
<br>to use a constant instead of calling the size() method of the vector
<br>with each increment/decrement of the loop variable (above &quot;const s=
ize_t bla_sz=20
<br>=3D bla.size() was used in the initializer,
<br>and in the loop hdr just tested against that very constant --&gt; perfo=
rmance gain).<br></blockquote><div><br></div><div>Or the compiler can optim=
ize it away; <a href=3D"https://godbolt.org/g/qV9ufZ">they have a tendency =
to do that.</a> Or you can just use a proper range-based `for` loop and not=
 bother with checking the size at all.<br></div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">
&gt; Also, do you have sufficient experience in compiler writing to be able=
 to say
<br>&gt; that it&#39;s &quot;easy to implement&quot;?
<br>
<br>It&#39;s been long ago with yacc &amp; lex / bison &amp; flex etc. :-),=
 but I know for=20
<br>sure this is easy to implement.<br></blockquote><div><br></div><div>...=
 are you <i>seriously</i> trying to say that your prior use of a couple of =
parser building tools is sufficient evidence to know how hard it would be t=
o implement a feature in compilers? I mean, even if C++ compilers <i>did</i=
> use these tools (which FYI, they do not), that just gets you to <i>parsin=
g</i> the syntax. Implementing said functionality is a <i>long</i> way away=
 from merely parsing the syntax.<br></div><div>=C2=A0<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">&gt; =C2=A0 =C2=A0 It allows to define
<br>&gt; =C2=A0 =C2=A0 any type of variables, also different types,
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 and also with attributes (ie. const, v=
olatile etc.), practically anywhere
<br>&gt; =C2=A0 =C2=A0 (ie. free of context).
<br>&gt;
<br>&gt;
<br>&gt; Yes, it does. Why is this a good thing?
<br>
<br>Because it is, as demonstrated above. =C2=A0:-)
<br></blockquote><div><br></div><div>You &quot;demonstrated above&quot; ter=
rible code that became more comprehensible when you <i>stopped</i> using th=
e feature you&#39;re asking for. You need to demonstrate terrible code that=
 we write now that becomes more compressible <i>with</i> your feature, not =
the other way around.</div><div><br></div><div>Plus, you need to demonstrat=
e that said terrible code is sufficiently common to make your feature worth=
while.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;">
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 It generalizes and extends the &quot;Initi=
alizers in if and switch statements&quot;
<br>&gt; =C2=A0 =C2=A0 of C++17 that was proposed
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 by Thomas K=C3=B6ppe &lt;<a>tko...@goo=
gle.com</a>&gt; at
<br>&gt; =C2=A0 =C2=A0 <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/do=
cs/papers/2016/p0305r0.html" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-s=
td.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0305r0.html\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNF95advE2CXM1cgqRxc8C8j3r7sFw&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2=
Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0305r0.htm=
l\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF95advE2CXM1cgqRxc8C8j3r7sFw&#39;=
;return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016=
/<wbr>p0305r0.html</a>
<br>&gt; =C2=A0 =C2=A0 &lt;<a href=3D"http://www.open-std.org/jtc1/sc22/wg2=
1/docs/papers/2016/p0305r0.html" target=3D"_blank" rel=3D"nofollow" onmouse=
down=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.op=
en-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0305r0.html\x26sa=
\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF95advE2CXM1cgqRxc8C8j3r7sFw&#39;;return=
 true;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%=
2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0305r0=
..html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF95advE2CXM1cgqRxc8C8j3r7sFw&=
#39;;return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/=
2016/<wbr>p0305r0.html</a>&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 (ISO/IEC JTC1 SC22 WG21 P00305r0, Date=
: 2016-03-14, To: EWG, CWG)
<br>&gt;
<br>&gt;
<br>&gt; Yes, it does. Why is that a good thing?
<br>
<br>Fast and safe code by implicit encapsulation, and the use of const.
<br>And can be used practically everywhere, ie. &quot;context-free&quot;,
<br>also specifically extending the shown keywords (for, do, while, if, swi=
tch, etc.).<br></blockquote><div><br></div><div>You&#39;re <i>describing th=
e feature</i>, not explaining why it is a good thing. The ability to define=
 a sequence of variables anywhere is <i>not</i> a priori good.<br></div></d=
iv>

<p></p>

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

------=_Part_91869_523370579.1528666398674--

------=_Part_91868_1847205074.1528666398674--

.

Nicol Bolas wrote on 06/10/2018 11:33 PM:
> On Sunday, June 10, 2018 at 3:32:56 PM UTC-4, U.Mutlu wrote:
>
>     Nicol Bolas wrote on 06/10/2018 05:20 PM:
>      > On Sunday, June 10, 2018 at 9:42:32 AM UTC-4, U.Mutlu wrote:
>      >
>      >     Example in a for-loop:
>      >         for ([const size_t bla_sz =3D bla.size(), cmp_val =3D bla[=
0]; bool f =3D
>      >     false;]
>      >              size_t i =3D 1; !f && (i < bla_sz); ++i) ...
>      >
>      > That is code which should /fail/ code review. Is there a need to m=
ake it
>      > easier to write bad code?
>
>     There's a good reason out there in the "field" for this proposed meth=
od.
>     Without this method one has to use either an own scope for the
>     temporary variables, or has to leak the variables into the ambient sc=
ope,
>     which of course is not desirable, IMO even both not desirable.
>
>
> I don't see how this is better. Why is the following code so much worse t=
han
> what you wrote?
>

> {
> constsize_t cmp_val =3Dbla[0];
> boolf =3Dfalse;
>    foo(size_t i =3D1,bla_sz =3Dbla.size();!f &&(i <bla_sz);++i)
> {...}
> }

IMO a terrible construct one should try to avoid.


> By putting different variables on multiple lines, you separate out distin=
ct
> concerns. I don't know what `cmp_val` is for, (BTW, your use of variable =
names
> is Godawful), but it certainly isn't a part of the actual loop, since you
> aren't testing it against anything in the conditional statement. It's mer=
ely a
> thing you want to use /within/ the loop.
>
> Similarly, `f` serves a different purpose from `bla_sz` to the loop itsel=
f;
> one is used to exit the loop prematurely (I'll assume that `break` is not
> acceptable for some reason), and the other is used to exit the loop norma=
lly.
> Sticking each of these things on their own lines calls out their distinct
> purposes towards the loop. The variables are all associated with the loop=
 (due
> to scoping), but they're all associated differently with the loop.
>
> And therefore, someone reading the loop to figure out what it is actually
> doing can see what the logic of the loop is. You have an early terminatio=
n
> variable (so they should pay attention to where it gets set), you're
> prematurely optimizing your loop by storing a size, and you have some oth=
er
> value that you're using within the loop.
>
> Your example with three variables all declared on one line is far less ea=
sily
> digestible.

These are cosmetics, they have nothing to do with the proposal per se.

> But here's the thing. Even if I agreed with you that your "stick everythi=
ng in
> one line and let the reader sort out what means what" approach were
> objectively better... how often do you /really/ need to write such constr=
ucts?
> Out of every 100 loops you write, you /might/ need to do this for 5 of th=
em.
> Maybe.

I need it very often, especially in processing std::vector's.

> Do we really need a whole language feature just to serve such a narrow ne=
ed?
> Considering how rarely such code needs to be written, is having inelegant
> loops appear inelegant really a problem that needs solving?

Nope.
Since you are even against the already implemented subset of this proposal
(var definition with if and switch), you are against any useful progress
based on demand from the practice field. The purpose of the proposal is
to improve the language, not to make it worse. And I think I can, for me,
judge that it would be a very useful feature for the broad user base.

>
>      >     Notes:
>      >         This a very powerful and easy to implement proposal.
>      >
>      >
>      > Irrelevant. The most important thing about any proposal is whether=
 it
>     solves a
>      > problem that needs solving. Thus far, you haven't identified a pro=
blem
>     that
>      > needs solving.
>
>     The above for-loop example shows the power of the method.
>     Imagine the size of a vector is constant in the loop, then it makes s=
ense
>     to use a constant instead of calling the size() method of the vector
>     with each increment/decrement of the loop variable (above "const size=
_t
>     bla_sz
>     =3D bla.size() was used in the initializer,
>     and in the loop hdr just tested against that very constant --> perfor=
mance
>     gain).
>
>
> Or the compiler can optimize it away; they have a tendency to do that.
> <https://godbolt.org/g/qV9ufZ> Or you can just use a proper range-based `=
for`
> loop and not bother with checking the size at all.

Range-based for loop is not usable here b/c in this example the loop shall=
=20
start at element 1, not 0.

>      >     It allows to define
>      >     any type of variables, also different types,
>      >         and also with attributes (ie. const, volatile etc.),
>     practically anywhere
>      >     (ie. free of context).
>      >
>      >
>      > Yes, it does. Why is this a good thing?
>
>     Because it is, as demonstrated above.  :-)
>
>
> You "demonstrated above" terrible code that became more comprehensible wh=
en
> you /stopped/ using the feature you're asking for. You need to demonstrat=
e
> terrible code that we write now that becomes more compressible /with/ you=
r
> feature, not the other way around.
>
> Plus, you need to demonstrate that said terrible code is sufficiently com=
mon
> to make your feature worthwhile.

BS, it's just your ignorance.


>      >         It generalizes and extends the "Initializers in if and swi=
tch
>     statements"
>      >     of C++17 that was proposed
>      >         by Thomas K=C3=B6ppe <tko...@google.com> at
>      > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r0.ht=
ml
>     <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r0.html=
>
>      >
>     <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r0.html
>     <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r0.html=
>>
>      >         (ISO/IEC JTC1 SC22 WG21 P00305r0, Date: 2016-03-14, To: EW=
G, CWG)
>      >
>      >
>      > Yes, it does. Why is that a good thing?
>
>     Fast and safe code by implicit encapsulation, and the use of const.
>     And can be used practically everywhere, ie. "context-free",
>     also specifically extending the shown keywords (for, do, while, if,
>     switch, etc.).
>
>
> You're /describing the feature/, not explaining why it is a good thing. T=
he
> ability to define a sequence of variables anywhere is /not/ a priori good=
..

Come on, I've enough with your hostility, arrogance, ignorance & idiocracy.

I hope some other, progressive, people will check the proposal.




--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/pfk837%24boa%241%40blaine.gmane.org.

.

On Monday, 11 June 2018 00:20:27 CEST U.Mutlu wrote:
> > Plus, you need to demonstrate that said terrible code is sufficiently
> > common to make your feature worthwhile.
>
> BS, it's just your ignorance.

Regardless of whether it's terrible or not, you need to demonstrate that the
feature would be sufficiently used by developers and would lead to
(subjective) improvement of their code.

So no, not BS. You need to show this in the proposal.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2883831.2pzhy8mynU%40tjmaciei-mobl1.

.

Thiago Macieira wrote on 06/10/2018 10:52 PM:
> On Sunday, 10 June 2018 20:32:42 IST U.Mutlu wrote:
>> It's been long ago with yacc & lex / bison & flex etc. :-), but I know for
>> sure this is easy to implement.
>
> Can you provide a branch of Clang or GCC so we can test your proposal then?

 From what is proposed, do you really think it is very complicated to implement?
It does not touch or disturb anything else, it's so to say "standalone".
So, then logic dictates that it should be easy to implement.

No, I cannot provide you a ready-made solution. What about your pre-judgement
about a possible implementation?



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/pfk8hm%2487c%241%40blaine.gmane.org.

.

Thiago Macieira wrote on 06/11/2018 12:27 AM:
> On Monday, 11 June 2018 00:20:27 CEST U.Mutlu wrote:
>>> Plus, you need to demonstrate that said terrible code is sufficiently
>>> common to make your feature worthwhile.
>>
>> BS, it's just your ignorance.
>
> Regardless of whether it's terrible or not, you need to demonstrate that the
> feature would be sufficiently used by developers and would lead to
> (subjective) improvement of their code.

It is obviously an improvement, and I already gave an example and commented it.

As I stated in my initial posting, ATM I don't have the time to file an
official proposal, so I would be thankful if someone else will do it.
Everybody feel free. Thx.



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/pfk8sv%24u9f%241%40blaine.gmane.org.

.

--000000000000fe6e61056e52f43a
Content-Type: text/plain; charset="UTF-8"

It is not obviously an improvement. I see it as a significant harm, not an
improvement.
Give an example where the code is improved by your design, not harmed.

On Sun, Jun 10, 2018 at 6:34 PM, U.Mutlu <for-gmane@mutluit.com> wrote:

> Thiago Macieira wrote on 06/11/2018 12:27 AM:
>
>> On Monday, 11 June 2018 00:20:27 CEST U.Mutlu wrote:
>>
>>> Plus, you need to demonstrate that said terrible code is sufficiently
>>>> common to make your feature worthwhile.
>>>>
>>>
>>> BS, it's just your ignorance.
>>>
>>
>> Regardless of whether it's terrible or not, you need to demonstrate that
>> the
>> feature would be sufficiently used by developers and would lead to
>> (subjective) improvement of their code.
>>
>
> It is obviously an improvement, and I already gave an example and
> commented it.
>
> As I stated in my initial posting, ATM I don't have the time to file an
> official proposal, so I would be thankful if someone else will do it.
> Everybody feel free. Thx.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/is
> ocpp.org/d/msgid/std-proposals/pfk8sv%24u9f%241%40blaine.gmane.org.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMD6iD9d4qOnXytV1hwEh83jX%2Bjgmzu21YbPTFYsRHb44oa2QQ%40mail.gmail.com.

--000000000000fe6e61056e52f43a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It is not obviously an improvement. I see it as a signific=
ant harm, not an improvement.=C2=A0<div>Give an example where the code is i=
mproved by your design, not harmed.</div></div><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">On Sun, Jun 10, 2018 at 6:34 PM, U.Mutlu <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:for-gmane@mutluit.com" target=3D"_blank=
">for-gmane@mutluit.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><span class=3D"">Thiago Macieira wrote on 06/11/2018 12:27 AM:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Monday, 11 June 2018 00:20:27 CEST U.Mutlu wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Plus, you need to demonstrate that said terrible code is sufficiently<br>
common to make your feature worthwhile.<br>
</blockquote>
<br>
BS, it&#39;s just your ignorance.<br>
</blockquote>
<br>
Regardless of whether it&#39;s terrible or not, you need to demonstrate tha=
t the<br>
feature would be sufficiently used by developers and would lead to<br>
(subjective) improvement of their code.<br>
</blockquote>
<br></span>
It is obviously an improvement, and I already gave an example and commented=
 it.<br>
<br>
As I stated in my initial posting, ATM I don&#39;t have the time to file an=
 official proposal, so I would be thankful if someone else will do it. Ever=
ybody feel free. Thx.<span class=3D""><br>
<br>
<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isoc<wbr>pp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/pfk8sv%24u9f%241%40blaine.gmane.org" =
rel=3D"noreferrer" target=3D"_blank">https://groups.google.com/a/is<wbr>ocp=
p.org/d/msgid/std-proposals<wbr>/pfk8sv%24u9f%241%40blaine.<wbr>gmane.org</=
a>.<br>
</blockquote></div><br></div>

<p></p>

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

--000000000000fe6e61056e52f43a--

.

--000000000000751e27056e53e3ef
Content-Type: text/plain; charset="UTF-8"

On Mon, 11 Jun 2018, 01:37 Ren Industries, <renindustries@gmail.com> wrote:

> It is not obviously an improvement. I see it as a significant harm, not an
> improvement.
>

I can't see significant harm. I mean, it's just a way of introducing scope
control with a fairly useful syntax that allows for multiple types. That's
the bit I like here - generalizing the current approach with if( ; ) in a
rather interesting way:

if([T a = ...; S b = ...]; some_bool_function(a,b)){
   do_the_thing(a, b);
}.

Though other options do exist, this feels less hacky than, say, binding to
some tautological combined object, existing solely for the purpose of
binding to. If we had an auto which behaved like an auto rather than a
ditto, we could get rid of those square brackets - but that's a debate that
has been had before, and ended up in an impasse if I recall correctly.

In terms of adding it to some other scope-inducing statements, I think it's
reasonable - except for that do-while - on the do by all means, but on the
while has exactly one use case and it's a naff one. But in general this
approach does encourage beginners to think carefully about their scopes.
Sure, a few curly braces here and there doesn't hurt - but amongst
beginners it is not something that is necessarily thought about.

I wouldn't say that the improvement is significant, but I think
"significant harm" is a slight exaggeration.

>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCO0tZcx_sk0a59NDn8t_Sq79zoZPNDuwA0ySArYyXMn0w%40mail.gmail.com.

--000000000000751e27056e53e3ef
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, =
11 Jun 2018, 01:37 Ren Industries, &lt;<a href=3D"mailto:renindustries@gmai=
l.com">renindustries@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr">It is not obviously an improvement. I see it as=
 a significant harm, not an improvement.=C2=A0</div></blockquote></div></di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">I can&#39;t see significant=
 harm. I mean, it&#39;s just a way of introducing scope control with a fair=
ly useful syntax that allows for multiple types. That&#39;s the bit I like =
here - generalizing the current approach with if( ; ) in a rather interesti=
ng way:</div><div dir=3D"auto"><br></div><div dir=3D"auto">if([T a =3D ...;=
 S b =3D ...]; some_bool_function(a,b)){</div><div dir=3D"auto">=C2=A0 =C2=
=A0do_the_thing(a, b);</div><div dir=3D"auto">}.</div><div dir=3D"auto"><br=
></div><div dir=3D"auto">Though other options do exist, this feels less hac=
ky than, say, binding to some tautological combined object, existing solely=
 for the purpose of binding to. If we had an auto which behaved like an aut=
o rather than a ditto, we could get rid of those square brackets - but that=
&#39;s a debate that has been had before, and ended up in an impasse if I r=
ecall correctly.</div><div dir=3D"auto"><br></div><div dir=3D"auto">In term=
s of adding it to some other scope-inducing statements, I think it&#39;s re=
asonable - except for that do-while - on the do by all means, but on the wh=
ile has exactly one use case and it&#39;s a naff one. But in general this a=
pproach does encourage beginners to think carefully about their scopes. Sur=
e, a few curly braces here and there doesn&#39;t hurt - but amongst beginne=
rs it is not something that is necessarily thought about.</div><div dir=3D"=
auto"><br></div><div dir=3D"auto">I wouldn&#39;t say that the improvement i=
s significant, but I think &quot;significant harm&quot; is a slight exagger=
ation.</div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
</blockquote></div></div></div>

<p></p>

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

--000000000000751e27056e53e3ef--

.

Ren Industries wrote on 06/11/2018 02:37 AM:
> It is not obviously an improvement. I see it as a significant harm, not an
> improvement.
> Give an example where the code is improved by your design, not harmed.

Already given -> read the posting carefully. There's a commented example
for the for-loop, and it can be applied similarly also to all the other
cases (if, if-else, while, do-while, switch).

FYI: in C++17 a subset of this proposal has already been implemented,
cf. the reference in the OP and the C++ spec. This proposal generalizes 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/pfkk64%24rv3%241%40blaine.gmane.org.

.

------=_Part_87872_777914242.1528692947266
Content-Type: multipart/alternative;
 boundary="----=_Part_87873_131078258.1528692947266"

------=_Part_87873_131078258.1528692947266
Content-Type: text/plain; charset="UTF-8"

On Sunday, June 10, 2018 at 6:20:41 PM UTC-4, U.Mutlu wrote:
>
> Nicol Bolas wrote on 06/10/2018 11:33 PM:
> > On Sunday, June 10, 2018 at 3:32:56 PM UTC-4, U.Mutlu wrote:
> >
> >     Nicol Bolas wrote on 06/10/2018 05:20 PM:
> >      > On Sunday, June 10, 2018 at 9:42:32 AM UTC-4, U.Mutlu wrote:
> >      >
> >      >     Example in a for-loop:
> >      >         for ([const size_t bla_sz = bla.size(), cmp_val = bla[0];
> bool f =
> >      >     false;]
> >      >              size_t i = 1; !f && (i < bla_sz); ++i) ...
> >      >
> >      > That is code which should /fail/ code review. Is there a need to
> make it
> >      > easier to write bad code?
> >
> >     There's a good reason out there in the "field" for this proposed
> method.
> >     Without this method one has to use either an own scope for the
> >     temporary variables, or has to leak the variables into the ambient
> scope,
> >     which of course is not desirable, IMO even both not desirable.
> >
> >
> > I don't see how this is better. Why is the following code so much worse
> than
> > what you wrote?
> >
>
> > {
> > constsize_t cmp_val =bla[0];
> > boolf =false;
> >    foo(size_t i =1,bla_sz =bla.size();!f &&(i <bla_sz);++i)
> > {...}
> > }
>
> IMO a terrible construct one should try to avoid.
>

I stated my opinion that I preferred this over your proposed alternative. I
spent 3 paragraphs outlining my way of thinking.

You stated your opinion that this was worse. You spent no time outlining
your way of thinking.

I don't think it is possible to have a productive discussion about a
subjective topic if only one of the people is willing to actually explain
their subjective notions rather than simply declaring them to be true.

> By putting different variables on multiple lines, you separate out
> distinct
> > concerns. I don't know what `cmp_val` is for, (BTW, your use of variable
> names
> > is Godawful), but it certainly isn't a part of the actual loop, since
> you
> > aren't testing it against anything in the conditional statement. It's
> merely a
> > thing you want to use /within/ the loop.
> >
> > Similarly, `f` serves a different purpose from `bla_sz` to the loop
> itself;
> > one is used to exit the loop prematurely (I'll assume that `break` is
> not
> > acceptable for some reason), and the other is used to exit the loop
> normally.
> > Sticking each of these things on their own lines calls out their
> distinct
> > purposes towards the loop. The variables are all associated with the
> loop (due
> > to scoping), but they're all associated differently with the loop.
> >
> > And therefore, someone reading the loop to figure out what it is
> actually
> > doing can see what the logic of the loop is. You have an early
> termination
> > variable (so they should pay attention to where it gets set), you're
> > prematurely optimizing your loop by storing a size, and you have some
> other
> > value that you're using within the loop.
> >
> > Your example with three variables all declared on one line is far less
> easily
> > digestible.
>
> These are cosmetics, they have nothing to do with the proposal per se.
>

But your proposal is *entirely* cosmetic. What you want doesn't give users
any greater expressive power than they have now. If you want to scope some
variables, we have a tool for that: {}. So what you're wanting is merely
syntactic sugar.

Since the proposal is sugar, asking how sweet that sugar is is therefore an
appropriate question.

> But here's the thing. Even if I agreed with you that your "stick
> everything in
> > one line and let the reader sort out what means what" approach were
> > objectively better... how often do you /really/ need to write such
> constructs?
> > Out of every 100 loops you write, you /might/ need to do this for 5 of
> them.
> > Maybe.
>
> I need it very often, especially in processing std::vector's.
>

You must be doing unusual processing of arrays if you frequently cannot use
range-based `for` or even straight iterators.

Furthermore, you are not the world. I've seen a lot of loops in my time,
and it is my experience that most of them are not this complicated.

> Do we really need a whole language feature just to serve such a narrow
> need?
> > Considering how rarely such code needs to be written, is having
> inelegant
> > loops appear inelegant really a problem that needs solving?
>
> Nope.
> Since you are even against the already implemented subset of this proposal
> (var definition with if and switch),


Don't put words in my mouth.

Adding variable definitions to `if` solved a genuine problem: dealing with
expressions that result in `optional<T>` and similar types (note that both
`optional` and the new `if` syntax landed in the same standard). Before you
can actually use such a type, you have to test it first. Through this
feature, you can express this intent directly: you get the `optional` and
test it:

if(auto opt = expr; opt)
{
  //use *opt
}

This is important because it is something that happens *frequently* in code
that needs to deal in optional values. And there are other types besides
`optional` where this is useful.

Note what I said earlier about "express this intent". The idea is to
evaluate the optional-bearing expression and test it. The two operations
are part of a complete, logical thought; therefore, they belong in the same
statement.

Now compare that to your loop. You could argue that `f` is part of the
loop, since it is part of the condition for exiting. But your `cmp_val` is
very much not a part of the loop itself. It is used by the loop, but it is
not a part of the loop's branching logic. And the loop introduction exists
to set up its branching logic.

Adding variables to the `for` statement which are not part of the `for`
loop's branching logic is introducing clutter.

So these are not the same thing at all. Declaring random variables that
have nothing to do with the loop logic itself is very different from
declaring a variable which is immediately used in a condition.

Could you have two variables of different types that get immediately used
in a condition? Or three? Or four? Sure.

But the more variables you have, the more variables of different types you
have, the less clear it is what your statement is actually doing. And
therefore, the more clear your code would become if it were multiple
statements.

Just because you *can* do something all in one place doesn't mean you
*should*. And just because adding a teaspoon of sugar makes the sauce taste
better doesn't mean you should add a whole bag.

And especially not for "consistency".

you are against any useful progress
> based on demand from the practice field.


I'm against poorly founded proposals that will inevitably lead to the
writing of less readable code. My "practice field" experience tells me that
the more code you stuff into one statement, the less readable the code
becomes. Adding a feature whose primary purpose is to pack more stuff into
a single statement is not a good thing.

Or at the very least had *better* have a really good motivation behind it
(see `if` above).

The purpose of the proposal is
> to improve the language, not to make it worse. And I think I can, for me,
> judge that it would be a very useful feature for the broad user base.
>
> >
> >      >     Notes:
> >      >         This a very powerful and easy to implement proposal.
> >      >
> >      >
> >      > Irrelevant. The most important thing about any proposal is
> whether it
> >     solves a
> >      > problem that needs solving. Thus far, you haven't identified a
> problem
> >     that
> >      > needs solving.
> >
> >     The above for-loop example shows the power of the method.
> >     Imagine the size of a vector is constant in the loop, then it makes
> sense
> >     to use a constant instead of calling the size() method of the vector
> >     with each increment/decrement of the loop variable (above "const
> size_t
> >     bla_sz
> >     = bla.size() was used in the initializer,
> >     and in the loop hdr just tested against that very constant -->
> performance
> >     gain).
> >
> >
> > Or the compiler can optimize it away; they have a tendency to do that.
> > <https://godbolt.org/g/qV9ufZ> Or you can just use a proper range-based
> `for`
> > loop and not bother with checking the size at all.
>
> Range-based for loop is not usable here b/c in this example the loop shall
> start at element 1, not 0.
>

Adding an offset to the start of a range is trivial, with the right tools.
Something like this:

for(auto &val : irange(v).trim_prefix(1))

That's quite digestible. Obviously, incorporating a variable-based
condition is more difficult (and less digestible), but merely starting from
1 rather than 0 is simply a matter of having good range tools.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/389958b9-4c1c-4cbb-baa8-7aa12c20c075%40isocpp.org.

------=_Part_87873_131078258.1528692947266
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, June 10, 2018 at 6:20:41 PM UTC-4, U.Mutlu wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">Nicol Bolas wrote on 06/10/2=
018 11:33 PM:
<br>&gt; On Sunday, June 10, 2018 at 3:32:56 PM UTC-4, U.Mutlu wrote:
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 Nicol Bolas wrote on 06/10/2018 05:20 PM:
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; On Sunday, June 10, 2018 at 9:42:32 AM UT=
C-4, U.Mutlu wrote:
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 Example in a for-loop:
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 for ([const s=
ize_t bla_sz =3D bla.size(), cmp_val =3D bla[0]; bool f =3D
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 false;]
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0size_t i =3D 1; !f &amp;&amp; (i &lt; bla_sz); ++i) ...
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; That is code which should /fail/ code rev=
iew. Is there a need to make it
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; easier to write bad code?
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 There&#39;s a good reason out there in the &quot;fie=
ld&quot; for this proposed method.
<br>&gt; =C2=A0 =C2=A0 Without this method one has to use either an own sco=
pe for the
<br>&gt; =C2=A0 =C2=A0 temporary variables, or has to leak the variables in=
to the ambient scope,
<br>&gt; =C2=A0 =C2=A0 which of course is not desirable, IMO even both not =
desirable.
<br>&gt;
<br>&gt;
<br>&gt; I don&#39;t see how this is better. Why is the following code so m=
uch worse than
<br>&gt; what you wrote?
<br>&gt;
<br>
<br>&gt; {
<br>&gt; constsize_t cmp_val =3Dbla[0];
<br>&gt; boolf =3Dfalse;
<br>&gt; =C2=A0 =C2=A0foo(size_t i =3D1,bla_sz =3Dbla.size();!f &amp;&amp;(=
i &lt;bla_sz);++i)
<br>&gt; {...}
<br>&gt; }
<br>
<br>IMO a terrible construct one should try to avoid.<br></blockquote><div>=
<br></div><div>I stated my opinion that I preferred this over your proposed=
 alternative. I spent 3 paragraphs outlining my way of thinking.</div><div>=
<br></div><div>You stated your opinion that this was worse. You spent no ti=
me outlining your way of thinking.</div><div><br></div><div>I don&#39;t thi=
nk it is possible to have a productive discussion about a subjective topic =
if only one of the people is willing to actually explain their subjective n=
otions rather than simply declaring them to be true.<br></div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">
&gt; By putting different variables on multiple lines, you separate out dis=
tinct
<br>&gt; concerns. I don&#39;t know what `cmp_val` is for, (BTW, your use o=
f variable names
<br>&gt; is Godawful), but it certainly isn&#39;t a part of the actual loop=
, since you
<br>&gt; aren&#39;t testing it against anything in the conditional statemen=
t. It&#39;s merely a
<br>&gt; thing you want to use /within/ the loop.
<br>&gt;
<br>&gt; Similarly, `f` serves a different purpose from `bla_sz` to the loo=
p itself;
<br>&gt; one is used to exit the loop prematurely (I&#39;ll assume that `br=
eak` is not
<br>&gt; acceptable for some reason), and the other is used to exit the loo=
p normally.
<br>&gt; Sticking each of these things on their own lines calls out their d=
istinct
<br>&gt; purposes towards the loop. The variables are all associated with t=
he loop (due
<br>&gt; to scoping), but they&#39;re all associated differently with the l=
oop.
<br>&gt;
<br>&gt; And therefore, someone reading the loop to figure out what it is a=
ctually
<br>&gt; doing can see what the logic of the loop is. You have an early ter=
mination
<br>&gt; variable (so they should pay attention to where it gets set), you&=
#39;re
<br>&gt; prematurely optimizing your loop by storing a size, and you have s=
ome other
<br>&gt; value that you&#39;re using within the loop.
<br>&gt;
<br>&gt; Your example with three variables all declared on one line is far =
less easily
<br>&gt; digestible.
<br>
<br>These are cosmetics, they have nothing to do with the proposal per se.<=
br></blockquote><div><br></div><div>But your proposal is <i>entirely</i> co=
smetic. What you want doesn&#39;t give users any greater expressive power t=
han they have now. If you want to scope some variables, we have a tool for =
that: {}. So what you&#39;re wanting is merely syntactic sugar.</div><div><=
br></div><div>Since the proposal is sugar, asking how sweet that sugar is i=
s therefore an appropriate question.<br></div><div><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">
&gt; But here&#39;s the thing. Even if I agreed with you that your &quot;st=
ick everything in
<br>&gt; one line and let the reader sort out what means what&quot; approac=
h were
<br>&gt; objectively better... how often do you /really/ need to write such=
 constructs?
<br>&gt; Out of every 100 loops you write, you /might/ need to do this for =
5 of them.
<br>&gt; Maybe.
<br>
<br>I need it very often, especially in processing std::vector&#39;s.<br></=
blockquote><div><br></div><div>You must be doing unusual processing of arra=
ys if you frequently cannot use range-based `for` or even straight iterator=
s.</div><div><br></div><div>Furthermore, you are not the world. I&#39;ve se=
en a lot of loops in my time, and it is my experience that most of them are=
 not this complicated.<br></div><br><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
&gt; Do we really need a whole language feature just to serve such a narrow=
 need?
<br>&gt; Considering how rarely such code needs to be written, is having in=
elegant
<br>&gt; loops appear inelegant really a problem that needs solving?
<br>
<br>Nope.
<br>Since you are even against the already implemented subset of this propo=
sal
<br>(var definition with if and switch),</blockquote><div><br></div><div>Do=
n&#39;t put words in my mouth.</div><div><br></div><div>Adding variable def=
initions to `if` solved a genuine problem: dealing with expressions that re=
sult in `optional&lt;T&gt;` and similar types (note that both `optional` an=
d the new `if` syntax landed in the same standard). Before you can actually=
 use such a type, you have to test it first. Through this feature, you can =
express this intent directly: you get the `optional` and test it:</div><div=
><br></div><div style=3D"background-color: rgb(250, 250, 250); border-color=
: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow-wrap=
: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">if</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> opt </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> expr</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> opt</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>//use *opt</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></d=
iv></code></div><div><br></div><div>This is important because it is somethi=
ng that happens <i>frequently</i> in code that needs to deal in optional va=
lues. And there are other types besides `optional` where this is useful.</d=
iv><div><br></div><div>Note what I said earlier about &quot;express this in=
tent&quot;. The idea is to evaluate the optional-bearing expression and tes=
t it. The two operations are part of a complete, logical thought; therefore=
, they belong in the same statement.</div><div><br></div><div>Now compare t=
hat to your loop. You could argue that `f` is part of the loop, since it is=
 part of the condition for exiting. But your `cmp_val` is very much not a p=
art of the loop itself. It is used by the loop, but it is not a part of the=
 loop&#39;s branching logic. And the loop introduction exists to set up its=
 branching logic.</div><div><br></div><div>Adding variables to the `for` st=
atement which are not part of the `for` loop&#39;s branching logic is intro=
ducing clutter.</div><div><br></div><div>So these are not the same thing at=
 all. Declaring random variables that have nothing to do with the loop logi=
c itself is very different from declaring a variable which is immediately u=
sed in a condition.</div><div><br></div><div>Could you have two variables o=
f different types that get immediately used in a condition? Or three? Or fo=
ur? Sure.</div><div><br></div><div>But the more variables you have, the mor=
e variables of different types you have, the less clear it is what your sta=
tement is actually doing. And therefore, the more clear your code would bec=
ome if it were multiple statements.</div><div><br></div><div>Just because y=
ou <i>can</i> do something all in one place doesn&#39;t mean you <i>should<=
/i>. And just because adding a teaspoon of sugar makes the sauce taste bett=
er doesn&#39;t mean you should add a whole bag.</div><div><br></div><div>An=
d especially not for &quot;consistency&quot;.<br></div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">you are against any useful progress
<br>based on demand from the practice field.</blockquote><div><br></div><di=
v>I&#39;m against poorly founded proposals that will inevitably lead to the=
 writing of less readable code. My &quot;practice field&quot; experience te=
lls me that the more code you stuff into one statement, the less readable t=
he code becomes. Adding a feature whose primary purpose is to pack more stu=
ff into a single statement is not a good thing.</div><div><br></div><div>Or=
 at the very least had <i>better</i> have a really good motivation behind i=
t (see `if` above).<br></div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">The purpose of the proposal is
<br>to improve the language, not to make it worse. And I think I can, for m=
e,
<br>judge that it would be a very useful feature for the broad user base.<b=
r>
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 Notes:
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 This a very p=
owerful and easy to implement proposal.
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt;
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; Irrelevant. The most important thing abou=
t any proposal is whether it
<br>&gt; =C2=A0 =C2=A0 solves a
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; problem that needs solving. Thus far, you=
 haven&#39;t identified a problem
<br>&gt; =C2=A0 =C2=A0 that
<br>&gt; =C2=A0 =C2=A0 =C2=A0&gt; needs solving.
<br>&gt;
<br>&gt; =C2=A0 =C2=A0 The above for-loop example shows the power of the me=
thod.
<br>&gt; =C2=A0 =C2=A0 Imagine the size of a vector is constant in the loop=
, then it makes sense
<br>&gt; =C2=A0 =C2=A0 to use a constant instead of calling the size() meth=
od of the vector
<br>&gt; =C2=A0 =C2=A0 with each increment/decrement of the loop variable (=
above &quot;const size_t
<br>&gt; =C2=A0 =C2=A0 bla_sz
<br>&gt; =C2=A0 =C2=A0 =3D bla.size() was used in the initializer,
<br>&gt; =C2=A0 =C2=A0 and in the loop hdr just tested against that very co=
nstant --&gt; performance
<br>&gt; =C2=A0 =C2=A0 gain).
<br>&gt;
<br>&gt;
<br>&gt; Or the compiler can optimize it away; they have a tendency to do t=
hat.
<br>&gt; &lt;<a href=3D"https://godbolt.org/g/qV9ufZ" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\=
x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2FqV9ufZ\x26sa\x3dD\x26sntz\x3d1\x26usg\x3=
dAFQjCNHVJMBioXmr307PUrq758gEIxDQFQ&#39;;return true;" onclick=3D"this.href=
=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgodbolt.org%2Fg%2FqV9=
ufZ\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHVJMBioXmr307PUrq758gEIxDQFQ&#3=
9;;return true;">https://godbolt.org/g/qV9ufZ</a>&gt; Or you can just use a=
 proper range-based `for`
<br>&gt; loop and not bother with checking the size at all.
<br>
<br>Range-based for loop is not usable here b/c in this example the loop sh=
all=20
<br>start at element 1, not 0.<br></blockquote><div><br></div><div>Adding a=
n offset to the start of a range is trivial, with the right tools. Somethin=
g like this:</div><div><br></div><div><div style=3D"background-color: rgb(2=
50, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; borde=
r-width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code 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"style=
d-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">val <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> irange</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: #6=
60;" class=3D"styled-by-prettify">).</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">trim_prefix</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">))</span></div></code></div></div><div><br></div><div>That&#39;s q=
uite digestible. Obviously, incorporating a variable-based condition is mor=
e difficult (and less digestible), but merely starting from 1 rather than 0=
 is simply a matter of having good range tools.<br></div><br></div>

<p></p>

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

------=_Part_87873_131078258.1528692947266--

------=_Part_87872_777914242.1528692947266--

.

------=_Part_96424_1222679911.1528694198936
Content-Type: multipart/alternative;
 boundary="----=_Part_96425_1027630625.1528694198937"

------=_Part_96425_1027630625.1528694198937
Content-Type: text/plain; charset="UTF-8"

On Sunday, June 10, 2018 at 9:44:22 PM UTC-4, Jake Arkinstall wrote:
>
> On Mon, 11 Jun 2018, 01:37 Ren Industries, <renind...@gmail.com
> <javascript:>> wrote:
>
>> It is not obviously an improvement. I see it as a significant harm, not
>> an improvement.
>>
>
> I can't see significant harm. I mean, it's just a way of introducing scope
> control with a fairly useful syntax that allows for multiple types. That's
> the bit I like here - generalizing the current approach with if( ; ) in a
> rather interesting way:
>
> if([T a = ...; S b = ...]; some_bool_function(a,b)){
>    do_the_thing(a, b);
> }.
>
> Though other options do exist, this feels less hacky than, say, binding to
> some tautological combined object, existing solely for the purpose of
> binding to. If we had an auto which behaved like an auto rather than a
> ditto, we could get rid of those square brackets - but that's a debate that
> has been had before, and ended up in an impasse if I recall correctly.
>

My recollection was that it ended up in "OK, so you want `auto` to deduce
multiple types? Go convince the committee". Which was never attempted.

The principle objection to what was discussed before was that it *wasn't*
using `auto` to deduce different types, that (like this one) it was
inventing a novel syntax for something we already know how it ought to be
spelled. And since there are no grammatical issues with spelling it that
way, any more grammar heavy spelling is pointless, and solves none of the
problems with the core idea.

And the principle objection to any form of this basic idea (aka: declaring
multiple variables of the same type in a single statement) is merely what
I've restated here: long statements are obscure statements, and obscuring
code is not something we should encourage.

In terms of adding it to some other scope-inducing statements, I think it's
> reasonable - except for that do-while - on the do by all means, but on the
> while has exactly one use case and it's a naff one. But in general this
> approach does encourage beginners to think carefully about their scopes.
> Sure, a few curly braces here and there doesn't hurt - but amongst
> beginners it is not something that is necessarily thought about.
>

How are you going to teach beginners about scopes if you don't *teach them
about scopes*? Which requires teaching them about braces and such. Indeed,
making them explicitly scope their variable declarations would do far more
good than this syntax at teaching them about scoping.

Furthermore, something far more important than scoping that beginners
should learn: not to shove a bunch of things into statements. If it's
between learning about ranges/adapters and learning about scoping of
variables, I'd rather they learn the former than the latter.

I wouldn't say that the improvement is significant, but I think
> "significant harm" is a slight exaggeration.
>

OK, how about, "it creates another vector for people to write bad code,
while doing little to improve code clarity?" That is, it will be abused far
more often than it improves anything. I would consider that justification
for calling it "significant harm".

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/741c91fa-0172-4f40-92f4-a1d5ede9bd2d%40isocpp.org.

------=_Part_96425_1027630625.1528694198937
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, June 10, 2018 at 9:44:22 PM UTC-4, Jake Arkinst=
all 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"auto"><d=
iv><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, 11 Jun 2018, 01:37 R=
en Industries, &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"pYsX9GfwBQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;j=
avascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;=
return true;">renind...@gmail.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">It is not obviously an improvement. I see it=
 as a significant harm, not an improvement.=C2=A0</div></blockquote></div><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">I can&#39;t see signific=
ant harm. I mean, it&#39;s just a way of introducing scope control with a f=
airly useful syntax that allows for multiple types. That&#39;s the bit I li=
ke here - generalizing the current approach with if( ; ) in a rather intere=
sting way:</div><div dir=3D"auto"><br></div><div dir=3D"auto">if([T a =3D .=
...; S b =3D ...]; some_bool_function(a,b)){</div><div dir=3D"auto">=C2=A0 =
=C2=A0do_the_thing(a, b);</div><div dir=3D"auto">}.</div><div dir=3D"auto">=
<br></div><div dir=3D"auto">Though other options do exist, this feels less =
hacky than, say, binding to some tautological combined object, existing sol=
ely for the purpose of binding to. If we had an auto which behaved like an =
auto rather than a ditto, we could get rid of those square brackets - but t=
hat&#39;s a debate that has been had before, and ended up in an impasse if =
I recall correctly.</div></div></blockquote><div><br></div><div>My recollec=
tion was that it ended up in &quot;OK, so you want `auto` to deduce multipl=
e types? Go convince the committee&quot;. Which was never attempted.</div><=
div><br></div><div>The principle objection to what was discussed before was=
 that it <i>wasn&#39;t</i> using `auto` to deduce different types, that (li=
ke this one) it was inventing a novel syntax for something we already know =
how it ought to be spelled. And since there are no grammatical issues with =
spelling it that way, any more grammar heavy spelling is pointless, and sol=
ves none of the problems with the core idea.<br></div><div><br></div><div> =
And the principle objection to any form of this basic idea (aka: declaring =
multiple variables of the same type in a single statement) is merely what I=
&#39;ve restated here: long statements are obscure statements, and obscurin=
g code is not something we should encourage.<br></div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div dir=3D"auto">=
</div><div dir=3D"auto">In terms of adding it to some other scope-inducing =
statements, I think it&#39;s reasonable - except for that do-while - on the=
 do by all means, but on the while has exactly one use case and it&#39;s a =
naff one. But in general this approach does encourage beginners to think ca=
refully about their scopes. Sure, a few curly braces here and there doesn&#=
39;t hurt - but amongst beginners it is not something that is necessarily t=
hought about.</div></div></blockquote><div><br></div><div>How are you going=
 to teach beginners about scopes if you don&#39;t <i>teach them about scope=
s</i>? Which requires teaching them about braces and such. Indeed, making t=
hem explicitly scope their variable declarations would do far more good tha=
n this syntax at teaching them about scoping.<br></div><div><br></div><div>=
Furthermore, something far more important than scoping that beginners shoul=
d learn: not to shove a bunch of things into statements. If it&#39;s betwee=
n learning about ranges/adapters and learning about scoping of variables, I=
&#39;d rather they learn the former than the latter.<br></div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"auto"><div dir=
=3D"auto"></div><div dir=3D"auto">I wouldn&#39;t say that the improvement i=
s significant, but I think &quot;significant harm&quot; is a slight exagger=
ation.</div></div></blockquote><div><br></div><div>OK, how about, &quot;it =
creates another vector for people to write bad code, while doing little to =
improve code clarity?&quot; That is, it will be abused far more often than =
it improves anything. I would consider that justification for calling it &q=
uot;significant harm&quot;.<br></div></div>

<p></p>

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

------=_Part_96425_1027630625.1528694198937--

------=_Part_96424_1222679911.1528694198936--

.

--000000000000cbf6ac056e577cbe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Do you want to allow that scoping block outside of a selection statement?

As an aside, I don't think this is a good idea. Even if we had this feature
I would never use it, because it would make my code unreadable.

I also don't really think that you're motivation is strong enough. Your for
loop can be rewritten to

for (std::size_t i =3D 1, bla_sz =3D bla.size(); i < bla_sz; ++i) {
    const size_t cmp_val =3D bla[0];
    if (/*...*/) break;
}

And I would even argue that you don't really need bla_sz. I find the above
way more readable than your loop.



On Sun, Jun 10, 2018, 3:42 PM U.Mutlu <for-gmane@mutluit.com> wrote:

> C++ core language extension proposal: "Allow Initializers Anywhere" (AIE)
>
> For defining variables anywhere:
>    [initializer-list]
>
> The vars in the [initializer-list] are known only after their occurance,
> of
> course.
> The vars are known only in their scope, of course.
>
> Applicable everywhere:
>   if ([initializer-list] ...) ...
>
>   switch ([initializer-list] ...) ...
>
>   for ([initializer-list] ...; ...; ...) ...
>
>   while ([initializer-list] ...) ...
>
>   do [initializer-list] ... while ([initializer-list2] ...);
>   // (initializer-list2 is limited in scope)
>
>   [initializer-list]
>   // (also anywhere w/o any association (of course then the braces are
> redundant))
>
> Example in a for-loop:
>    for ([const size_t bla_sz =3D bla.size(), cmp_val =3D bla[0]; bool f =
=3D
> false;]
>         size_t i =3D 1; !f && (i < bla_sz); ++i) ...
>
> Alternative syntax (maybe):
>   :initializer-list:
>
> Notes:
>    This a very powerful and easy to implement proposal. It allows to
> define
> any type of variables, also different types,
>    and also with attributes (ie. const, volatile etc.), practically
> anywhere
> (ie. free of context).
>    It generalizes and extends the "Initializers in if and switch
> statements"
> of C++17 that was proposed
>    by Thomas K=C3=B6ppe <tkoeppe@google.com> at
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r0.html
>    (ISO/IEC JTC1 SC22 WG21 P00305r0, Date: 2016-03-14, To: EWG, CWG)
>
> As I unfortunately don't have time to file an official proposal myself, I
> want
> to encourage others to do it.
> As said, it's very flexible and powerful (also for optimization), and at
> the
> same time very easy to implement into the core language as it's
> practically
> context-free.
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5B1D2AB5.406=
0409%40mutluit.com
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CALmDwq13ZK0BvMNHFmUY8GwtR%3DnHeAYZ2Dxbo5BAgRuZm=
MLiSw%40mail.gmail.com.

--000000000000cbf6ac056e577cbe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div dir=3D"auto">Do you want to allow that scoping block=
 outside of a selection statement?<div dir=3D"auto"><br></div><div dir=3D"a=
uto">As an aside, I don&#39;t think this is a good idea. Even if we had thi=
s feature I would never use it, because it would make my code unreadable.</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">I also don&#39;t really t=
hink that you&#39;re motivation is strong enough. Your for loop can be rewr=
itten to</div><div dir=3D"auto"><span style=3D"font-family:sans-serif;font-=
size:12.8px"><br></span></div><div dir=3D"auto"><font face=3D"sans-serif"><=
span style=3D"font-size:12.8px">for (std::size_t i =3D 1, bla_sz =3D bla.si=
ze(); i &lt; bla_sz; ++i) {</span></font></div><div dir=3D"auto"><font face=
=3D"sans-serif"><span style=3D"font-size:12.8px">=C2=A0 =C2=A0 const size_t=
 cmp_val =3D bla[0];</span></font></div><div dir=3D"auto"><font face=3D"san=
s-serif"><span style=3D"font-size:12.8px">=C2=A0 =C2=A0 if (/*...*/) break;=
</span></font></div><div dir=3D"auto"><font face=3D"sans-serif"><span style=
=3D"font-size:12.8px">}</span></font></div><div dir=3D"auto"><font face=3D"=
sans-serif"><span style=3D"font-size:12.8px"><br></span></font></div><div d=
ir=3D"auto"><span style=3D"font-family:sans-serif">And I would even argue t=
hat you don&#39;t really need bla_sz. I find the above way more readable th=
an your loop.</span><br></div><div dir=3D"auto"><span style=3D"font-family:=
sans-serif"><br></span></div><div dir=3D"auto"><span style=3D"font-family:s=
ans-serif"><br></span></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Sun, Jun 10, 2018, 3:42 PM U.Mutlu &lt;<a href=3D"mailto:for-gm=
ane@mutluit.com" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank"=
>for-gmane@mutluit.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">C++ core language extension proposal: &quot;Allow Initializers Anywhere&=
quot; (AIE)<br>
<br>
For defining variables anywhere:<br>
=C2=A0 =C2=A0[initializer-list]<br>
<br>
The vars in the [initializer-list] are known only after their occurance, of=
 <br>
course.<br>
The vars are known only in their scope, of course.<br>
<br>
Applicable everywhere:<br>
=C2=A0 if ([initializer-list] ...) ...<br>
<br>
=C2=A0 switch ([initializer-list] ...) ...<br>
<br>
=C2=A0 for ([initializer-list] ...; ...; ...) ...<br>
<br>
=C2=A0 while ([initializer-list] ...) ...<br>
<br>
=C2=A0 do [initializer-list] ... while ([initializer-list2] ...);<br>
=C2=A0 // (initializer-list2 is limited in scope)<br>
<br>
=C2=A0 [initializer-list]<br>
=C2=A0 // (also anywhere w/o any association (of course then the braces are=
 redundant))<br>
<br>
Example in a for-loop:<br>
=C2=A0 =C2=A0for ([const size_t bla_sz =3D bla.size(), cmp_val =3D bla[0]; =
bool f =3D false;]<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 size_t i =3D 1; !f &amp;&amp; (i &lt; bla_sz); =
++i) ...<br>
<br>
Alternative syntax (maybe):<br>
=C2=A0 :initializer-list:<br>
<br>
Notes:<br>
=C2=A0 =C2=A0This a very powerful and easy to implement proposal. It allows=
 to define <br>
any type of variables, also different types,<br>
=C2=A0 =C2=A0and also with attributes (ie. const, volatile etc.), practical=
ly anywhere <br>
(ie. free of context).<br>
=C2=A0 =C2=A0It generalizes and extends the &quot;Initializers in if and sw=
itch statements&quot; <br>
of C++17 that was proposed<br>
=C2=A0 =C2=A0by Thomas K=C3=B6ppe &lt;<a href=3D"mailto:tkoeppe@google.com"=
 rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">tkoe=
ppe@google.com</a>&gt; at <br>
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r0.=
html" rel=3D"noreferrer noreferrer noreferrer noreferrer noreferrer" target=
=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0305r0=
..html</a><br>
=C2=A0 =C2=A0(ISO/IEC JTC1 SC22 WG21 P00305r0, Date: 2016-03-14, To: EWG, C=
WG)<br>
<br>
As I unfortunately don&#39;t have time to file an official proposal myself,=
 I want <br>
to encourage others to do it.<br>
As said, it&#39;s very flexible and powerful (also for optimization), and a=
t the <br>
same time very easy to implement into the core language as it&#39;s practic=
ally <br>
context-free.<br>
<br>
<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%2Bunsubscribe@isocpp.org" rel=3D"no=
referrer noreferrer noreferrer noreferrer" target=3D"_blank">std-proposals+=
unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank"=
>std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5B1D2AB5.4060409%40mutluit.com" rel=
=3D"noreferrer noreferrer noreferrer noreferrer noreferrer" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5B1D2AB5.40=
60409%40mutluit.com</a>.<br>
</blockquote></div></div>

<p></p>

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

--000000000000cbf6ac056e577cbe--

.

On Monday, 11 June 2018 00:28:10 CEST U.Mutlu wrote:
> Thiago Macieira wrote on 06/10/2018 10:52 PM:
> > On Sunday, 10 June 2018 20:32:42 IST U.Mutlu wrote:
> >> It's been long ago with yacc & lex / bison & flex etc. :-), but I know
> >> for
> >> sure this is easy to implement.
> >
> > Can you provide a branch of Clang or GCC so we can test your proposal
> > then?
>
>  From what is proposed, do you really think it is very complicated to
> implement?

How would I know? I don't know the codebase of either GCC or Clang, or of
another front-end for that matter. The point is: *I* don't know but you seem
to. Since you have investigated and concluded it's easy, you must know *how*
it would be implemented in at least one compiler and you know how long it
would take you to implement it.

So, please implement it so we can experiment with the feature.

> It does not touch or disturb anything else, it's so to say
> "standalone". So, then logic dictates that it should be easy to implement.

Your logic is flawed.

> No, I cannot provide you a ready-made solution. What about your
> pre-judgement about a possible implementation?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6622740.kLYQeigjd5%40tjmaciei-mobl1.

.

On 2018-06-10 09:42, U.Mutlu wrote:
> C++ core language extension proposal: "Allow Initializers Anywhere" (AIE)
>=20
> For defining variables anywhere:
> =C2=A0 [initializer-list]
>=20
> The vars in the [initializer-list] are known only after their occurance,
> of course.
> The vars are known only in their scope, of course.
>=20
> Applicable everywhere:
> =C2=A0if ([initializer-list] ...) ...
>=20
> =C2=A0switch ([initializer-list] ...) ...
>=20
> =C2=A0for ([initializer-list] ...; ...; ...) ...
>=20
> =C2=A0while ([initializer-list] ...) ...
>=20
> =C2=A0do [initializer-list] ... while ([initializer-list2] ...);
> =C2=A0// (initializer-list2 is limited in scope)
>=20
> =C2=A0[initializer-list]
> =C2=A0// (also anywhere w/o any association (of course then the braces ar=
e
> redundant))
>=20
> Example in a for-loop:
> =C2=A0 for ([const size_t bla_sz =3D bla.size(), cmp_val =3D bla[0]; bool=
 f =3D
> false;]
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 size_t i =3D 1; !f && (i < bla_sz); =
++i) ...

Like others that have replied, I also don't see how this is an
improvement over:

  with (bool f =3D false)
  with (size_t const cmp_val =3D bla[0])
  for (size_t i : open_range(1, bla.size()) | interruptible(f))
  {
    ...
  }

....and, lo! You can already write that in C++17!

(Definition of the macro `with` and implementation of the range-adapter
`interruptible` is left as an exercise for the reader.)

p.s. Directly CC'ing Bjarne, Herb, etc. is pretty tacky (and probably a
good way to irritate them and lessen the chances of anyone =C2=AD=E2=80=94 =
them
especially =E2=80=94 taking you seriously). Despite an apparent belief to s=
uch
effect on your part, the committee does not exist for the sole purpose
of doing your bidding.

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/b3d28593-e568-780e-9980-fb3caac6bd74%40gmail.com=
..

.