------=_Part_160_1459743651.1407452572559
Content-Type: text/plain; charset=UTF-8

On Thursday, August 7, 2014 3:00:55 PM UTC-7, Andrew Tomazos wrote:
>
> I've conducted a quick study of ~50,000,000 lines of production Java code
> extracted from the Ubuntu package repository for usages of break label /
> continue label.  Results attached.
>
> Enjoy,
> Andrew.
>

Wow, thanks. =)  Even if this means the feature is not worthwhile.

Melissa

--

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

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

<div dir=3D"ltr">On Thursday, August 7, 2014 3:00:55 PM UTC-7, Andrew Tomaz=
os wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
 class=3D"gmail_quote"><div dir=3D"ltr">I've conducted a quick study of ~50=
,000,000 lines of production Java code extracted from the Ubuntu package re=
pository for usages of break label / continue label. &nbsp;Results attached=
..<div>
<br></div><div>Enjoy,</div>
<div>Andrew.</div></div></div></div></blockquote><div><br>Wow, thanks. =3D)=
&nbsp; Even if this means the feature is not worthwhile.<br><br>Melissa<br>=
</div></div>

<p></p>

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

------=_Part_160_1459743651.1407452572559--

.

------=_Part_116_1579752667.1407452732647
Content-Type: text/plain; charset=UTF-8

Thanks Andrew

Fascinating, thanks very much for this.

I'm still looking through some of the examples. Here's a few early
observations with:

1. I'm actually really really surprised at the hight use rate of the
feature.
I just wouldn't have and didn't credit it. Enlightening.

2.In saying that, I have to remind myself that java doesn't actually have a
goto statement.
So it has to use break whatever.
This statement isn't trying to say much, just a reminder.

3. In going through the examples, I was surprised how many times I found it
annoying and difficult
to find a break x, then have to scroll all the way up to find the for loop
for x, so I could then find the brace to scroll all the way down
to match it to the closing brace so I could work out where the code was
taking me.
I would much much prefer goto x: and just scroll down to find out where I
am going to.
On shorter loops, I'm sure this wouldn't matter but I imagine many loops
that are nested to begin with to require the feature
would be quote long. But I don't know.
I am making more of a statement here.

4. Overall. interesting.
Too early to tell if I am swayed or confirmed in my opinion from this, but
fascinated.

On Friday, August 8, 2014 10:00:55 AM UTC+12, Andrew Tomazos wrote:

> I've conducted a quick study of ~50,000,000 lines of production Java code
> extracted from the Ubuntu package repository for usages of break label /
> continue label.  Results attached.
>
> Enjoy,
> Andrew.
>
>
>

--

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

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

<div dir=3D"ltr"><div>Thanks Andrew</div><div><br></div><div>Fascinating, t=
hanks very much for this.</div><div><br></div><div>I'm still looking throug=
h some of the examples. Here's a few early observations with:</div><div><br=
></div><div>1. I'm actually really really surprised at the hight use rate o=
f the feature.</div><div>I just wouldn't have and didn't credit it. Enlight=
ening.</div><div><br></div><div>2.In saying that, I have to remind myself t=
hat java doesn't actually have a goto statement.</div><div>So it has to use=
 break whatever.</div><div>This statement isn't trying to say much, just a =
reminder.</div><div><br></div><div>3. In going through the examples, I was =
surprised how many times I found it annoying and difficult</div><div>to fin=
d a break x, then have to scroll all the way up to find the for loop for x,=
 so I could then find the brace to scroll all the way&nbsp;down</div><div>t=
o match it to the closing brace so I could work out where the code was taki=
ng me.</div><div>I would much much prefer goto x: and just scroll down to f=
ind out where I am going to.</div><div>On shorter loops, I'm sure this woul=
dn't matter but I imagine many loops that are nested to begin with to requi=
re the feature</div><div>would be quote long. But I don't know.</div><div>I=
 am making more of a statement here.</div><div><br></div><div>4. Overall. i=
nteresting.</div><div>Too early to tell if I am swayed or confirmed in my o=
pinion from this, but fascinated.<br><br>On Friday, August 8, 2014 10:00:55=
 AM UTC+12, Andrew Tomazos wrote:</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb=
(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><div di=
r=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">I've conducted a quic=
k study of ~50,000,000 lines of production Java code extracted from the Ubu=
ntu package repository for usages of break label / continue label. &nbsp;Re=
sults attached.<div>
<br></div><div>Enjoy,</div>
<div>Andrew.</div><div><br></div></div>
</div><br></div>
</blockquote></div>

<p></p>

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

------=_Part_116_1579752667.1407452732647--

.

--Apple-Mail=_CDE00F6D-A002-42F7-89A6-E6E10B094EE2
Content-Type: text/plain; charset=ISO-8859-1


On 2014-08-09, at 1:35 PM, Myriachan <myriachan@gmail.com> wrote:

> One advantage with this chained break syntax is that it can be used more easily with macros,

Usually not. It depends on the application, but a macro-based facility which defines the loop, and then wants to escape from it, does not generally know whether the user added an inner loop surrounding the escape point. Labels are necessary.

> but I'd rather have Visual C++'s__COUNTER__ be standardized, personally. =)

It doesn't work with the ODR. Never use __COUNTER__ in a header file. Prefer __LINE__ or my overloading trick.

--

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

--Apple-Mail=_CDE00F6D-A002-42F7-89A6-E6E10B094EE2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08&ndash;09, at 1:35 PM, Myriachan &lt;<a href=3D"mailto:myriachan@gm=
ail.com">myriachan@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interch=
ange-newline"><blockquote type=3D"cite"><div style=3D"font-family: Helvetic=
a; font-size: 12px; font-style: normal; font-variant: normal; font-weight: =
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-al=
ign: start; text-indent: 0px; text-transform: none; white-space: normal; wi=
dows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D=
"ltr">One advantage with this chained break syntax is that it can be used m=
ore easily with macros, </div></div></blockquote><div><br></div><div>Usuall=
y not. It depends on the application, but a macro-based facility which defi=
nes the loop, and then wants to escape from it, does not generally know whe=
ther the user added an inner loop surrounding the escape point. Labels are =
necessary.</div><br><blockquote type=3D"cite"><div style=3D"font-family: He=
lvetica; font-size: 12px; font-style: normal; font-variant: normal; font-we=
ight: normal; letter-spacing: normal; line-height: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div =
dir=3D"ltr">but I'd rather have Visual C++'s<span style=3D"font-family: 'co=
urier new', monospace;">__COUNTER__</span>&nbsp;be standardized, personally=
.. =3D)<br></div></div></blockquote><div><br></div>It doesn&rsquo;t work wit=
h the ODR. Never use <font face=3D"Courier">__COUNTER__</font> in a header =
file. Prefer <font face=3D"Courier">__LINE__</font> or my&nbsp;<a href=3D"h=
ttp://stackoverflow.com/a/6174263/153285">overloading trick</a>.</div><div>=
<br></div></body></html>

<p></p>

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

--Apple-Mail=_CDE00F6D-A002-42F7-89A6-E6E10B094EE2--

.

--Apple-Mail=_6E49E113-4B46-4EA6-B3F7-B956E4CD898E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-08-16, at 5:09 AM, gmisocpp@gmail.com wrote:

> Forgive me, but this conversation lacks direction and it's going nowhere.=
 You seem to be trying to drive a wedge by saying you support the proposal =
when you're simply opposed. You requested bogus "metrics," then when others=
 indulged that fallacious argument you changed the goalpost again. Now ever=
yone is trying to guess what would make the proposal aesthetically perfect =
for you personally. It's unkind to send others on such a fool's errand.
>=20
> I don't like the aggressive suggestion or characterization. I'm not tryin=
g to drive wedges anywhere, I'm participating in a discussion about a featu=
re that I admittedly don't find compelling because I haven't come across gr=
eat use for it and I've admitted that

If you can't find why it would be useful, then how could you possibly suppo=
rt it? Even if you're trying to be supportive, you make it sound like it ta=
kes some imagination to find a use case. It doesn't. We don't need to find =
a "great" use either; the advantage is to make mundane code look more munda=
ne.

    bool all_good =3D true;
bad_elem_search:
    for ( auto && outer_elem : outer ) {
        for ( auto && inner_elem : inner ) {
            if ( ! good( inner_elem ) ) {
                all_good =3D false;
                break bad_elem_search;
            }
            if ( inner_elem.successors_all_valid() ) {
                continue bad_elem_search;
            }
        }
    }

It doesn't seek to be revolutionary or indispensable, it's just more legibl=
e than goto because

1. The label is grouped with the loop controls, so it won't get lost in ref=
actoring.
2. The break/continue keyword indicates that it's only a break/continue, no=
t a more exotic sort of goto.
3. A label on a loop names what the loop does. A label after a loop must na=
me the postcondition, which is usually awkward.

Plenty of folks would use such a feature, because it's simply the overlap o=
f break/continue usage and nested loops. Plenty of folks would not. If you =
fall into the latter category, that's not a good position to improve it. Bu=
ilding consensus requires understanding the majority of supporters. Saying =
you're trying to build consensus but ignoring (or not comprehending) the ex=
isting consensus among users and supporters is driving a wedge. Although no=
body seems to be supporting your tweaks, the discussion still makes it look=
 like there's fragmentation where there's not.

The division of the committee vote was most likely not over the minutiae of=
 scoping and syntax, but whether such nested loop structures should be enco=
uraged or beautified. Personally, I do tend to avoid nested loops, because =
they tend to indicate polynomial complexity. There are plenty of instances =
where they don't, though, and an early exit can improve big-O runtime vs. a=
 poorly implemented flag. I think the feature might be proposed again witho=
ut any changes, but with examples of how it encourages fast programs and ma=
lleable code. N3879 had almost no such advocacy.

--=20

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

--Apple-Mail=_6E49E113-4B46-4EA6-B3F7-B956E4CD898E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08&ndash;16, at 5:09 AM, <a href=3D"mailto:gmisocpp@gmail.com">gmisoc=
pp@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><block=
quote type=3D"cite"><blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bo=
rder-left-width: 1px; border-left-style: solid; position: static; z-index: =
auto;">Forgive me, but this conversation lacks direction and it&rsquo;s goi=
ng nowhere. You seem to be trying to drive a wedge by saying you support th=
e proposal when you&rsquo;re simply opposed. You requested bogus &ldquo;met=
rics,&rdquo; then when others indulged that fallacious argument you changed=
 the goalpost again. Now everyone is trying to guess what would make the pr=
oposal aesthetically perfect for you personally. It&rsquo;s unkind to send =
others on such a fool&rsquo;s errand.</blockquote><div><br></div><div><div =
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-=
variant: normal; font-weight: normal; letter-spacing: normal; line-height: =
normal; orphans: auto; text-align: start; text-indent: 0px; text-transform:=
 none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-s=
troke-width: 0px;">I don't like the aggressive suggestion or characterizati=
on. I'm not trying to drive wedges anywhere, I'm participating in a discuss=
ion about a feature that I admittedly don't find compelling because I haven=
't come across great use for it and I've admitted that </div></div></blockq=
uote><div><br></div><div>If you can&rsquo;t find why it would be useful, th=
en how could you possibly support it? Even if you&rsquo;re trying to be sup=
portive, you make it sound like it takes some imagination to find a use cas=
e. It doesn&rsquo;t. We don&rsquo;t need to find a &ldquo;great&rdquo; use =
either; the advantage is to make mundane code look&nbsp;more mundane.</div>=
<div><br></div><div><font face=3D"Courier">&nbsp; &nbsp; bool all_good =3D =
true;</font></div><div><font face=3D"Courier">bad_elem_search:</font></div>=
<div><font face=3D"Courier">&nbsp; &nbsp; for ( auto &amp;&amp; outer_elem =
: outer ) {</font></div><div><font face=3D"Courier">&nbsp; &nbsp; &nbsp; &n=
bsp; for ( auto &amp;&amp; inner_elem : inner ) {</font></div><div><font fa=
ce=3D"Courier">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if ( ! good( inner=
_elem ) ) {</font></div><div><font face=3D"Courier">&nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; all_good =3D false;</font></div><div><div>=
<font face=3D"Courier">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; break bad_elem_search;</font></div><div><font face=3D"Courier">&nbsp; &=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }</font></div><div><font face=3D"Courier"=
>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if ( inner_elem.successors_all_v=
alid() ) {</font></div><div><font face=3D"Courier">&nbsp; &nbsp; &nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; continue bad_elem_search;</font></div><div>=
<font face=3D"Courier">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }</font></=
div><div><font face=3D"Courier">&nbsp; &nbsp; &nbsp; &nbsp; }</font></div><=
div><font face=3D"Courier">&nbsp; &nbsp; }</font></div></div><div><br></div=
><div>It doesn&rsquo;t seek to be revolutionary or indispensable, it&rsquo;=
s just more legible than <font face=3D"Courier">goto</font> because</div><d=
iv><br></div><div>1. The label is grouped with the loop controls, so it won=
&rsquo;t get lost in refactoring.</div><div>2. The <font face=3D"Courier">b=
reak</font>/<font face=3D"Courier">continue</font> keyword indicates that i=
t&rsquo;s only a&nbsp;<font face=3D"Courier">break</font>/<font face=3D"Cou=
rier">continue</font>, not a more exotic sort of <font face=3D"Courier">got=
o</font>.</div><div>3. A label on a loop names what the loop does. A label =
after a loop must name the postcondition, which is usually awkward.</div><d=
iv><br></div><div>Plenty of folks would use such a feature, because it&rsqu=
o;s simply the overlap of&nbsp;<font face=3D"Courier">break</font>/<font fa=
ce=3D"Courier">continue</font>&nbsp;usage and nested loops. Plenty of folks=
 would not. If you fall into the latter category, that&rsquo;s not a good p=
osition to improve it. Building consensus requires understanding the majori=
ty of supporters. Saying you&rsquo;re trying to build consensus but ignorin=
g (or not comprehending) the existing consensus among users and supporters =
is driving a wedge. Although nobody seems to be supporting your tweaks, the=
 discussion still makes it look like there&rsquo;s fragmentation where ther=
e&rsquo;s not.</div></div><div><br></div><div>The division of the committee=
 vote was most likely not over the minutiae of scoping and syntax, but whet=
her such nested loop structures should be encouraged or beautified. Persona=
lly, I do tend to avoid nested loops, because they tend to indicate polynom=
ial complexity. There are plenty of instances where they don&rsquo;t, thoug=
h, and an early exit can improve big-O runtime vs. a poorly implemented fla=
g. I think the feature might be proposed again without any changes, but wit=
h examples of how it encourages fast programs and malleable code. N3879 had=
 almost no such advocacy.</div><div><br></div></body></html>

<p></p>

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

--Apple-Mail=_6E49E113-4B46-4EA6-B3F7-B956E4CD898E--

.

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


On Saturday, August 16, 2014 1:56:48 PM UTC+12, David Krauss wrote:
>
>
> If you can=E2=80=99t find why it would be useful, then how could you poss=
ibly=20
> support it?
>

Because I look at the arguments of those who DO find it useful and try=20
to support that. But... In other words:
If you are building a mouse trap, I don't have to have mice to want to help=
=20
you improve it.
But nor does that mean I can't also question if we really have a rodent=20
problem.
What's hard to grasp about that?

I've been supportive as I can be in that context, I asked if scoping would=
=20
help improve the proposal or not, or if the label would be better if it=20
were as tight as possible with the loop, to be supportive. I can't help you=
=20
don't like the ideas. I'm happy you shoot them down too with good argument,=
=20
It just doesn't require unfriendly characterisation and conspiracies to do=
=20
that or being so binary in a you are either with us, against us, or trying=
=20
to scupper us kind of manner. Relax.
=20

> Even if you=E2=80=99re trying to be supportive, you make it sound like it=
 takes=20
> some imagination to find a use case. It doesn=E2=80=99t.
>

Similar arguments come up in the discussion of marriage. lol

I saw you're use case before, and what part about the my "all agreed"=20
sentence did you not see in my post about your use case?

But equally it has taken 30 years for this idea to still not quite come to=
=20
fruition yet, so obviously more peoples imagination are effected here than=
=20
your statement would suggest. And people still argue for Properties because=
=20
every other language has it.
What dreams may come.
=20

> We don=E2=80=99t need to find a =E2=80=9Cgreat=E2=80=9D use either; the a=
dvantage is to make=20
> mundane code look more mundane.
>

Forgive me all to hell for trying to improve an idea.

One minute I'm not supportive, the next minute I'm driving a wedge, and the=
=20
next minute I'm too supportive because my idea is not needed.=20

If you want to talk about what We need, we *need* is to encourage people=20
to participate in the C++ community and grow the support base so there's=20
more We. A task best achieved if you don't shout contributors down with=20
"this discussion is going no where" type stuff, and conspiracy talk of=20
wedges, or accusing anyone who isn't yet sold on an idea as having=20
problems with their imagination.
=20

>
>     bool all_good =3D true;
> bad_elem_search:
>     for ( auto && outer_elem : outer ) {
>         for ( auto && inner_elem : inner ) {
>             if ( ! good( inner_elem ) ) {
>                 all_good =3D false;
>                 break bad_elem_search;
>             }
>             if ( inner_elem.successors_all_valid() ) {
>                 continue bad_elem_search;
>             }
>         }
>     }
>
> It doesn=E2=80=99t seek to be revolutionary or indispensable, it=E2=80=99=
s just more=20
> legible than goto because
>
> 1. The label is grouped with the loop controls, so it won=E2=80=99t get l=
ost in=20
> refactoring.
>

Sure, but the label is still before the loop so it can still get lost in=20
refactoring which is why I contributed the probably not original idea that=
=20
maybe the label should be part of the for, not before it, so it is even=20
less likely to get lost.

But you don't like such contributions, talk about control statements.
=20

> 2. The break/continue keyword indicates that it=E2=80=99s only a break/co=
ntinue,=20
> not a more exotic sort of goto.
> 3. A label on a loop names what the loop does. A label after a loop must=
=20
> name the postcondition, which is usually awkward.
>
> Plenty of folks would use such a feature, because it=E2=80=99s simply the=
 overlap=20
> of break/continue usage and nested loops. Plenty of folks would not. If=
=20
> you fall into the latter category, that=E2=80=99s not a good position to =
improve=20
> it. Building consensus requires understanding the majority of supporters.=
=20
> Saying you=E2=80=99re trying to build consensus but ignoring (or not comp=
rehending)=20
> the existing consensus among users and supporters is driving a wedge.=20
> Although nobody seems to be supporting your tweaks, the discussion still=
=20
> makes it look like there=E2=80=99s fragmentation where there=E2=80=99s no=
t.
>

Consensus takes time because you have to convince. I'm sorry you want to=20
dispense with that sooner than is required. I can sympathise but that's=20
about it in this case. I do see a consensus, but the numbers appear small=
=20
and minorities are often vocal.
That's why it takes time to determine but discussions like this draw people=
=20
out to voice their views.

I appreciate the problem you are worrying about here does happen, but=20
that's life. I'm not going to apologize for participating.

And getting consensus has lots of forms, I asked for things like stats, and=
=20
they have kindly appeared. I've been unsure about the value of some parts=
=20
and you've come out to defend that value, I think that has helped your case=
=20
regardless of what I think of the proposal so I'm not going to apologize=20
for doing that. It's useful in my opinion and I'm more swayed than what I=
=20
was so no doubt others will be. But you just seem to have been=20
bitten before, with talks of wedges, such that you don't see this other=20
scenario of consensus finding is possible anymore, but not every issue is=
=20
that difficult to worry about that.


> The division of the committee vote was most likely not over the minutiae=
=20
> of scoping and syntax, but whether such nested loop structures should be=
=20
> encouraged or beautified. Personally, I do tend to avoid nested loops,=20
> because they tend to indicate polynomial complexity. There are plenty of=
=20
> instances where they don=E2=80=99t, though, and an early exit can improve=
 big-O=20
> runtime vs. a poorly implemented flag.
>

I agree.
=20

> I think the feature might be proposed again without any changes, but with=
=20
> examples of how it encourages fast programs and malleable code. N3879 had=
=20
> almost no such advocacy.
>
>
If the Committee weren't sold the first time, it might be simply=20
because many examples are solved with one single goto and we have that=20
capability today. The proposed feature requires having to scroll up to find=
=20
the destination, then down to brace match to really find the real=20
destination. They might take the view that a goto and label mark exactly=20
where the destination is and it's usually forward, with no matching=20
required. However with an IDE the proposed type of loop becomes gives you a=
=20
choice of destinations, the closing brace or the loop beginning and it can=
=20
help you find either which is good too.

So we'll see. It's looking favourable for your goals as I see consensus=20
for, but in small numbers so far.

Overall, I understand your proposal fears but they seem overblown and=20
misplaced in this instance and I'm sure the Committee won't veto this=20
proposal based on anything I have to say, because the feature isn't=20
dangerous, it's at worst "meh". That's something I've already said.

So I think the Committee will if in doubt, vote this proposal in anyway as=
=20
it can't hurt if there is some consensus. But they might want to see that=
=20
and in bigger numbers. Talking about it helps draw those numbers in. But=20
if they instead advocate "meh, use goto and get over it, there's better=20
things to talk about" instead, it'll explain why it's taken 30 years to=20
appear so far and I won't cry either way because I have sympathies for both=
=20
views, even if you'd like me to be binary about it. So I'll go with both=20
those views even within myself until a consensus forms within myself. It=20
isn't that hard to understand or unreasonable really as you think.

I'm sure the right outcome will happen here regardless.

--=20

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

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

<div dir=3D"ltr"><br>On Saturday, August 16, 2014 1:56:48 PM UTC+12, David =
Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;"><div style=3D"-ms-word-wrap: brea=
k-word;"><div><div><br></div><div>If you can=E2=80=99t find why it would be=
 useful, then how could you possibly support it?</div></div></div></blockqu=
ote><div><br></div><div>Because I&nbsp;look at the arguments&nbsp;of those =
who&nbsp;DO find it useful and try to&nbsp;support that. But... In other wo=
rds:</div><div>If you are building a mouse trap, I don't have to have mice =
to want to help you improve it.</div><div>But nor does that mean I can't al=
so question if we really have a rodent problem.</div><div>What's hard to gr=
asp about that?</div><div><br></div><div>I've been&nbsp;supportive as I can=
 be in that context, I&nbsp;asked if&nbsp;scoping would help improve the pr=
oposal&nbsp;or not, or if the label would be better if it were as tight as =
possible with the loop,&nbsp;to be supportive. I can't help you don't like =
the ideas. I'm happy you shoot them down too with good argument, It just do=
esn't require&nbsp;unfriendly characterisation and conspiracies&nbsp;to do =
that or being so binary in a you are either with us, against us, or trying =
to scupper us kind of manner. Relax.</div><div>&nbsp;</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bo=
rder-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-st=
yle: solid;"><div style=3D"-ms-word-wrap: break-word;"><div><div> Even if y=
ou=E2=80=99re trying to be supportive, you make it sound like it takes some=
 imagination to find a use case. It doesn=E2=80=99t.</div></div></div></blo=
ckquote><div><br></div><div>Similar&nbsp;arguments come up&nbsp;in the disc=
ussion of&nbsp;marriage. lol</div><div><br></div><div>I saw&nbsp;you're use=
 case before, and what part about the&nbsp;my "all agreed" sentence did you=
 not see in my&nbsp;post about your use case?</div><div><br></div><div>But =
equally it has taken 30 years&nbsp;for this idea to still not quite come to=
 fruition yet, so obviously&nbsp;more peoples&nbsp;imagination&nbsp;are eff=
ected&nbsp;here than your statement would suggest. And people still argue f=
or Properties because every other language has it.</div><div>What dreams ma=
y come.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204=
, 204); border-left-width: 1px; border-left-style: solid;"><div style=3D"-m=
s-word-wrap: break-word;"><div><div> We don=E2=80=99t need to find a =E2=80=
=9Cgreat=E2=80=9D use either; the advantage is to make mundane code look&nb=
sp;more mundane.</div></div></div></blockquote><div><br></div><div>Forgive =
me all to hell for trying to improve an idea.</div><div><br></div><div>One =
minute I'm not supportive, the next minute I'm driving a wedge, and the nex=
t minute I'm too supportive because my idea is not needed. </div><div><br><=
/div><div>If you want to talk about what We need,&nbsp;we *need* is to enco=
urage people to&nbsp;participate in the&nbsp;C++ community and grow the&nbs=
p;support base so there's more We. A task best achieved if you don't&nbsp;s=
hout contributors down with "this discussion is going no where" type stuff,=
 and conspiracy talk of wedges,&nbsp;or accusing anyone&nbsp;who isn't yet =
sold on an idea&nbsp;as having problems&nbsp;with their imagination.</div><=
div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><div style=3D"-ms-word-wrap: b=
reak-word;"><div><div><br></div><div><font face=3D"Courier">&nbsp; &nbsp; b=
ool all_good =3D true;</font></div><div><font face=3D"Courier">bad_elem_sea=
rch:</font></div><div><font face=3D"Courier">&nbsp; &nbsp; for ( auto &amp;=
&amp; outer_elem : outer ) {</font></div><div><font face=3D"Courier">&nbsp;=
 &nbsp; &nbsp; &nbsp; for ( auto &amp;&amp; inner_elem : inner ) {</font></=
div><div><font face=3D"Courier">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; i=
f ( ! good( inner_elem ) ) {</font></div><div><font face=3D"Courier">&nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; all_good =3D false;</font=
></div><div><div><font face=3D"Courier">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp; &nbsp; break bad_elem_search;</font></div><div><font face=3D"=
Courier">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }</font></div><div><font=
 face=3D"Courier">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if ( inner_elem=
..successors_all_<wbr>valid() ) {</font></div><div><font face=3D"Courier">&n=
bsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; continue bad_elem_sea=
rch;</font></div><div><font face=3D"Courier">&nbsp; &nbsp; &nbsp; &nbsp; &n=
bsp; &nbsp; }</font></div><div><font face=3D"Courier">&nbsp; &nbsp; &nbsp; =
&nbsp; }</font></div><div><font face=3D"Courier">&nbsp; &nbsp; }</font></di=
v></div><div><br></div><div>It doesn=E2=80=99t seek to be revolutionary or =
indispensable, it=E2=80=99s just more legible than <font face=3D"Courier">g=
oto</font> because</div><div><br></div><div>1. The label is grouped with th=
e loop controls, so it won=E2=80=99t get lost in refactoring.</div></div></=
div></blockquote><div><br></div><div>Sure, but the label is still before th=
e loop so it can still get lost in refactoring which is why I contributed t=
he probably not original idea&nbsp;that maybe the label should be part of t=
he for, not&nbsp;before it, so it is even less likely to get lost.</div><di=
v><br></div><div>But you don't like such contributions, talk about control =
statements.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(20=
4, 204, 204); border-left-width: 1px; border-left-style: solid;"><div style=
=3D"-ms-word-wrap: break-word;"><div><div>2. The <font face=3D"Courier">bre=
ak</font>/<font face=3D"Courier">continue</font> keyword indicates that it=
=E2=80=99s only a&nbsp;<font face=3D"Courier">break</font>/<font face=3D"Co=
urier">continue</font>, not a more exotic sort of <font face=3D"Courier">go=
to</font>.</div><div>3. A label on a loop names what the loop does. A label=
 after a loop must name the postcondition, which is usually awkward.</div><=
div><br></div><div>Plenty of folks would use such a feature, because it=E2=
=80=99s simply the overlap of&nbsp;<font face=3D"Courier">break</font>/<fon=
t face=3D"Courier">continue</font>&nbsp;usage and nested loops. Plenty of f=
olks would not. If you fall into the latter category, that=E2=80=99s not a =
good position to improve it. Building consensus requires understanding the =
majority of supporters. Saying you=E2=80=99re trying to build consensus but=
 ignoring (or not comprehending) the existing consensus among users and sup=
porters is driving a wedge. Although nobody seems to be supporting your twe=
aks, the discussion still makes it look like there=E2=80=99s fragmentation =
where there=E2=80=99s not.</div></div></div></blockquote><div><br></div><di=
v>Consensus&nbsp;takes time because you have to convince. I'm sorry you wan=
t to dispense with that sooner than is required. I can sympathise but that'=
s about it in this case. I do see a consensus, but the numbers&nbsp;appear =
small and&nbsp;minorities are often vocal.</div><div>That's why it takes ti=
me to determine but discussions like this draw people out to&nbsp;voice the=
ir&nbsp;views.</div><div><br></div><div><div><div>I appreciate the problem =
you are worrying about here does happen, but that's life. I'm not going to =
apologize for participating.</div></div></div><div><br></div><div>And getti=
ng consensus has lots of forms, I asked for things like stats, and they hav=
e kindly appeared. I've been unsure about the value of some parts and you'v=
e come out to defend that value, I think that has helped your case regardle=
ss of what I think of the proposal so&nbsp;I'm not going to apologize for&n=
bsp;doing that. It's useful in my opinion and I'm more swayed than what I w=
as so no doubt others will be.&nbsp;But you just seem to&nbsp;have been bit=
ten&nbsp;before, with talks of&nbsp;wedges, such that you don't see this ot=
her scenario of&nbsp;consensus finding&nbsp;is possible anymore, but not ev=
ery issue is that difficult to worry about that.</div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-lef=
t: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; bord=
er-left-style: solid;"><div style=3D"-ms-word-wrap: break-word;"><div><br><=
/div><div>The division of the committee vote was most likely not over the m=
inutiae of scoping and syntax, but whether such nested loop structures shou=
ld be encouraged or beautified. Personally, I do tend to avoid nested loops=
, because they tend to indicate polynomial complexity. There are plenty of =
instances where they don=E2=80=99t, though, and an early exit can improve b=
ig-O runtime vs. a poorly implemented flag.</div></div></blockquote><div><b=
r></div><div>I agree.</div><div>&nbsp;</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color=
: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><d=
iv style=3D"-ms-word-wrap: break-word;"><div> I think the feature might be =
proposed again without any changes, but with examples of how it encourages =
fast programs and malleable code. N3879 had almost no such advocacy.</div><=
div><br></div></div></blockquote><div><br></div><div>If the Committee weren=
't sold the first time, it might be simply because&nbsp;many examples are s=
olved with one single goto and we have that capability today. The proposed =
feature requires having&nbsp;to scroll up to find the destination,&nbsp;the=
n down to brace match to really find the real destination. They might&nbsp;=
take the view&nbsp;that a goto and label mark exactly where the destination=
&nbsp;is and it's usually forward, with no matching required. However with =
an IDE the proposed type of loop becomes&nbsp;gives&nbsp;you a choice of de=
stinations, the closing brace or the loop beginning and it can help you fin=
d either which is good too.</div><div><br></div><div>So we'll see. It's loo=
king favourable for your goals as&nbsp;I see consensus for, but in small nu=
mbers so far.</div><div><br></div><div>Overall, I understand your proposal =
fears but they seem overblown and misplaced in this instance and I'm sure t=
he Committee won't veto this proposal based on anything I have to say, beca=
use&nbsp;the feature isn't dangerous, it's at worst "meh". That's something=
 I've already said.</div><div><br></div><div>So&nbsp;I think the Committee&=
nbsp;will if&nbsp;in doubt,&nbsp;vote&nbsp;this proposal in anyway as it ca=
n't hurt if there is some consensus.&nbsp;But they might want to see that a=
nd&nbsp;in bigger numbers.&nbsp;Talking about it&nbsp;helps draw those numb=
ers&nbsp;in. But if&nbsp;they&nbsp;instead advocate "meh, use goto and&nbsp=
;get over it,&nbsp;there's better things to talk about" instead,&nbsp;it'll=
 explain why it's taken 30 years to appear so far and I won't cry either wa=
y because I have sympathies for both views, even if you'd like me to be bin=
ary about it. So I'll go with both those views even within myself until a c=
onsensus forms within myself. It isn't that hard to understand or unreasona=
ble really as you think.</div><div><br></div><div>I'm sure the right outcom=
e will happen here regardless.</div></div>

<p></p>

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

------=_Part_1560_1206638792.1408187438703--

.

On 16 August 2014 14:10,  <gmisocpp@gmail.com> wrote:
> But equally it has taken 30 years for this idea to still not quite come to
> fruition yet, so obviously more peoples imagination are effected here than
> your statement would suggest. And people still argue for Properties because
> every other language has it.

I recommend caution with such statements; not every other language has
properties,
quite many of them don't.

> So I think the Committee will if in doubt, vote this proposal in anyway as
> it can't hurt if there is some consensus. But they might want to see that

If in doubt, the committee will most certainly reject it. It's very
unlikely that
we would accept a proposal with "well, it can't hurt.. much". And "consensus"
on this particular forum doesn't mean squat. :)

> and in bigger numbers. Talking about it helps draw those numbers in. But if
> they instead advocate "meh, use goto and get over it, there's better things
> to talk about" instead, it'll explain why it's taken 30 years to appear so

Having rejected the previous proposal quite recently, the committee's
first question
to a revised proposal would be "what's different this time?" So, if
people care about
this proposed facility, they need to present strong motivation for it.
This forum
is not any official litmus test, but one might doubt the chance of
convincing the
committee if even people on this forum aren't convinced. Furthermore, the
previous proposal didn't pass through Evolution Working Group. After passing
EWG, a proposal would still need to pass through Core, and a full committee
vote, to get adopted. So any further proposal for these facilities
should be much
more convincing than the previous one, and I have trouble imagining what
changes would make it that much more convincing.

--

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

.

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

On Sat, Aug 16, 2014 at 11:30 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 16 August 2014 14:10,  <gmisocpp@gmail.com> wrote:
> > But equally it has taken 30 years for this idea to still not quite come
> to
> > fruition yet, so obviously more peoples imagination are effected here
> than
> > your statement would suggest. And people still argue for Properties
> because
> > every other language has it.
>
> I recommend caution with such statements; not every other language has
> properties,
> quite many of them don't.
>

Yes perhaps I exaggerated. C# and Java were on my mind, large by market
share, but that's not % of all languages, so point taken.


>
> > So I think the Committee will if in doubt, vote this proposal in anyway
> as
> > it can't hurt if there is some consensus. But they might want to see that
>
> If in doubt, the committee will most certainly reject it. It's very
> unlikely that
> we would accept a proposal with "well, it can't hurt.. much". And
> "consensus"
> on this particular forum doesn't mean squat. :)
>
> > and in bigger numbers. Talking about it helps draw those numbers in. But
> if
> > they instead advocate "meh, use goto and get over it, there's better
> things
> > to talk about" instead, it'll explain why it's taken 30 years to appear
> so
>
> Having rejected the previous proposal quite recently, the committee's
> first question
> to a revised proposal would be "what's different this time?" So, if
> people care about
> this proposed facility, they need to present strong motivation for it.
> This forum
> is not any official litmus test, but one might doubt the chance of
> convincing the
> committee if even people on this forum aren't convinced. Furthermore, the
> previous proposal didn't pass through Evolution Working Group. After
> passing
> EWG, a proposal would still need to pass through Core, and a full committee
> vote, to get adopted. So any further proposal for these facilities
> should be much
> more convincing than the previous one, and I have trouble imagining what
> changes would make it that much more convincing.
>

I'd agree, but that appears to present a pretty impossible challenge then
if it's true.

Because on the one hand, you're saying they've rejected this proposal
already and they'll likely rejected it again if there isn't something new
on the table.

But on the other hand you seem to be saying if we discuss this more to
see try to get that something new like I've been trying, then that might
just cause more dissent and they'll reject it on that basis too as David is
fearful of.

So it would appear the proposal is damned either way and already was,
because my lone dissent will not have dissuaded anyone.

But there is "a lot" of consensus on here For the proposal, at least in the
people who have messaged here. it appeared to me I am the only dissenting
voice here and I'm weekly against at worst, to weekly for a best, but
everyone else who has contributed seems mainly pro the proposal, I just
couldn't get a feel for if that is a vocal minority or not.

Do you really think it's that bleak in that context?

The "for" camp seem to be in this no win position damned either way: can't
discuss to get new ideas, can't risk dissent to make things worse. Can you
suggest a path forward beyond just giving up on the proposal that doesn't
fall victim to either of these two paths which you have just warned both
will likely result in failure?

Or maybe I'm missing something here.

Thanks


>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/QFo3J1rQIZo/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sat, Aug 16, 2014 at 11:30 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<=
a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.vouti=
lainen@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid"><div>On 16 August 2014 14:10,=C2=A0 &lt;<a href=3D"mailto:=
gmisocpp@gmail.com">gmisocpp@gmail.com</a>&gt; wrote:<br>

&gt; But equally it has taken 30 years for this idea to still not quite com=
e to<br>
&gt; fruition yet, so obviously more peoples imagination are effected here =
than<br>
&gt; your statement would suggest. And people still argue for Properties be=
cause<br>
&gt; every other language has it.<br>
<br>
</div>I recommend caution with such statements; not every other language ha=
s<br>
properties,<br>
quite many of them don&#39;t.<br></blockquote><div><br></div><div>Yes perha=
ps I exaggerated. C# and Java=C2=A0were on my mind, large by market share, =
but that&#39;s not % of all languages,=C2=A0so point taken.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px=
;border-left-style:solid">

<div><br>
&gt; So I think the Committee will if in doubt, vote this proposal in anywa=
y as<br>
&gt; it can&#39;t hurt if there is some consensus. But they might want to s=
ee that<br>
<br>
</div>If in doubt, the committee will most certainly reject it. It&#39;s ve=
ry<br>
unlikely that<br>
we would accept a proposal with &quot;well, it can&#39;t hurt.. much&quot;.=
 And &quot;consensus&quot;<br>
on this particular forum doesn&#39;t mean squat. :)<br>
<div><br>
&gt; and in bigger numbers. Talking about it helps draw those numbers in. B=
ut if<br>
&gt; they instead advocate &quot;meh, use goto and get over it, there&#39;s=
 better things<br>
&gt; to talk about&quot; instead, it&#39;ll explain why it&#39;s taken 30 y=
ears to appear so<br>
<br>
</div>Having rejected the previous proposal quite recently, the committee&#=
39;s<br>
first question<br>
to a revised proposal would be &quot;what&#39;s different this time?&quot; =
So, if<br>
people care about<br>
this proposed facility, they need to present strong motivation for it.<br>
This forum<br>
is not any official litmus test, but one might doubt the chance of<br>
convincing the<br>
committee if even people on this forum aren&#39;t convinced. Furthermore, t=
he<br>
previous proposal didn&#39;t pass through Evolution Working Group. After pa=
ssing<br>
EWG, a proposal would still need to pass through Core, and a full committee=
<br>
vote, to get adopted. So any further proposal for these facilities<br>
should be much<br>
more convincing than the previous one, and I have trouble imagining what<br=
>
changes would make it that much more convincing.<br></blockquote><div><br><=
/div><div>I&#39;d agree, but=C2=A0that appears to present=C2=A0a pretty imp=
ossible challenge then if it&#39;s true.</div><div><br></div><div>Because o=
n the one hand, you&#39;re saying they&#39;ve rejected=C2=A0this proposal a=
lready=C2=A0and they&#39;ll likely=C2=A0rejected it again if there isn&#39;=
t something new on the table.</div>
<div><br></div><div>But on the other hand you seem to be=C2=A0saying=C2=A0i=
f we=C2=A0discuss this more to see=C2=A0try to get=C2=A0that something new =
like I&#39;ve been trying,=C2=A0then=C2=A0that might just cause more dissen=
t and=C2=A0they&#39;ll reject it on that basis too as David=C2=A0is fearful=
 of.</div>
<div><br></div><div>So it would appear the proposal is damned either way an=
d already was, because=C2=A0my lone dissent will not have dissuaded anyone.=
</div><div><br></div><div>But there is &quot;a lot&quot; of consensus on he=
re For the proposal, at least=C2=A0in the people who have messaged here. it=
=C2=A0appeared to me I am the only=C2=A0dissenting voice here and I&#39;m=
=C2=A0weekly against at worst, to weekly for a best,=C2=A0but everyone else=
 who has contributed seems=C2=A0mainly pro the proposal, I just couldn&#39;=
t get a feel for if that is a vocal minority or not.</div>
<div><br></div><div>Do you really think it&#39;s that bleak in that context=
?</div><div><br></div><div>The=C2=A0&quot;for&quot; camp seem to be in this=
 no win position damned either way: can&#39;t discuss to get new ideas, can=
&#39;t risk dissent to make things worse. Can you suggest a=C2=A0path=C2=A0=
forward beyond just giving up on the proposal that doesn&#39;t fall victim =
to either of these two paths=C2=A0which you=C2=A0have just=C2=A0warned both=
 will likely result in failure?</div>
<div><br></div><div>Or maybe I&#39;m missing something here.</div><div><br>=
</div><div>Thanks</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204=
,204,204);border-left-width:1px;border-left-style:solid">

<div><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/QFo3J1rQIZo/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/QFo3J1rQIZo=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

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

--001a11c1308e3a0b5f0500bea832--

.

On 08/16/2014 02:55 PM, G M wrote:
> But there is "a lot" of consensus on here For the proposal, at least in t=
he people who have messaged here.

What's the ratio of writers vs. readers? 1:100?
So, some people said something, but a lot of people sat back and watched.

> The "for" camp seem to be in this no win position damned either way: can'=
t discuss to get new ideas, can't risk dissent to make things worse. Can yo=
u suggest a path forward beyond just giving up on the proposal that doesn't=
 fall victim to either of these two paths which you have just warned both w=
ill likely result in failure?

You're welcome to discuss as much as you like, and dissent in this forum mi=
ght not
become non-consensus at the WG21 level.

As unfortunate as it may appear here, WG21 is the deciding entity on the
technical level.  Anyone is welcome to join WG21 as an expert delegated
from your national standardization organization, and/or present your propos=
al
in paper form at the next meeting.
http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3828.pdf

As a committee member, my question is: Where is the paper that describes th=
e
syntax and semantics of the proposed facility, preferably with wording chan=
ges
relative to the current C++ working draft?  I'd like to see the complete
package, and not attempt to amalgamate a vague set of ideas from multiple
e-mails.

Jens

--=20

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

.

------=_Part_1854_1022617384.1408228057358
Content-Type: text/plain; charset=UTF-8

Hi

On Sunday, August 17, 2014 3:53:38 AM UTC+12, Jens Maurer wrote:
>
> On 08/16/2014 02:55 PM, G M wrote:
> > But there is "a lot" of consensus on here For the proposal, at least in
> the people who have messaged here.
>
> What's the ratio of writers vs. readers? 1:100?
> So, some people said something, but a lot of people sat back and watched.
>

That was what I was trying to suggest. But when I'm the only public
dissenter as weakly against with a estimated potential of being weakly
for, I have to credit the other support because it is all public and for so
I was trying to give that credit. But I agree with your view FWIW.


> > The "for" camp seem to be in this no win position damned either way:
> can't discuss to get new ideas, can't risk dissent to make things worse.
> Can you suggest a path forward beyond just giving up on the proposal that
> doesn't fall victim to either of these two paths which you have just warned
> both will likely result in failure?
>
> You're welcome to discuss as much as you like, and dissent in this forum
> might not
> become non-consensus at the WG21 level.
>

The other comments from people and your use of might, show it's anyone's
guess. But what else can you say. So I agree.

I have to believe that even if a heated discussion took place, if a
compelling idea came forward, on this subject at least, it would be easily
seen and stand above the din as the subject isn't complex. For more complex
issues I might see David's view but history is probably littered with
examples that make his case too. I just think we can't have such fears
getting too overblown that we adopt a style that stops people
participating. It seems you favour that more relaxed view in this case
while acknowledging anything might happen.


> As unfortunate as it may appear here, WG21 is the deciding entity on the
> technical level.  Anyone is welcome to join WG21 as an expert delegated
> from your national standardization organization, and/or present your
> proposal
> in paper form at the next meeting.
> http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3828.pdf
>
> As a committee member, my question is: Where is the paper that describes
> the
> syntax and semantics of the proposed facility, preferably with wording
> changes
> relative to the current C++ working draft?  I'd like to see the complete
> package, and not attempt to amalgamate a vague set of ideas from multiple
> e-mails.
>

Offering such ideas by email is all I have to offer here but I hope
occasionally something useful might help a proposal from such
participation. I certainly appreciate the effort of those that go beyond
that like David and Andrew in this case. That's a factor that draws people
in and to this forum in particular. On this proposal I think Andrew's
contribution of stat's etc. are all helpful developments for
assessing value etc. hopefully they can build on that.


> Jens
>

Thanks, I found a lot to agree with in that. It seems realistic.

--

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

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

<div dir=3D"ltr">Hi<br><br>On Sunday, August 17, 2014 3:53:38 AM UTC+12, Je=
ns Maurer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;">On 08/16/2014 02:55 PM, G M wr=
ote:
<br>&gt; But there is "a lot" of consensus on here For the proposal, at lea=
st in the people who have messaged here.
<br>
<br>What's the ratio of writers vs. readers? 1:100?
<br>So, some people said something, but a lot of people sat back and watche=
d.
<br></blockquote><div><br></div><div>That&nbsp;was what I was trying to sug=
gest. But&nbsp;when&nbsp;I'm the only&nbsp;public dissenter as weakly again=
st&nbsp;with a estimated potential&nbsp;of being weakly for,&nbsp;I have to=
 credit the other support&nbsp;because it is all public&nbsp;and&nbsp;for&n=
bsp;so I was trying to give that credit. But I agree with your view FWIW.</=
div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0=
px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bor=
der-left-width: 1px; border-left-style: solid;">
<br>&gt; The "for" camp seem to be in this no win position damned either wa=
y: can't discuss to get new ideas, can't risk dissent to make things worse.=
 Can you suggest a path forward beyond just giving up on the proposal that =
doesn't fall victim to either of these two paths which you have just warned=
 both will likely result in failure?
<br>
<br>You're welcome to discuss as much as you like, and dissent in this foru=
m might not
<br>become non-consensus at the WG21 level.
<br></blockquote><div><br></div><div>The other comments from people and you=
r&nbsp;use of might, show it's anyone's guess. But what else can you say. S=
o I agree.</div><div><br></div><div>I have to believe that even if a heated=
 discussion took place, if&nbsp;a compelling idea came forward,&nbsp;on thi=
s subject at least,&nbsp;it would&nbsp;be easily seen&nbsp;and stand above =
the din as the subject isn't complex. For more complex issues I might see D=
avid's view but history is probably littered with examples that make his ca=
se too. I just think we can't have such fears getting too overblown that we=
 adopt a style that stops people participating. It seems you favour that mo=
re relaxed view in this case while acknowledging anything might happen.</di=
v><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;">
<br>As unfortunate as it may appear here, WG21 is the deciding entity on th=
e
<br>technical level. &nbsp;Anyone is welcome to join WG21 as an expert dele=
gated
<br>from your national standardization organization, and/or present your pr=
oposal
<br>in paper form at the next meeting.
<br><a onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F=
%2Fopen-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn3828.pdf\46s=
a\75D\46sntz\0751\46usg\75AFQjCNFpRM0ibjvlihbTCR57cqx8lXlgHA';return true;"=
 onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fopen-st=
d.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn3828.pdf\46sa\75D\46sn=
tz\0751\46usg\75AFQjCNFpRM0ibjvlihbTCR57cqx8lXlgHA';return true;" href=3D"h=
ttp://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3828.pdf" target=3D"_bl=
ank">http://open-std.org/jtc1/sc22/<wbr>wg21/docs/papers/2014/n3828.<wbr>pd=
f</a>
<br>
<br>As a committee member, my question is: Where is the paper that describe=
s the
<br>syntax and semantics of the proposed facility, preferably with wording =
changes
<br>relative to the current C++ working draft? &nbsp;I'd like to see the co=
mplete
<br>package, and not attempt to amalgamate a vague set of ideas from multip=
le
<br>e-mails.
<br></blockquote><div><br></div><div>Offering such ideas by email is&nbsp;a=
ll I&nbsp;have to offer here but I hope occasionally something useful might=
&nbsp;help a&nbsp;proposal from such participation. I certainly appreciate =
the effort of those that go beyond that like David and Andrew in this case.=
 That's a factor that draws people in and to this forum in particular.&nbsp=
;On this proposal I&nbsp;think Andrew's contribution of stat's etc.&nbsp;ar=
e all&nbsp;helpful developments&nbsp;for assessing&nbsp;value etc. hopefull=
y they can&nbsp;build on that.</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-lef=
t-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: sol=
id;">
<br>Jens
<br></blockquote><div><br></div><div>Thanks, I found a lot to agree with in=
 that.&nbsp;It seems realistic.</div></div>

<p></p>

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

------=_Part_1854_1022617384.1408228057358--

.

------=_Part_319_2064277543.1408260602060
Content-Type: text/plain; charset=UTF-8

On Saturday, August 16, 2014 4:30:46 AM UTC-7, Ville Voutilainen wrote:
>
> Having rejected the previous proposal quite recently, the committee's
> first question
> to a revised proposal would be "what's different this time?" So, if
> people care about
> this proposed facility, they need to present strong motivation for it.
>

To me, what's new this time is that constexpr functions can now use break
and continue, but not goto.  This makes "just use goto" less valid of an
counterargument.


On Friday, August 15, 2014 6:56:48 PM UTC-7, David Krauss wrote:
>
> The division of the committee vote was most likely not over the minutiae
> of scoping and syntax, but whether such nested loop structures should be
> encouraged or beautified. Personally, I do tend to avoid nested loops,
> because they tend to indicate polynomial complexity.
>

I primarily would love this feature just to be able to break out of a loop
from within a switch!


On Saturday, August 16, 2014 8:53:38 AM UTC-7, Jens Maurer wrote:

> As a committee member, my question is: Where is the paper that describes
> the
> syntax and semantics of the proposed facility, preferably with wording
> changes
> relative to the current C++ working draft?  I'd like to see the complete
> package, and not attempt to amalgamate a vague set of ideas from multiple
> e-mails.
>

I personally believe that the reason that this has not yet happened is that
it is viewed as a trivial matter.  The previously-rejected proposal was a
strict superset of this one: take a pair of scissors to it and you get this
proposal.  Not knowing of the previously-rejected proposal, I also wrote a
diff to the Standard for this proposal at the beginning of the first thread
(this is actually the second thread); however, since I'm a layman
(laywoman?) in the sense of being new to this list I doubt that mine would
pass muster at the required quality level.

I could dig these up easily if you'd like.


Melissa

--

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

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

<div dir=3D"ltr">On Saturday, August 16, 2014 4:30:46 AM UTC-7, Ville Vouti=
lainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Having rejected t=
he previous proposal quite recently, the committee's
<br>first question
<br>to a revised proposal would be "what's different this time?" So, if
<br>people care about
<br>this proposed facility, they need to present strong motivation for it.
<br></blockquote><br>To me, what's new this time is that <span style=3D"fon=
t-family: courier new,monospace;">constexpr</span> functions can now use <s=
pan style=3D"font-family: courier new,monospace;">break</span> and <span st=
yle=3D"font-family: courier new,monospace;">continue</span>, but not <span =
style=3D"font-family: courier new,monospace;">goto</span>.&nbsp; This makes=
 "just use <span style=3D"font-family: courier new,monospace;">goto</span>"=
 less valid of an counterargument.<br><br><br>On Friday, August 15, 2014 6:=
56:48 PM UTC-7, David Krauss wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div style=3D"word-wrap:break-word">The
 division of the committee vote was most likely not over the minutiae of
 scoping and syntax, but whether such nested loop structures should be=20
encouraged or beautified. Personally, I do tend to avoid nested loops,=20
because they tend to indicate polynomial complexity. <br></div></blockquote=
><br>I primarily would love this feature just to be able to <span style=3D"=
font-family: courier new,monospace;">break</span> out of a loop from within=
 a <span style=3D"font-family: courier new,monospace;">switch</span>!<br><b=
r><br>On Saturday, August 16, 2014 8:53:38 AM UTC-7, Jens Maurer wrote: <br=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">As a committee member, my que=
stion is: Where is the paper that describes the
<br>syntax and semantics of the proposed facility, preferably with wording =
changes
<br>relative to the current C++ working draft? &nbsp;I'd like to see the co=
mplete
<br>package, and not attempt to amalgamate a vague set of ideas from multip=
le
<br>e-mails.
<br></blockquote><div><br>I personally believe that the reason that this ha=
s not yet happened is that it is viewed as a trivial matter.&nbsp; The prev=
iously-rejected proposal was a strict superset of this one: take a pair of =
scissors to it and you get this proposal.&nbsp; Not knowing of the previous=
ly-rejected proposal, I also wrote a diff to the Standard for this proposal=
 at the beginning of the first thread (this is actually the second thread);=
 however, since I'm a layman (laywoman?) in the sense of being new to this =
list I doubt that mine would pass muster at the required quality level.<br>=
<br>I could dig these up easily if you'd like.<br><br><br>Melissa<br></div>=
</div>

<p></p>

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

------=_Part_319_2064277543.1408260602060--

.

On 17 August 2014 10:30, Myriachan <myriachan@gmail.com> wrote:
> On Saturday, August 16, 2014 4:30:46 AM UTC-7, Ville Voutilainen wrote:
>>
>> Having rejected the previous proposal quite recently, the committee's
>> first question
>> to a revised proposal would be "what's different this time?" So, if
>> people care about
>> this proposed facility, they need to present strong motivation for it.
>
>
> To me, what's new this time is that constexpr functions can now use break
> and continue, but not goto.  This makes "just use goto" less valid of an
> counterargument.

Well, yeah - but "just use goto" is not the only counterargument. The stronger
counterargument is to split such nested loops into functions, and that solution
works even with constexpr. Yes, I know, many people claim that that is not
a palatable solution. For what it's worth, my stubborn head says it's THE
solution and the claims that nested loops are necessary do not convince
_me_. :)

Having said that, I have for a while thought that your point about
goto in constexpr
functions is something that would be reasonable to discuss. ;)

> I personally believe that the reason that this has not yet happened is that
> it is viewed as a trivial matter.  The previously-rejected proposal was a

Personally, I remain unconvinced that the problem is severe enough to introduce
a core language facility to tackle it. I have never suffered from this problem
within a timespan two decades. For the cases where I thought that a
labeled-break
was a suitable solution for a problem in java code (which I have also
written a fair
amount), I always ended up with a different solution. Yes, anecdotal as it may
be, but I have _no_ evidence that labeled breaks improve anything.

--

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

.

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

On Sun, Aug 17, 2014 at 10:40 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 17 August 2014 10:30, Myriachan <myriachan@gmail.com> wrote:
> > On Saturday, August 16, 2014 4:30:46 AM UTC-7, Ville Voutilainen wrote:
> >>
> >> Having rejected the previous proposal quite recently, the committee's
> >> first question
> >> to a revised proposal would be "what's different this time?" So, if
> >> people care about
> >> this proposed facility, they need to present strong motivation for it.
> >
> >
> > To me, what's new this time is that constexpr functions can now use break
> > and continue, but not goto.  This makes "just use goto" less valid of an
> > counterargument.
>
> Well, yeah - but "just use goto" is not the only counterargument. The
> stronger
> counterargument is to split such nested loops into functions, and that
> solution
> works even with constexpr. Yes, I know, many people claim that that is not
> a palatable solution. For what it's worth, my stubborn head says it's THE
> solution and the claims that nested loops are necessary do not convince
> _me_. :)
>
> Having said that, I have for a while thought that your point about
> goto in constexpr
> functions is something that would be reasonable to discuss. ;)
>
> > I personally believe that the reason that this has not yet happened is
> that
> > it is viewed as a trivial matter.  The previously-rejected proposal was a
>
> Personally, I remain unconvinced that the problem is severe enough to
> introduce
> a core language facility to tackle it. I have never suffered from this
> problem
> within a timespan two decades. For the cases where I thought that a
> labeled-break
> was a suitable solution for a problem in java code (which I have also
> written a fair
> amount), I always ended up with a different solution. Yes, anecdotal as it
> may
> be, but I have _no_ evidence that labeled breaks improve anything.
>

People that already liked the proposal, look at the new data, and say "see,
I told you so."

People that already disliked the proposal, look at the new data, and say
"see, I told you so."

I see now what the professor meant when he said "there is no accounting for
taste".

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Aug 17, 2014 at 10:40 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 17 August 2014 10:30, Myr=
iachan &lt;<a href=3D"mailto:myriachan@gmail.com">myriachan@gmail.com</a>&g=
t; wrote:<br>

&gt; On Saturday, August 16, 2014 4:30:46 AM UTC-7, Ville Voutilainen wrote=
:<br>
&gt;&gt;<br>
&gt;&gt; Having rejected the previous proposal quite recently, the committe=
e&#39;s<br>
&gt;&gt; first question<br>
&gt;&gt; to a revised proposal would be &quot;what&#39;s different this tim=
e?&quot; So, if<br>
&gt;&gt; people care about<br>
&gt;&gt; this proposed facility, they need to present strong motivation for=
 it.<br>
&gt;<br>
&gt;<br>
&gt; To me, what&#39;s new this time is that constexpr functions can now us=
e break<br>
&gt; and continue, but not goto.=C2=A0 This makes &quot;just use goto&quot;=
 less valid of an<br>
&gt; counterargument.<br>
<br>
</div>Well, yeah - but &quot;just use goto&quot; is not the only counterarg=
ument. The stronger<br>
counterargument is to split such nested loops into functions, and that solu=
tion<br>
works even with constexpr. Yes, I know, many people claim that that is not<=
br>
a palatable solution. For what it&#39;s worth, my stubborn head says it&#39=
;s THE<br>
solution and the claims that nested loops are necessary do not convince<br>
_me_. :)<br>
<br>
Having said that, I have for a while thought that your point about<br>
goto in constexpr<br>
functions is something that would be reasonable to discuss. ;)<br>
<div class=3D""><br>
&gt; I personally believe that the reason that this has not yet happened is=
 that<br>
&gt; it is viewed as a trivial matter.=C2=A0 The previously-rejected propos=
al was a<br>
<br>
</div>Personally, I remain unconvinced that the problem is severe enough to=
 introduce<br>
a core language facility to tackle it. I have never suffered from this prob=
lem<br>
within a timespan two decades. For the cases where I thought that a<br>
labeled-break<br>
was a suitable solution for a problem in java code (which I have also<br>
written a fair<br>
amount), I always ended up with a different solution. Yes, anecdotal as it =
may<br>
be, but I have _no_ evidence that labeled breaks improve anything.<br>
<div class=3D"HOEnZb"><div class=3D"h5"></div></div></blockquote></div><br>=
</div><div class=3D"gmail_extra">People that already liked the proposal, lo=
ok at the new data, and say &quot;see, I told you so.&quot;</div><div class=
=3D"gmail_extra">
<br></div><div class=3D"gmail_extra">People that already disliked the propo=
sal, look at the new data, and say &quot;see, I told you so.&quot;</div><di=
v class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I see now what=
 the professor meant when he said &quot;there is no accounting for taste&qu=
ot;.</div>
<div class=3D"gmail_extra"><br></div></div>

<p></p>

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

--047d7b1118fd185be70500cf7bc5--

.

------=_Part_346_1530665662.1408269559444
Content-Type: text/plain; charset=UTF-8



On Sunday, August 17, 2014 1:40:07 AM UTC-7, Ville Voutilainen wrote:
>
> On 17 August 2014 10:30, Myriachan <myri...@gmail.com <javascript:>>
> wrote:
> > On Saturday, August 16, 2014 4:30:46 AM UTC-7, Ville Voutilainen wrote:
> >>
> >> Having rejected the previous proposal quite recently, the committee's
> >> first question
> >> to a revised proposal would be "what's different this time?" So, if
> >> people care about
> >> this proposed facility, they need to present strong motivation for it.
> >
> >
> > To me, what's new this time is that constexpr functions can now use
> break
> > and continue, but not goto.  This makes "just use goto" less valid of an
> > counterargument.
>
> Well, yeah - but "just use goto" is not the only counterargument. The
> stronger
> counterargument is to split such nested loops into functions, and that
> solution
> works even with constexpr. Yes, I know, many people claim that that is not
> a palatable solution. For what it's worth, my stubborn head says it's THE
> solution and the claims that nested loops are necessary do not convince
> _me_. :)
>

Without exceptions to work with, conditionally returning 2 levels deep in
some cases but 3 levels deep in others can be annoying in constexpr
functions.  Of course, why I'd be writing a 3-level-deep loop as constexpr,
I don't know, since I'd probably be on crack.

The most useful part of labeled breaks to me is actually the ability to
break out from a loop within a switch without needing goto, a temporary
variable, or having to modify the loop iterator.  That can be useful, for
example, in parsing a string at compile time.


> Having said that, I have for a while thought that your point about
> goto in constexpr
> functions is something that would be reasonable to discuss. ;)
>

=)


> > I personally believe that the reason that this has not yet happened is
> that
> > it is viewed as a trivial matter.  The previously-rejected proposal was
> a
>
> Personally, I remain unconvinced that the problem is severe enough to
> introduce
> a core language facility to tackle it.


The text you quoted here was me specifically referring to the text I quoted
above it; that is, it was about why there hadn't been a formal
specification of the proposal yet.  I wasn't making a statement about how
long C/C++ has gone without this feature.


> Yes, anecdotal as it may
> be, but I have _no_ evidence that labeled breaks improve anything.
>

Wouldn't getting rid of some gotos in favor of something less risky be
valuable? =)  To me, the question is more about whether this would be
valuable *enough* to justify the new feature.

Melissa

--

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

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

<div dir=3D"ltr"><br><br>On Sunday, August 17, 2014 1:40:07 AM UTC-7, Ville=
 Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 17 Augus=
t 2014 10:30, Myriachan &lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"RDApSCnpL_kJ" onmousedown=3D"this.href=3D'javascript:';=
return true;" onclick=3D"this.href=3D'javascript:';return true;">myri...@gm=
ail.com</a>&gt; wrote:
<br>&gt; On Saturday, August 16, 2014 4:30:46 AM UTC-7, Ville Voutilainen w=
rote:
<br>&gt;&gt;
<br>&gt;&gt; Having rejected the previous proposal quite recently, the comm=
ittee's
<br>&gt;&gt; first question
<br>&gt;&gt; to a revised proposal would be "what's different this time?" S=
o, if
<br>&gt;&gt; people care about
<br>&gt;&gt; this proposed facility, they need to present strong motivation=
 for it.
<br>&gt;
<br>&gt;
<br>&gt; To me, what's new this time is that constexpr functions can now us=
e break
<br>&gt; and continue, but not goto. &nbsp;This makes "just use goto" less =
valid of an
<br>&gt; counterargument.
<br>
<br>Well, yeah - but "just use goto" is not the only counterargument. The s=
tronger
<br>counterargument is to split such nested loops into functions, and that =
solution
<br>works even with constexpr. Yes, I know, many people claim that that is =
not
<br>a palatable solution. For what it's worth, my stubborn head says it's T=
HE
<br>solution and the claims that nested loops are necessary do not convince
<br>_me_. :)
<br></blockquote><div><br>Without exceptions to work with, conditionally re=
turning 2 levels deep in some cases but 3 levels deep in others can be anno=
ying in <span style=3D"font-family: courier new,monospace;">constexpr</span=
> functions.&nbsp; Of course, why I'd be writing a 3-level-deep loop as <sp=
an style=3D"font-family: courier new,monospace;">constexpr</span>, I don't =
know, since I'd probably be on crack.<br><br>The most useful part of labele=
d <span style=3D"font-family: courier new,monospace;">break</span>s to me i=
s actually the ability to break out from a loop within a <span style=3D"fon=
t-family: courier new,monospace;">switch</span> without needing <span style=
=3D"font-family: courier new,monospace;">goto</span>, a temporary variable,=
 or having to modify the loop iterator.&nbsp; That can be useful, for examp=
le, in parsing a string at compile time.<br>&nbsp;</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">Having said that, I have for a while thought th=
at your point about
<br>goto in constexpr
<br>functions is something that would be reasonable to discuss. ;)
<br></blockquote><div><br>=3D)<br>&nbsp;</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">&gt; I personally believe that the reason that this has not=
 yet happened is that
<br>&gt; it is viewed as a trivial matter. &nbsp;The previously-rejected pr=
oposal was a
<br>
<br>Personally, I remain unconvinced that the problem is severe enough to i=
ntroduce
<br>a core language facility to tackle it. </blockquote><div><br>The text y=
ou quoted here was me specifically referring to the text I quoted above it;=
 that is, it was about why there hadn't been a formal specification of the =
proposal yet.&nbsp; I wasn't making a statement about how long C/C++ has go=
ne without this feature.<br></div><div>&nbsp;<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">Yes, anecdotal as it may
<br>be, but I have _no_ evidence that labeled breaks improve anything.<br><=
/blockquote><div><br>Wouldn't getting rid of some <span style=3D"font-famil=
y: courier new,monospace;">goto</span>s in favor of something less risky be=
 valuable? =3D)&nbsp; To me, the question is more about whether this would =
be valuable <i>enough</i> to justify the new feature.<br><br>Melissa<br></d=
iv></div>

<p></p>

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

------=_Part_346_1530665662.1408269559444--

.

------=_Part_1179_1032818057.1408273909446
Content-Type: text/plain; charset=UTF-8

Regarding goto in constexpr functions, why don't just allow it?
It seems like there are no technical reasons to prohibit it (for, break and
continue are already implemented), the only reason is that goto is
generally bad.
The paper on relaxing constexpr
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3597.html> says

> Some of the remaining restrictions on constexpr functions and constant
> expression evaluation could be relaxed, if the value of the language
> feature within a constant expression is thought to be sufficient to justify
> the implementation cost

Isn't the case of Myriachan compelling enough to lift this particular
restriction?

On Sunday, August 17, 2014 11:30:02 AM UTC+4, Myriachan wrote:
>
> On Saturday, August 16, 2014 4:30:46 AM UTC-7, Ville Voutilainen wrote:
>>
>> Having rejected the previous proposal quite recently, the committee's
>> first question
>> to a revised proposal would be "what's different this time?" So, if
>> people care about
>> this proposed facility, they need to present strong motivation for it.
>>
>
> To me, what's new this time is that constexpr functions can now use break
> and continue, but not goto.  This makes "just use goto" less valid of an
> counterargument.
>
>
> On Friday, August 15, 2014 6:56:48 PM UTC-7, David Krauss wrote:
>>
>> The division of the committee vote was most likely not over the minutiae
>> of scoping and syntax, but whether such nested loop structures should be
>> encouraged or beautified. Personally, I do tend to avoid nested loops,
>> because they tend to indicate polynomial complexity.
>>
>
> I primarily would love this feature just to be able to break out of a
> loop from within a switch!
>
>
> On Saturday, August 16, 2014 8:53:38 AM UTC-7, Jens Maurer wrote:
>
>> As a committee member, my question is: Where is the paper that describes
>> the
>> syntax and semantics of the proposed facility, preferably with wording
>> changes
>> relative to the current C++ working draft?  I'd like to see the complete
>> package, and not attempt to amalgamate a vague set of ideas from multiple
>> e-mails.
>>
>
> I personally believe that the reason that this has not yet happened is
> that it is viewed as a trivial matter.  The previously-rejected proposal
> was a strict superset of this one: take a pair of scissors to it and you
> get this proposal.  Not knowing of the previously-rejected proposal, I also
> wrote a diff to the Standard for this proposal at the beginning of the
> first thread (this is actually the second thread); however, since I'm a
> layman (laywoman?) in the sense of being new to this list I doubt that mine
> would pass muster at the required quality level.
>
> I could dig these up easily if you'd like.
>
>
> Melissa
>

--

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

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

<div dir=3D"ltr">Regarding goto&nbsp;in constexpr functions, why don't just=
 allow it?<br><div>It seems like there are no technical reasons to prohibit=
 it (for, break and continue are already implemented), the only reason is t=
hat goto is generally bad.</div><div><a href=3D"http://www.open-std.org/jtc=
1/sc22/wg21/docs/papers/2013/n3597.html">The paper on relaxing constexpr</a=
> says</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Some of the remain=
ing restrictions on constexpr functions and constant expression evaluation =
could be relaxed, if the value of the language feature within a constant ex=
pression is thought to be sufficient to justify the implementation cost</bl=
ockquote><div>Isn't the case of Myriachan compelling enough to lift this pa=
rticular restriction?</div><div><br></div>On Sunday, August 17, 2014 11:30:=
02 AM UTC+4, Myriachan wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">On Saturday, August 16, 2014 4:30:46 AM UTC-7, Ville Voutil=
ainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Having rejected the pre=
vious proposal quite recently, the committee's
<br>first question
<br>to a revised proposal would be "what's different this time?" So, if
<br>people care about
<br>this proposed facility, they need to present strong motivation for it.
<br></blockquote><br>To me, what's new this time is that <span style=3D"fon=
t-family:courier new,monospace">constexpr</span> functions can now use <spa=
n style=3D"font-family:courier new,monospace">break</span> and <span style=
=3D"font-family:courier new,monospace">continue</span>, but not <span style=
=3D"font-family:courier new,monospace">goto</span>.&nbsp; This makes "just =
use <span style=3D"font-family:courier new,monospace">goto</span>" less val=
id of an counterargument.<br><br><br>On Friday, August 15, 2014 6:56:48 PM =
UTC-7, David Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div styl=
e=3D"word-wrap:break-word">The
 division of the committee vote was most likely not over the minutiae of
 scoping and syntax, but whether such nested loop structures should be=20
encouraged or beautified. Personally, I do tend to avoid nested loops,=20
because they tend to indicate polynomial complexity. <br></div></blockquote=
><br>I primarily would love this feature just to be able to <span style=3D"=
font-family:courier new,monospace">break</span> out of a loop from within a=
 <span style=3D"font-family:courier new,monospace">switch</span>!<br><br><b=
r>On Saturday, August 16, 2014 8:53:38 AM UTC-7, Jens Maurer wrote: <br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">As a committee member, my question is:=
 Where is the paper that describes the
<br>syntax and semantics of the proposed facility, preferably with wording =
changes
<br>relative to the current C++ working draft? &nbsp;I'd like to see the co=
mplete
<br>package, and not attempt to amalgamate a vague set of ideas from multip=
le
<br>e-mails.
<br></blockquote><div><br>I personally believe that the reason that this ha=
s not yet happened is that it is viewed as a trivial matter.&nbsp; The prev=
iously-rejected proposal was a strict superset of this one: take a pair of =
scissors to it and you get this proposal.&nbsp; Not knowing of the previous=
ly-rejected proposal, I also wrote a diff to the Standard for this proposal=
 at the beginning of the first thread (this is actually the second thread);=
 however, since I'm a layman (laywoman?) in the sense of being new to this =
list I doubt that mine would pass muster at the required quality level.<br>=
<br>I could dig these up easily if you'd like.<br><br><br>Melissa<br></div>=
</div></blockquote></div>

<p></p>

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

------=_Part_1179_1032818057.1408273909446--

.

On 17 August 2014 12:59, Myriachan <myriachan@gmail.com> wrote:
>> Yes, anecdotal as it may
>> be, but I have _no_ evidence that labeled breaks improve anything.
> Wouldn't getting rid of some gotos in favor of something less risky be
> valuable? =)  To me, the question is more about whether this would be
> valuable enough to justify the new feature.


Would it? I don't think that's a simple question, and I don't have a
simple answer. :)
I frankly do not see what causes this desire to get rid of gotos, it seems to be
aiming for getting rid of gotos for irrational reasons.

--

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

.

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

On Sun, Aug 17, 2014 at 2:04 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 17 August 2014 12:59, Myriachan <myriachan@gmail.com> wrote:
> >> Yes, anecdotal as it may
> >> be, but I have _no_ evidence that labeled breaks improve anything.
> > Wouldn't getting rid of some gotos in favor of something less risky be
> > valuable? =)  To me, the question is more about whether this would be
> > valuable enough to justify the new feature.
>
>
> Would it? I don't think that's a simple question, and I don't have a
> simple answer. :)
> I frankly do not see what causes this desire to get rid of gotos, it seems
> to be
> aiming for getting rid of gotos for irrational reasons.
>

A goto statement can create an arbitrary edge in the static control flow
graph.  As a consequence, liberal use can create spaghetti code that is
hard to read and debug.  That is why most programmers are taught not to use
it.  It is also why most coding guidelines discourage or prohibit its use.
 It is also why most programmers dont use it to terminate an enclosing
nested loop or switch, and use flags or other refactorings instead.
 Despite rumors to the contrary, most programmers don't factor out nested
loops into single use functions to use the return statement, which can
terminate nested loops.  We can tell these facts by studying the large
amount of existing code available.

A break statement (both the current one and the proposed one) can only
terminate an enclosing statement.  This is a very specific and easy to
follow edge in the static control flow graph.  It is easier to read and
debug than using flags.  It is easier to follow than a factored-out single
use function.  It is even easier to follow than a single-use lambda too.
 It's the reason that the statement is allowed in Java, but goto isn't.

The majority of those against the proposal are not prepared to entertain or
be drawn into a nuanced argument about the specifics.  They are applying a
general policy against extending any statements that can effect control
flow, on the grounds that you shouldn't need them, because you shouldn't be
writing complicated control structures to begin with.  They don't care that
people do find themselves wanting to terminate nested loops or switches,
they only care about people that are writing the kind of idealized "good
code", that only exists in their imaginations, and we can find no evidence
of in reality.

Reminds me of the old saying: "In theory there is no difference between
theory and practice.  In practice, there is."

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
un, Aug 17, 2014 at 2:04 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 17 August 2014 12:59, Myr=
iachan &lt;<a href=3D"mailto:myriachan@gmail.com">myriachan@gmail.com</a>&g=
t; wrote:<br>

&gt;&gt; Yes, anecdotal as it may<br>
&gt;&gt; be, but I have _no_ evidence that labeled breaks improve anything.=
<br>
&gt; Wouldn&#39;t getting rid of some gotos in favor of something less risk=
y be<br>
&gt; valuable? =3D)=C2=A0 To me, the question is more about whether this wo=
uld be<br>
&gt; valuable enough to justify the new feature.<br>
<br>
<br>
</div>Would it? I don&#39;t think that&#39;s a simple question, and I don&#=
39;t have a<br>
simple answer. :)<br>
I frankly do not see what causes this desire to get rid of gotos, it seems =
to be<br>
aiming for getting rid of gotos for irrational reasons.<br>
<div class=3D"HOEnZb"><div class=3D"h5"></div></div></blockquote></div><br>=
</div><div class=3D"gmail_extra">A goto statement can create an arbitrary e=
dge in the static control flow graph. =C2=A0As a consequence, liberal use c=
an create spaghetti code that is hard to read and debug. =C2=A0That is why =
most programmers are taught not to use it. =C2=A0It is also why most coding=
 guidelines discourage or prohibit its use. =C2=A0It is also why most progr=
ammers dont use it to terminate an enclosing nested loop or switch, and use=
 flags or other refactorings instead. =C2=A0Despite rumors to the contrary,=
 most programmers don&#39;t factor out nested loops into single use functio=
ns to use the return statement, which can terminate nested loops. =C2=A0We =
can tell these facts by studying the large amount of existing code availabl=
e.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">A break sta=
tement (both the current one and the proposed one) can only terminate an en=
closing statement. =C2=A0This is a very specific and easy to follow edge in=
 the static control flow graph. =C2=A0It is easier to read and debug than u=
sing flags. =C2=A0It is easier to follow than a factored-out single use fun=
ction. =C2=A0It is even easier to follow than a single-use lambda too. =C2=
=A0It&#39;s the reason that the statement is allowed in Java, but goto isn&=
#39;t.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The majorit=
y of those against the proposal are not prepared to entertain or be drawn i=
nto a nuanced argument about the specifics. =C2=A0They are applying a gener=
al policy against extending any statements that can effect control flow, on=
 the grounds that you shouldn&#39;t need them, because you shouldn&#39;t be=
 writing complicated control structures to begin with. =C2=A0They don&#39;t=
 care that people do find themselves wanting to terminate nested loops or s=
witches, they only care about people that are writing the kind of idealized=
 &quot;good code&quot;, that only exists in their imaginations, and we can =
find no evidence of in reality.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Reminds me =
of the old saying: &quot;In theory there is no difference between theory an=
d practice. =C2=A0In practice, there is.&quot;</div><div class=3D"gmail_ext=
ra"><br>
</div></div>

<p></p>

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

--047d7bd6c016a359130500db0524--

.

On 2014-08-16, at 11:53 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:

> As a committee member, my question is: Where is the paper that describes =
the
> syntax and semantics of the proposed facility, preferably with wording ch=
anges
> relative to the current C++ working draft?  I'd like to see the complete
> package, and not attempt to amalgamate a vague set of ideas from multiple
> e-mails.

Just to be clear, are you looking for something other than N3879 =A70.5.1 a=
nd =A70.5.2?


On 2014-08-17, at 4:40 PM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:

> Well, yeah - but "just use goto" is not the only counterargument. The str=
onger
> counterargument is to split such nested loops into functions, and that so=
lution
> works even with constexpr. Yes, I know, many people claim that that is no=
t
> a palatable solution. For what it's worth, my stubborn head says it's THE
> solution and the claims that nested loops are necessary do not convince
> _me_. :)


Is it helpful to keep others from having a feature that would improve the q=
uality of their code, because you would prefer their code to be improved a =
different way? If there's "no accounting for taste," would it not be better=
 to suspend your own when judging the common good?  I favor this proposal e=
ven if I can't dig up an example in my code bases. At least I've used non-e=
xiting "found it" flags in pure numeric code. Not all shipping software is =
polished.

Introducing functions is not always free. It means translating local variab=
les into parameters and requires the inliner to do its thing, without inter=
fering with any other optimizations. Also, being nested doesn't imply a loo=
p is large enough to warrant refactoring.

Anyway, factoring out a function doesn't replace goto at all; functions onl=
y have one return address. The function still has to set a flag or return a=
n end-iterator value. In practice, programmers often implement a flag but c=
ontinue iterating without early exit. This ground was already covered, I th=
ink in the initial thread "Java-style labeled break/continue, standalone."

--=20

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

.

--Apple-Mail=_1E1BF645-3B47-46E5-AD93-2C3D99808B19
Content-Type: text/plain; charset=ISO-8859-1


On 2014-08-18, at 8:47 AM, David Krauss <potswa@gmail.com> wrote:

> Anyway, factoring out a function doesn't replace goto at all; functions only have one return address. The function still has to set a flag or return an end-iterator value.

Ah, you meant to factor the outer loop into a single-use function rather than the inner loop into a reusable function. Single-use functions aren't always good style. I don't think that can be considered quite so universal.

--

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

--Apple-Mail=_1E1BF645-3B47-46E5-AD93-2C3D99808B19
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08&ndash;18, at 8:47 AM, David Krauss &lt;<a href=3D"mailto:potswa@gm=
ail.com">potswa@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchang=
e-newline"><blockquote type=3D"cite"><span style=3D"font-family: Helvetica;=
 font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; d=
isplay: inline !important;">Anyway, factoring out a function doesn&rsquo;t =
replace goto at all; functions only have one return address. The function s=
till has to set a flag or return an end-iterator value.</span></blockquote>=
<br></div><div>Ah, you meant to factor the outer loop into a single-use fun=
ction rather than the inner loop into a reusable function. Single-use funct=
ions aren&rsquo;t always good style. I don&rsquo;t think that can be consid=
ered quite so universal.</div><div><br></div></body></html>

<p></p>

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

--Apple-Mail=_1E1BF645-3B47-46E5-AD93-2C3D99808B19--

.

------=_Part_119_1845240474.1408323512406
Content-Type: text/plain; charset=UTF-8

On Sunday, August 17, 2014 5:04:26 AM UTC-7, Ville Voutilainen wrote:
>
> On 17 August 2014 12:59, Myriachan <myri...@gmail.com <javascript:>>
> wrote:
> > Wouldn't getting rid of some gotos in favor of something less risky be
> > valuable? =)  To me, the question is more about whether this would be
> > valuable enough to justify the new feature.
> Would it? I don't think that's a simple question, and I don't have a
> simple answer. :)
> I frankly do not see what causes this desire to get rid of gotos, it seems
> to be
> aiming for getting rid of gotos for irrational reasons.
>

I find them dangerous, but I don't want to get rid of gotos =)  They're
fine to leave in the language, but they're also weapons with no safeties on
them.  I'd prefer firearms aimed at our own feet to have safeties.  Thus
why I also think runtime-sized arrays and their companion std::dynarray are
long overdue: they can still be dangerous like our old friend alloca, but
unlike alloca, these weapons have safeties and a better scope attached
(figuratively *and* literally in this case).  Still, I wouldn't advocate
the removal of alloca, either.

I see labeled break and continue the same way: even though they are
strictly less powerful than goto, and are in fact defined in terms of goto,
they are easier to use and safer.

Melissa

--

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

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

<div dir=3D"ltr">On Sunday, August 17, 2014 5:04:26 AM UTC-7, Ville Voutila=
inen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 17 August 2014 1=
2:59, Myriachan &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"dZ47Wjb3dNwJ" onmousedown=3D"this.href=3D'javascript:';return t=
rue;" onclick=3D"this.href=3D'javascript:';return true;">myri...@gmail.com<=
/a>&gt; wrote:
<br>&gt; Wouldn't getting rid of some gotos in favor of something less risk=
y be
<br>&gt; valuable? =3D) &nbsp;To me, the question is more about whether thi=
s would be
<br>&gt; valuable enough to justify the new feature.
<br>
Would it? I don't think that's a simple question, and I don't have a
<br>simple answer. :)
<br>I frankly do not see what causes this desire to get rid of gotos, it se=
ems to be
<br>aiming for getting rid of gotos for irrational reasons.
<br></blockquote><div><br>I find them dangerous, but I don't want to get ri=
d of <span style=3D"font-family: courier new,monospace;">goto</span>s =3D)&=
nbsp; They're fine to leave in the language, but they're also weapons with =
no safeties on them.&nbsp; I'd prefer firearms aimed at our own feet to hav=
e safeties.&nbsp; Thus why I also think runtime-sized arrays and their comp=
anion <span style=3D"font-family: courier new,monospace;">std::dynarray</sp=
an> are long overdue: they can still be dangerous like our old friend <span=
 style=3D"font-family: courier new,monospace;">alloca</span>, but unlike <s=
pan style=3D"font-family: courier new,monospace;">alloca</span>, these weap=
ons have safeties and a better scope attached (figuratively <i>and</i> lite=
rally in this case).&nbsp; Still, I wouldn't advocate the removal of <span =
style=3D"font-family: courier new,monospace;">alloca</span>, either.<br><br=
>I see labeled <span style=3D"font-family: courier new,monospace;">break</s=
pan> and <span style=3D"font-family: courier new,monospace;">continue</span=
> the same way: even though they are strictly less powerful than <span styl=
e=3D"font-family: courier new,monospace;">goto</span>, and are in fact defi=
ned in terms of <span style=3D"font-family: courier new,monospace;">goto</s=
pan>, they are easier to use and safer.<br><br>Melissa<br></div></div>

<p></p>

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

------=_Part_119_1845240474.1408323512406--

.

On 18 August 2014 01:46, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> The majority of those against the proposal are not prepared to entertain or
> be drawn into a nuanced argument about the specifics.  They are applying a
> general policy against extending any statements that can effect control
> flow, on the grounds that you shouldn't need them, because you shouldn't be
> writing complicated control structures to begin with.  They don't care that
> people do find themselves wanting to terminate nested loops or switches,
> they only care about people that are writing the kind of idealized "good
> code", that only exists in their imaginations, and we can find no evidence
> of in reality.

I don't know what exactly causes the majority of those against this proposal
to be against it, but I do find it interesting if we can find no evidence of
the "good code". That would suggest we're looking in the wrong places.

--

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

.

On 18 August 2014 03:47, David Krauss <potswa@gmail.com> wrote:
>> Well, yeah - but "just use goto" is not the only counterargument. The stronger
>> counterargument is to split such nested loops into functions, and that solution
>> works even with constexpr. Yes, I know, many people claim that that is not
>> a palatable solution. For what it's worth, my stubborn head says it's THE
>> solution and the claims that nested loops are necessary do not convince
>> _me_. :)
> Is it helpful to keep others from having a feature that would improve the quality of their code, because

Given that we don't agree on the "would improve the quality" part, yes, it is.

--

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

.

--Apple-Mail=_7DA1709F-C95F-41F8-90BB-179A164E363C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-08-18, at 12:44 PM, Ville Voutilainen <ville.voutilainen@gmail.com>=
 wrote:

> On 18 August 2014 03:47, David Krauss <potswa@gmail.com> wrote:
>>> Well, yeah - but "just use goto" is not the only counterargument. The s=
tronger
>>> counterargument is to split such nested loops into functions, and that =
solution
>>> works even with constexpr. Yes, I know, many people claim that that is =
not
>>> a palatable solution. For what it's worth, my stubborn head says it's T=
HE
>>> solution and the claims that nested loops are necessary do not convince
>>> _me_. :)
>> Is it helpful to keep others from having a feature that would improve th=
e quality of their code, because
>=20
> Given that we don't agree on the "would improve the quality" part, yes, i=
t is.

The measures are fairly objective: compared to goto, break is less work to =
verify and passes more style guides. Compared to a flag, break more cleanly=
 implements early exit, and causes programmers to early-exit more consisten=
tly. Compared to a dedicated function with early return, it's much less boi=
lerplate, easier to read without jumping around the source file and setting=
 bookmarks (a telltale sign of spaghetti), and doesn't rely on function inl=
ining. One of the key benefits of a function, that the enclosed functionali=
ty must be named, also applies where a label is required.

The advantages of nested break are exactly the same as non-nested break. Th=
ose alternatives to nested/labeled break are exactly the same as we'd need =
if we didn't have the break we do.

What is it that makes single-level break worthwhile but not multi-level? Or=
 do you believe the single-level jump statements are also a mistake?

--=20

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

--Apple-Mail=_7DA1709F-C95F-41F8-90BB-179A164E363C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08&ndash;18, at 12:44 PM, Ville Voutilainen &lt;<a href=3D"mailto:vil=
le.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><=
br class=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 18 Augu=
st 2014 03:47, David Krauss &lt;<a href=3D"mailto:potswa@gmail.com">potswa@=
gmail.com</a>&gt; wrote:<br><blockquote type=3D"cite"><blockquote type=3D"c=
ite">Well, yeah - but "just use goto" is not the only counterargument. The =
stronger<br>counterargument is to split such nested loops into functions, a=
nd that solution<br>works even with constexpr. Yes, I know, many people cla=
im that that is not<br>a palatable solution. For what it's worth, my stubbo=
rn head says it's THE<br>solution and the claims that nested loops are nece=
ssary do not convince<br>_me_. :)<br></blockquote>Is it helpful to keep oth=
ers from having a feature that would improve the quality of their code, bec=
ause<br></blockquote><br>Given that we don't agree on the "would improve th=
e quality" part, yes, it is.<br></blockquote></div><br><div>The measures ar=
e fairly objective: compared to <font face=3D"Courier">goto</font>,&nbsp;<s=
pan style=3D"font-family: Courier;">break</span>&nbsp;is less work to verif=
y and passes more style guides. Compared to a flag,&nbsp;<span style=3D"fon=
t-family: Courier;">break</span>&nbsp;more cleanly implements early exit, a=
nd causes programmers to early-exit more consistently. Compared to a dedica=
ted function with early <font face=3D"Courier">return</font>, it&rsquo;s mu=
ch less boilerplate, easier to read without jumping around the source file =
and setting bookmarks (a telltale sign of spaghetti), and doesn&rsquo;t rel=
y on function inlining. One of the key benefits of a function, that the enc=
losed functionality must be named, also applies where a label is required.<=
/div><div><br></div><div>The advantages of nested&nbsp;<span style=3D"font-=
family: Courier;">break</span>&nbsp;are exactly the same as non-nested&nbsp=
;<span style=3D"font-family: Courier;">break</span>. Those alternatives to =
nested/labeled <font face=3D"Courier">break</font> are exactly the same as =
we&rsquo;d need if we didn&rsquo;t have the <font face=3D"Courier">break</f=
ont> we do.</div><div><br></div><div>What is it that makes single-level&nbs=
p;<span style=3D"font-family: Courier;">break</span>&nbsp;worthwhile but no=
t multi-level? Or do you believe the single-level jump statements are also =
a mistake?</div><div><br></div></body></html>

<p></p>

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

--Apple-Mail=_7DA1709F-C95F-41F8-90BB-179A164E363C--

.

On 18 August 2014 20:27, David Krauss <potswa@gmail.com> wrote:
> The measures are fairly objective: compared to goto, break is less work t=
o

Funny how we're not going to agree on them, then.

> verify and passes more style guides. Compared to a flag, break more clean=
ly

I have no reason to believe break is less work to verify in sane code.

> implements early exit, and causes programmers to early-exit more
> consistently. Compared to a dedicated function with early return, it=E2=
=80=99s much
> less boilerplate, easier to read without jumping around the source file a=
nd

This is, of course, not quite so for cases where the (presumably
multi-level) break is not easier to
read than the resulting code using separate functions.

> The advantages of nested break are exactly the same as non-nested break.
> Those alternatives to nested/labeled break are exactly the same as we=E2=
=80=99d need
> if we didn=E2=80=99t have the break we do.
> What is it that makes single-level break worthwhile but not multi-level? =
Or
> do you believe the single-level jump statements are also a mistake?

No, I don't. What makes single-level breaks worthwhile and multi-level
breaks not
is that we already have the former, and they are much more common and neces=
sary
than the latter.

--=20

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

.

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

Multilevel break is good because Ada has it.  Ada is an exemplar of
thoughtful programming language design.  It had things in 1983 that C++ is
still fumbling towards in 2014.  If Ichbiah believed that the language
should support exiting from multiple loops, you would do well to believe
him.


On Mon, Aug 18, 2014 at 1:39 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 18 August 2014 20:27, David Krauss <potswa@gmail.com> wrote:
> > The measures are fairly objective: compared to goto, break is less work
> to
>
> Funny how we're not going to agree on them, then.
>
> > verify and passes more style guides. Compared to a flag, break more
> cleanly
>
> I have no reason to believe break is less work to verify in sane code.
>
> > implements early exit, and causes programmers to early-exit more
> > consistently. Compared to a dedicated function with early return, it=E2=
=80=99s
> much
> > less boilerplate, easier to read without jumping around the source file
> and
>
> This is, of course, not quite so for cases where the (presumably
> multi-level) break is not easier to
> read than the resulting code using separate functions.
>
> > The advantages of nested break are exactly the same as non-nested break=
..
> > Those alternatives to nested/labeled break are exactly the same as we=
=E2=80=99d
> need
> > if we didn=E2=80=99t have the break we do.
> > What is it that makes single-level break worthwhile but not multi-level=
?
> Or
> > do you believe the single-level jump statements are also a mistake?
>
> No, I don't. What makes single-level breaks worthwhile and multi-level
> breaks not
> is that we already have the former, and they are much more common and
> necessary
> than the latter.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr">Multilevel break is good because Ada has it. =C2=A0Ada is =
an exemplar of thoughtful programming language design. =C2=A0It had things =
in 1983 that C++ is still fumbling towards in 2014. =C2=A0If Ichbiah believ=
ed that the language should support exiting from multiple loops, you would =
do well to believe him.</div>

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Aug 1=
8, 2014 at 1:39 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mail=
to:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.c=
om</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 18 August 2014 20:27, Dav=
id Krauss &lt;<a href=3D"mailto:potswa@gmail.com">potswa@gmail.com</a>&gt; =
wrote:<br>


&gt; The measures are fairly objective: compared to goto, break is less wor=
k to<br>
<br>
</div>Funny how we&#39;re not going to agree on them, then.<br>
<div class=3D""><br>
&gt; verify and passes more style guides. Compared to a flag, break more cl=
eanly<br>
<br>
</div>I have no reason to believe break is less work to verify in sane code=
..<br>
<div class=3D""><br>
&gt; implements early exit, and causes programmers to early-exit more<br>
&gt; consistently. Compared to a dedicated function with early return, it=
=E2=80=99s much<br>
&gt; less boilerplate, easier to read without jumping around the source fil=
e and<br>
<br>
</div>This is, of course, not quite so for cases where the (presumably<br>
multi-level) break is not easier to<br>
read than the resulting code using separate functions.<br>
<div class=3D""><br>
&gt; The advantages of nested break are exactly the same as non-nested brea=
k.<br>
&gt; Those alternatives to nested/labeled break are exactly the same as we=
=E2=80=99d need<br>
&gt; if we didn=E2=80=99t have the break we do.<br>
&gt; What is it that makes single-level break worthwhile but not multi-leve=
l? Or<br>
&gt; do you believe the single-level jump statements are also a mistake?<br=
>
<br>
</div>No, I don&#39;t. What makes single-level breaks worthwhile and multi-=
level<br>
breaks not<br>
is that we already have the former, and they are much more common and neces=
sary<br>
than the latter.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><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">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

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

--001a11c29f3ef362270500fbdb85--

.