Topic: break break ;" etc. to break out of nested loops
Author: temptony@freemail.hu
Date: Fri, 5 Apr 2013 12:23:33 -0700 (PDT)
Raw View
------=_Part_388_11946196.1365189813293
Content-Type: text/plain; charset=ISO-8859-1
I hesitate to suggest this simple enhancement to the language, because it's
so obvious that *somebody* must have thought of it before. In which case
there must have been a good reason for rejecting it! But here goes:
*Problem*
The *break* statement jumps out of the nearest enclosing *do, for, switch, *or
*while *statement. All programmers know that breaking out of a nested
for-loop to the *second*-nearest enclosing *do, for, switch, *or *while *statement
is a pain, and requires a *goto* statement or worse.
*Suggestion*
I suggest the following syntax:
The *break break* statement jumps out of the second-nearest enclosing *do,
for, switch, *or *while *statement.
The *break break* *break *statement jumps out of the third-nearest
enclosing *do, for, switch, *or *while *statement.
The *break break* *break break *statement jumps out of the fourth-nearest
enclosing *do, for, switch, *or *while *statement.
And so on. For instance:
for (int i = 0 ; i < 10 ; i++)
for (int j = 0 ; j < 10 ; j++)
for (int k = 0 ; k < 10 ; k++) {
// do stuff
if (a[i][j][k] == 0) break break break ; // the same as "goto
ContinueExecution ;"
}
ContinueExecution:
Easy to understand. Easy to implement. 100% backwards compatible. What's
not to like?
--
---
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/?hl=en.
------=_Part_388_11946196.1365189813293
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I hesitate to suggest this simple enhancement to the language, because it's=
so obvious that <i>somebody</i> must have thought of it before. In which c=
ase there must have been a good reason for rejecting it! But here goes:<div=
><div><br></div><div><i>Problem</i></div><div>The <b>break</b> stateme=
nt jumps out of the nearest enclosing <b>do, for, switch, </b>or <b>while <=
/b>statement. All programmers know that breaking out of a nested for-loop t=
o the <i>second</i>-nearest enclosing <b>do, for, switch, </b>or&=
nbsp;<b>while </b>statement is a pain, and requires a <b>goto</b> =
;statement or worse.</div><div><br></div><div><i>Suggestion</i></div><div>I=
suggest the following syntax:</div><div><br></div><div>The <b>break&n=
bsp;break</b> statement jumps out of the second-nearest enclosing <b>d=
o, for, switch, </b>or <b>while </b>statement.<br></div><div=
>The <b>break break</b> <b>break </b>statement jumps ou=
t of the third-nearest enclosing <b>do, for, switch, </b>or =
<b>while </b>statement.<br></div><div>The <b>break break</b>=
<b>break break </b>statement jumps out of the fourth-nearest enc=
losing <b>do, for, switch, </b>or <b>while </b>statemen=
t.<br></div><div><br></div><div>And so on. For instance:</div><div><br></di=
v><div>for (int i =3D 0 ; i < 10 ; i++)</div><div> for (int j =3D =
0 ; j < 10 ; j++)</div><div> for (int k =3D 0 ; k < 10 ;=
k++) {<br></div><div> // do stuff</div><div> &nb=
sp; if (a[i][j][k] =3D=3D 0) break break break ; // the same as "got=
o ContinueExecution ;"</div><div> }</div><div>ContinueExecutio=
n:<br></div><div><br></div><div>Easy to understand. Easy to implement. 100%=
backwards compatible. What's not to like?</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_388_11946196.1365189813293--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 6 Apr 2013 14:39:42 +0300
Raw View
--047d7b2e0887dba6eb04d9afa839
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 6 April 2013 12:23, <morwenn29@gmail.com> wrote:
> Le samedi 6 avril 2013 08:41:52 UTC+2, Chip Salzenberg a =E9crit :
>
>> On 4/5/2013 3:23 PM, Tony V E wrote:
>> > label: for (;;)
>> > {
>> > break label;
>> > }
>>
>> Yes, please; if this must be done, this is the way. It's one of the
>> things that's actually worth borrowing from Perl. The label is
>> semantically useful, and not brittle if another level is added. Thus:
>>
>> line:
>> while (cin >> s) {
>> ...
>> if (COND) continue line;
>> ...
>> }
>>
>
> That seems to be the only viable way to go for this kind of problem. The
> break 1, break 2, break 3, etc... is easy to understand but, even as a
> compile-time constant, I dont want to imagine what could be done with suc=
h
> a construct (well, I don't want to know, but never see it in real code):
>
>
Sure, java has a similar labeled-break. I just don't see much reason to
have such a labeled-break instead of goto.
--=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/?hl=3Den.
--047d7b2e0887dba6eb04d9afa839
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 6=
April 2013 12:23, <span dir=3D"ltr"><<a href=3D"mailto:morwenn29@gmail=
..com" target=3D"_blank">morwenn29@gmail.com</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex">
Le samedi 6 avril 2013 08:41:52 UTC+2, Chip Salzenberg a =E9crit=A0:<div cl=
ass=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 4/5/2013 3:23 PM, Ton=
y V E wrote:
<br>> label: for (;;)
<br>> {
<br>> =A0 =A0break label;
<br>> }
<br>
<br>Yes, please; if this must be done, this is the way. =A0It's one of =
the
<br>things that's actually worth borrowing from Perl. =A0The label is
<br>semantically useful, and not brittle if another level is added. =A0Thus=
:
<br>
<br>=A0 =A0 line:
<br>=A0 =A0 =A0 while (cin >> s) {
<br>=A0 =A0 =A0 =A0 =A0 ...
<br>=A0 =A0 =A0 =A0 =A0 if (COND) continue line;
<br>=A0 =A0 =A0 =A0 =A0 ...
<br>=A0 =A0 =A0 }<br></blockquote><div>=A0</div></div><div>=A0That seems to=
be the only viable way to go for this kind of problem. The break 1, break =
2, break 3, etc... is easy to understand but, even as a compile-time consta=
nt, I dont want to imagine what could be done with such a construct (well, =
I don't want to know, but never see it in real code):<br>
<br></div></blockquote><div><br></div><div>Sure, java has a similar labeled=
-break. I just don't see much reason to have such a labeled-break inste=
ad of goto. <br></div></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7b2e0887dba6eb04d9afa839--
.
Author: Reverend Chip <rev.chip@gmail.com>
Date: Fri, 05 Apr 2013 23:41:52 -0700
Raw View
On 4/5/2013 3:23 PM, Tony V E wrote:
> label: for (;;)
> {
> break label;
> }
Yes, please; if this must be done, this is the way. It's one of the
things that's actually worth borrowing from Perl. The label is
semantically useful, and not brittle if another level is added. Thus:
line:
while (cin >> s) {
...
if (COND) continue line;
...
}
--
---
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/?hl=en.
.
Author: temptony@freemail.hu
Date: Sat, 6 Apr 2013 07:31:03 -0700 (PDT)
Raw View
------=_Part_2696_25765825.1365258663919
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, April 6, 2013 12:23:20 AM UTC+2, Tony V E wrote:
And I'd rather have:
>
> break name;
>
> For a named loop construct somehow. Maybe
>
> label: for (;;)
> {
> break label;
> }
>
>
One reason for my proposal was to do away with superfluous labels. So this
doesn't get my support.
--
---
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/?hl=en.
------=_Part_2696_25765825.1365258663919
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, April 6, 2013 12:23:20 AM UTC+2, Tony V E wrote:<div><br><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">And I'd rather hav=
e:<br><div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">=
break name;<br><br></div><div class=3D"gmail_quote">
For a named loop construct somehow. Maybe<br><br></div><div class=3D"gmail_=
quote">label: for (;;)<br>{<br></div><div class=3D"gmail_quote">  =
; break label;<br>}<br><br></div></div></div></blockquote><div> </div>=
One reason for my proposal was to do away with superfluous labels. So this =
doesn't get my support.<br><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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2696_25765825.1365258663919--
.
Author: =?UTF-8?Q?Andrzej_Krzemie=C5=84ski?= <akrzemi1@gmail.com>
Date: Sat, 6 Apr 2013 06:59:47 -0700 (PDT)
Raw View
------=_Part_2833_14956985.1365256787789
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
W dniu sobota, 6 kwietnia 2013 02:26:49 UTC+2 u=BFytkownik Patrick M.=20
Niedzielski napisa=B3:
>
> On ven, 2013-04-05 at 12:53 -0700, Andrew Sandoval wrote:=20
> > How about *return*? That way you are pushed towards keeping your=20
> functions=20
> > simple.=20
>
> [slightly off-topic, but keeping the same thread for now]=20
>
> For large and complex loops, this is good advice. For small and short=20
> nested loops (looping a single statement over a two dimensional array),=
=20
> breaking the code off into a separate function can (*can*, not *will*)=20
> make the code harder to understand. It should be determined on a=20
> case-by-case basis whether breaking the code into a separate function is=
=20
> actually productive or makes the flow and reasoning behind the code less=
=20
> clear.=20
>
> This is actually an okay place for a goto, if the loops are short and=20
> clear, and breaking the two loops into a separate function doesn't make=
=20
> sense. Just be sure to document the reason for its use in the code.=20
>
+ 1
Programmers are told to avoid "goto" so aggressively, that they forget it=
=20
is sometimes just useful. Goto offers functionality only slightly worse=20
that labelled loops. And given that the problem we are trying to solve=20
occurs fairly rarely (or am I wrong?), I do not believe an alternative to=
=20
"goto" is worth the C++ Committee's effort.
Regards,
&rzej
=20
--=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/?hl=3Den.
------=_Part_2833_14956985.1365256787789
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
<br><br>W dniu sobota, 6 kwietnia 2013 02:26:49 UTC+2 u=BFytkownik Patrick =
M. Niedzielski napisa=B3:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On ve=
n, 2013-04-05 at 12:53 -0700, Andrew Sandoval wrote:
<br>> How about *return*? That way you are pushed towards keeping =
your functions=20
<br>> simple.
<br>
<br>[slightly off-topic, but keeping the same thread for now]
<br>
<br>For large and complex loops, this is good advice. For small and s=
hort
<br>nested loops (looping a single statement over a two dimensional array),
<br>breaking the code off into a separate function can (*can*, not *will*)
<br>make the code harder to understand. It should be determined on a
<br>case-by-case basis whether breaking the code into a separate function i=
s
<br>actually productive or makes the flow and reasoning behind the code les=
s
<br>clear.
<br>
<br>This is actually an okay place for a goto, if the loops are short and
<br>clear, and breaking the two loops into a separate function doesn't make
<br>sense. Just be sure to document the reason for its use in the cod=
e.
<br></blockquote><div><br>+ 1<br>Programmers are told to avoid "goto" so ag=
gressively, that they forget it is sometimes just useful. Goto offers funct=
ionality only slightly worse that labelled loops. And given that the proble=
m we are trying to solve occurs fairly rarely (or am I wrong?), I do not be=
lieve an alternative to "goto" is worth the C++ Committee's effort.<br><br>=
Regards,<br>&rzej<br><br> <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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2833_14956985.1365256787789--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Fri, 5 Apr 2013 18:23:20 -0400
Raw View
--f46d04016c39dc713504d9a488aa
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Apr 5, 2013 at 3:23 PM, <temptony@freemail.hu> wrote:
> I suggest the following syntax:
>
> The *break break* statement jumps out of the second-nearest enclosing *do,
> for, switch, *or *while *statement.
> The *break break* *break *statement jumps out of the third-nearest
> enclosing *do, for, switch, *or *while *statement.
> The *break break* *break break *statement jumps out of the fourth-nearest
> enclosing *do, for, switch, *or *while *statement.
>
>
break;
break(2);
break(3);
break(4);
(and break(1) would also work).
Not sure about runtime values
int n = ...
break(n);
And I'd rather have:
break name;
For a named loop construct somehow. Maybe
label: for (;;)
{
break label;
}
And all that is not saying I agree with any of it, or really want it; just
some suggestions.
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--f46d04016c39dc713504d9a488aa
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, Apr 5, 2013 at 3:23 PM, <span dir=3D"ltr"><<a href=3D"m=
ailto:temptony@freemail.hu" target=3D"_blank">temptony@freemail.hu</a>><=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I suggest the following syntax:<div><div><br=
></div><div>The=A0<b>break=A0break</b> statement jumps out of the second-ne=
arest enclosing=A0<b>do, for, switch,=A0</b>or=A0<b>while=A0</b>statement.<=
br>
</div><div>The=A0<b>break=A0break</b>=A0<b>break=A0</b>statement jumps out =
of the third-nearest enclosing=A0<b>do, for, switch,=A0</b>or=A0<b>while=A0=
</b>statement.<br></div><div>The=A0<b>break=A0break</b>=A0<b>break break=A0=
</b>statement jumps out of the fourth-nearest enclosing=A0<b>do, for, switc=
h,=A0</b>or=A0<b>while=A0</b>statement.<br>
</div><div><br></div></div></blockquote><div><br></div><div>break;<br>break=
(2);<br>break(3);<br></div><div>break(4);<br>=A0<br></div>(and break(1) wou=
ld also work).<br><br></div><div class=3D"gmail_quote">Not sure about runti=
me values<br>
<br></div><div class=3D"gmail_quote">int n =3D ...<br></div><div class=3D"g=
mail_quote">break(n);<br><br></div><div class=3D"gmail_quote">And I'd r=
ather have:<br><br></div><div class=3D"gmail_quote">break name;<br><br></di=
v><div class=3D"gmail_quote">
For a named loop construct somehow. Maybe<br><br></div><div class=3D"gmail_=
quote">label: for (;;)<br>{<br></div><div class=3D"gmail_quote">=A0=A0 brea=
k label;<br>}<br><br></div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">
And all that is not saying I agree with any of it, or really want it; just =
some suggestions.<br><br></div><div class=3D"gmail_quote">Tony<br><br></div=
></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--f46d04016c39dc713504d9a488aa--
.
Author: Benjamin Lindley <benjameslindley@gmail.com>
Date: Sat, 6 Apr 2013 05:57:52 -0700 (PDT)
Raw View
------=_Part_25_3558348.1365253072562
Content-Type: text/plain; charset=ISO-8859-1
I think this is a great idea. Yes, it would be preferred to do what
Sandoval mentioned, and return from a function, but why not have this
option too? It seems to me that it is exactly as the OP said
> "Easy to understand. Easy to implement. 100% backwards compatible."
>
I'm not sure how it makes the intention obscure. Two breaks in a row means
break, then break again. 3 breaks means break, then break, then break. I
would even suggest an addition. The ability to add one continue to a
series of breaks.
--
---
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/?hl=en.
------=_Part_25_3558348.1365253072562
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>I think this is a great idea. Yes, it would be preferred to do w=
hat Sandoval mentioned, and return from a function, but why not have this o=
ption too? It seems to me that it is exactly as the OP said</div><div=
> </div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1=
px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">"Eas=
y to understand. Easy to implement. 100% backwards compatible."<br></blockq=
uote><br>I'm not sure how it makes the intention obscure. Two breaks in a r=
ow means break, then break again. 3 breaks means break, then break, t=
hen break. I would even suggest an addition. The ability to add=
one continue to a series of breaks.<br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_25_3558348.1365253072562--
.
Author: Andrew Sandoval <sandoval@netwaysglobal.com>
Date: Fri, 5 Apr 2013 12:53:33 -0700 (PDT)
Raw View
------=_Part_526_31641456.1365191613317
Content-Type: text/plain; charset=ISO-8859-1
On Friday, April 5, 2013 2:23:33 PM UTC-5, temp...@freemail.hu wrote:
>
> I hesitate to suggest this simple enhancement to the language, because
> it's so obvious that *somebody* must have thought of it before. In which
> case there must have been a good reason for rejecting it! But here goes:
>
> *Problem*
> The *break* statement jumps out of the nearest enclosing *do, for,
> switch, *or *while *statement. All programmers know that breaking out of
> a nested for-loop to the *second*-nearest enclosing *do, for, switch, *or
> *while *statement is a pain, and requires a *goto* statement or worse.
>
> *Suggestion*
> I suggest the following syntax:
>
> The *break break* statement jumps out of the second-nearest enclosing *do,
> for, switch, *or *while *statement.
> The *break break* *break *statement jumps out of the third-nearest
> enclosing *do, for, switch, *or *while *statement.
> The *break break* *break break *statement jumps out of the fourth-nearest
> enclosing *do, for, switch, *or *while *statement.
>
> And so on. For instance:
>
> for (int i = 0 ; i < 10 ; i++)
> for (int j = 0 ; j < 10 ; j++)
> for (int k = 0 ; k < 10 ; k++) {
> // do stuff
> if (a[i][j][k] == 0) break break break ; // the same as "goto
> ContinueExecution ;"
> }
> ContinueExecution:
>
> Easy to understand. Easy to implement. 100% backwards compatible. What's
> not to like?
>
How about *return*? That way you are pushed towards keeping your functions
simple.
Not trying to be negative, but that seems like something you wouldn't hit
too often in C++ code -- C, yes, but hopefully not C++.
-Andrew Sandoval
--
---
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/?hl=en.
------=_Part_526_31641456.1365191613317
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, April 5, 2013 2:23:33 PM UTC-5, temp...@freemail.hu wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">I hesitate to suggest this simple en=
hancement to the language, because it's so obvious that <i>somebody</i> mus=
t have thought of it before. In which case there must have been a good reas=
on for rejecting it! But here goes:<div><div><br></div><div><i>Problem</i><=
/div><div>The <b>break</b> statement jumps out of the nearest enclosin=
g <b>do, for, switch, </b>or <b>while </b>statement. All programmers know t=
hat breaking out of a nested for-loop to the <i>second</i>-nearest enclosin=
g <b>do, for, switch, </b>or <b>while </b>statement is =
a pain, and requires a <b>goto</b> statement or worse.</div><div><br><=
/div><div><i>Suggestion</i></div><div>I suggest the following syntax:</div>=
<div><br></div><div>The <b>break break</b> statement jumps out of=
the second-nearest enclosing <b>do, for, switch, </b>or <b>=
while </b>statement.<br></div><div>The <b>break break</b>&nb=
sp;<b>break </b>statemen<wbr>t jumps out of the third-nearest enclosin=
g <b>do, for, switch, </b>or <b>while </b>statement.<br=
></div><div>The <b>break break</b> <b>break break </b>s=
tatement jumps out of the fourth-nearest enclosing <b>do, for, switch,=
</b>or <b>while </b>statement.<br></div><div><br></div><div=
>And so on. For instance:</div><div><br></div><div>for (int i =3D 0 ; i <=
; 10 ; i++)</div><div> for (int j =3D 0 ; j < 10 ; j++)</div><div>=
for (int k =3D 0 ; k < 10 ; k++) {<br></div><div> &n=
bsp; // do stuff</div><div> if (a[i][j][k] =3D=
=3D 0) break break break ; // the same as "goto ContinueExecution ;"</div><=
div> }</div><div>ContinueExecution:<br></div><div><br></div><d=
iv>Easy to understand. Easy to implement. 100% backwards compatible. What's=
not to like?</div></div></blockquote><div><br>How about <span style=3D"col=
or: rgb(0, 0, 255);"><b><span style=3D"font-family: courier new,monospace;"=
>return</span></b></span>? That way you are pushed towards keeping yo=
ur functions simple.<br>Not trying to be negative, but that seems like some=
thing you wouldn't hit too often in C++ code -- C, yes, but hopefully not C=
++.<br><br>-Andrew Sandoval<br> <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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_526_31641456.1365191613317--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Fri, 5 Apr 2013 22:26:07 +0200
Raw View
--089e01294d0ca643b804d9a2e5e9
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Apr 5, 2013 at 9:23 PM, <temptony@freemail.hu> wrote:
> I suggest the following syntax:
>
> The *break break* statement jumps out of the second-nearest enclosing *do,
> for, switch, *or *while *statement.
> The *break break* *break *statement jumps out of the third-nearest
> enclosing *do, for, switch, *or *while *statement.
> The *break break* *break break *statement jumps out of the fourth-nearest
> enclosing *do, for, switch, *or *while *statement.
>
That would make the intention (of the author of the code) very obscure.
Also, most C++11 new keywords and syntaxes targets reduction of code to
write relative to code structure complexity.
To me, your proposition goes backward to this.
I remember having read some ideas about keywords for jumping out of several
loop blocks,
but they almost are all opposed by suggestions adding functions (add
another layer of abstraction).
A feature for getting out of these imbricated loops would be cool on short
term,
but on long term I think avoiding imbricating blocks is far better.
Joel Lamotte
--
---
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/?hl=en.
--089e01294d0ca643b804d9a2e5e9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Fri, Apr 5, 2013 at 9:23 PM, <span dir=3D"ltr"><<a href=3D"mailto:te=
mptony@freemail.hu" target=3D"_blank">temptony@freemail.hu</a>></span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>I suggest the following syntax:</div><d=
iv><br></div><div>The=A0<b>break=A0break</b> statement jumps out of the sec=
ond-nearest enclosing=A0<b>do, for, switch,=A0</b>or=A0<b>while=A0</b>state=
ment.<br>
</div><div>The=A0<b>break=A0break</b>=A0<b>break=A0</b>statement jumps out =
of the third-nearest enclosing=A0<b>do, for, switch,=A0</b>or=A0<b>while=A0=
</b>statement.<br></div><div>The=A0<b>break=A0break</b>=A0<b>break break=A0=
</b>statement jumps out of the fourth-nearest enclosing=A0<b>do, for, switc=
h,=A0</b>or=A0<b>while=A0</b>statement.</div>
</blockquote></div><br>That would make the intention (of the author of the =
code) very obscure.</div><div class=3D"gmail_extra" style><br></div><div cl=
ass=3D"gmail_extra" style>Also, most C++11 new keywords and syntaxes target=
s reduction of code to write relative to code structure complexity.</div>
<div class=3D"gmail_extra" style>To me, your proposition goes backward to t=
his.</div><div class=3D"gmail_extra" style><br></div><div class=3D"gmail_ex=
tra" style><br></div><div class=3D"gmail_extra" style>I remember having rea=
d some ideas about keywords for jumping out of several loop blocks,</div>
<div class=3D"gmail_extra" style>but they almost are all opposed =A0by sugg=
estions adding functions (add another layer of abstraction).</div><div clas=
s=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style>A featur=
e for getting out of these imbricated loops would be cool on short term,</d=
iv>
<div class=3D"gmail_extra" style>but on long term I think avoiding imbricat=
ing blocks is far better.</div><div class=3D"gmail_extra" style><br></div><=
div class=3D"gmail_extra" style>Joel Lamotte</div><div class=3D"gmail_extra=
" style>
<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--089e01294d0ca643b804d9a2e5e9--
.
Author: temptony@freemail.hu
Date: Fri, 5 Apr 2013 13:16:41 -0700 (PDT)
Raw View
------=_Part_2294_8534313.1365193001161
Content-Type: text/plain; charset=ISO-8859-1
It's not the business of the C++ standard to push programmers towards
keeping their functions simple! Nothing you say speaks against allowing *break
break...* into the language.
On Friday, April 5, 2013 9:53:33 PM UTC+2, Andrew Sandoval wrote:
>
> On Friday, April 5, 2013 2:23:33 PM UTC-5, temp...@freemail.hu wrote:
>>
>> I hesitate to suggest this simple enhancement to the language, because
>> it's so obvious that *somebody* must have thought of it before. In which
>> case there must have been a good reason for rejecting it! But here goes:
>>
>> *Problem*
>> The *break* statement jumps out of the nearest enclosing *do, for,
>> switch, *or *while *statement. All programmers know that breaking out of
>> a nested for-loop to the *second*-nearest enclosing *do, for, switch, *
>> or *while *statement is a pain, and requires a *goto* statement or worse.
>>
>> *Suggestion*
>> I suggest the following syntax:
>>
>> The *break break* statement jumps out of the second-nearest enclosing *do,
>> for, switch, *or *while *statement.
>> The *break break* *break *statement jumps out of the third-nearest
>> enclosing *do, for, switch, *or *while *statement.
>> The *break break* *break break *statement jumps out of the
>> fourth-nearest enclosing *do, for, switch, *or *while *statement.
>>
>> And so on. For instance:
>>
>> for (int i = 0 ; i < 10 ; i++)
>> for (int j = 0 ; j < 10 ; j++)
>> for (int k = 0 ; k < 10 ; k++) {
>> // do stuff
>> if (a[i][j][k] == 0) break break break ; // the same as "goto
>> ContinueExecution ;"
>> }
>> ContinueExecution:
>>
>> Easy to understand. Easy to implement. 100% backwards compatible. What's
>> not to like?
>>
>
> How about *return*? That way you are pushed towards keeping your
> functions simple.
> Not trying to be negative, but that seems like something you wouldn't hit
> too often in C++ code -- C, yes, but hopefully not C++.
>
> -Andrew Sandoval
>
>
--
---
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/?hl=en.
------=_Part_2294_8534313.1365193001161
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
It's not the business of the C++ standard to push programmers towards keepi=
ng their functions simple! Nothing you say speaks against allowing <b>break=
break...</b> into the language.<br><br>On Friday, April 5, 2013 9:53:=
33 PM UTC+2, Andrew Sandoval wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">On Friday, April 5, 2013 2:23:33 PM UTC-5, <a>temp...@freemail.hu</a>=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex">I hesitate to suggest this s=
imple enhancement to the language, because it's so obvious that <i>somebody=
</i> must have thought of it before. In which case there must have been a g=
ood reason for rejecting it! But here goes:<div><div><br></div><div><i>Prob=
lem</i></div><div>The <b>break</b> statement jumps out of the nearest =
enclosing <b>do, for, switch, </b>or <b>while </b>statement. All programmer=
s know that breaking out of a nested for-loop to the <i>second</i>-nearest =
enclosing <b>do, for, switch, </b>or <b>while </b>state=
ment is a pain, and requires a <b>goto</b> statement or worse.</div><d=
iv><br></div><div><i>Suggestion</i></div><div>I suggest the following synta=
x:</div><div><br></div><div>The <b>break break</b> statement jump=
s out of the second-nearest enclosing <b>do, for, switch, </b>or&=
nbsp;<b>while </b>statement.<br></div><div>The <b>break brea=
k</b> <b>break </b>statemen<wbr>t jumps out of the third-nearest =
enclosing <b>do, for, switch, </b>or <b>while </b>state=
ment.<br></div><div>The <b>break break</b> <b>break break&nb=
sp;</b>statement jumps out of the fourth-nearest enclosing <b>do, for,=
switch, </b>or <b>while </b>statement.<br></div><div><br></=
div><div>And so on. For instance:</div><div><br></div><div>for (int i =3D 0=
; i < 10 ; i++)</div><div> for (int j =3D 0 ; j < 10 ; j++)</d=
iv><div> for (int k =3D 0 ; k < 10 ; k++) {<br></div><div>&=
nbsp; // do stuff</div><div> if (a[i][j][=
k] =3D=3D 0) break break break ; // the same as "goto ContinueExecution ;"<=
/div><div> }</div><div>ContinueExecution:<br></div><div><br></=
div><div>Easy to understand. Easy to implement. 100% backwards compatible. =
What's not to like?</div></div></blockquote><div><br>How about <span style=
=3D"color:rgb(0,0,255)"><b><span style=3D"font-family:courier new,monospace=
">return</span></b></span>? That way you are pushed towards keeping y=
our functions simple.<br>Not trying to be negative, but that seems like som=
ething you wouldn't hit too often in C++ code -- C, yes, but hopefully not =
C++.<br><br>-Andrew Sandoval<br> <br></div></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2294_8534313.1365193001161--
.
Author: morwenn29@gmail.com
Date: Sat, 6 Apr 2013 02:23:01 -0700 (PDT)
Raw View
------=_Part_2600_9437091.1365240181315
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Le samedi 6 avril 2013 08:41:52 UTC+2, Chip Salzenberg a =E9crit :
>
> On 4/5/2013 3:23 PM, Tony V E wrote:=20
> > label: for (;;)=20
> > {=20
> > break label;=20
> > }=20
>
> Yes, please; if this must be done, this is the way. It's one of the=20
> things that's actually worth borrowing from Perl. The label is=20
> semantically useful, and not brittle if another level is added. Thus:=20
>
> line:=20
> while (cin >> s) {=20
> ...=20
> if (COND) continue line;=20
> ...=20
> }
>
=20
That seems to be the only viable way to go for this kind of problem. The=
=20
break 1, break 2, break 3, etc... is easy to understand but, even as a=20
compile-time constant, I dont want to imagine what could be done with such=
=20
a construct (well, I don't want to know, but never see it in real code):
template<unsigned N>
void foobar()
{
for (...;...;...) {
for (...;...;...) {
for (...;...;...) {
break N; // sit down and enjoy the complexity as if=20
there was no tomorrow
}
}
}
}
Well, this kind of problems will never be encountered with a labeled break.=
=20
But the label break is more verbose is the sense we need to label name.
In most of the cases, putting the nested loops in a function and using=20
return is enough.
If you want to read some more things about those breaks, there has been a=
=20
proposal for Python:
http://www.python.org/dev/peps/pep-3136/
It has been rejected, the reasons are included. That could be a good thing=
=20
to read.
--=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/?hl=3Den.
------=_Part_2600_9437091.1365240181315
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Le samedi 6 avril 2013 08:41:52 UTC+2, Chip Salzenberg a =E9crit :<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">On 4/5/2013 3:23 PM, Tony V E wrot=
e:
<br>> label: for (;;)
<br>> {
<br>> break label;
<br>> }
<br>
<br>Yes, please; if this must be done, this is the way. It's one of t=
he
<br>things that's actually worth borrowing from Perl. The label is
<br>semantically useful, and not brittle if another level is added. T=
hus:
<br>
<br> line:
<br> while (cin >> s) {
<br> ...
<br> if (COND) continue line;
<br> ...
<br> }<br></blockquote><div> </div><div> That=
seems to be the only viable way to go for this kind of problem. The break =
1, break 2, break 3, etc... is easy to understand but, even as a compile-ti=
me constant, I dont want to imagine what could be done with such a construc=
t (well, I don't want to know, but never see it in real code):<br><br> =
; template<unsigned N><br> void foobar(=
)<br> {<br> for=
(...;...;...) {<br> &=
nbsp; for (...;...;...) {<br> &nbs=
p; for (...;...;...) {<br>&=
nbsp; &nbs=
p; break N; // sit down and enjoy the c=
omplexity as if there was no tomorrow<br> &nbs=
p; }<br> &=
nbsp; }<br> &nbs=
p; }<br> }<br><br>Well, this kind=
of problems will never be encountered with a labeled break. But the label =
break is more verbose is the sense we need to label name.<br>In most of the=
cases, putting the nested loops in a function and using return is enough.<=
br><br>If you want to read some more things about those breaks, there has b=
een a proposal for Python:<br>http://www.python.org/dev/peps/pep-3136/<br>I=
t has been rejected, the reasons are included. That could be a good thing t=
o read.<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2600_9437091.1365240181315--
.
Author: Gabriel Dos Reis <gdr@axiomatics.org>
Date: Fri, 05 Apr 2013 15:41:27 -0500
Raw View
temptony@freemail.hu writes:
| It's not the business of the C++ standard to push programmers towards keeping
| their functions simple!
Maybe it is time it does?
--
---
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/?hl=en.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Sat, 6 Apr 2013 12:32:05 -0700
Raw View
--14dae93410f938d51b04d9b642dd
Content-Type: text/plain; charset=ISO-8859-1
On Apr 5, 2013 3:23 PM, "Tony V E" <tvaneerd@gmail.com> wrote:
>
>
>
>
> On Fri, Apr 5, 2013 at 3:23 PM, <temptony@freemail.hu> wrote:
>>
>> I suggest the following syntax:
>>
>> The break break statement jumps out of the second-nearest enclosing do,
for, switch, or while statement.
>> The break break break statement jumps out of the third-nearest
enclosing do, for, switch, or while statement.
>> The break break break break statement jumps out of the fourth-nearest
enclosing do, for, switch, or while statement.
>>
>
> break;
> break(2);
> break(3);
> break(4);
>
> (and break(1) would also work).
>
> Not sure about runtime values
>
> int n = ...
> break(n);
>
> And I'd rather have:
>
> break name;
>
> For a named loop construct somehow. Maybe
>
> label: for (;;)
> {
> break label;
> }
>
>
> And all that is not saying I agree with any of it, or really want it;
just some suggestions.
I think I would prefer
for outer (...) {
for (...) {
if (...)
break outer;
}
}
Using a label to refer to its labeled statement feels like an abuse of the
facility to me.
> Tony
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
--
---
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/?hl=en.
--14dae93410f938d51b04d9b642dd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
On Apr 5, 2013 3:23 PM, "Tony V E" <<a href=3D"mailto:tvaneerd=
@gmail.com">tvaneerd@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
><br>
> On Fri, Apr 5, 2013 at 3:23 PM, <<a href=3D"mailto:temptony@freemai=
l.hu">temptony@freemail.hu</a>> wrote:<br>
>><br>
>> I suggest the following syntax:<br>
>><br>
>> The=A0break=A0break statement jumps out of the second-nearest encl=
osing=A0do, for, switch,=A0or=A0while=A0statement.<br>
>> The=A0break=A0break=A0break=A0statement jumps out of the third-nea=
rest enclosing=A0do, for, switch,=A0or=A0while=A0statement.<br>
>> The=A0break=A0break=A0break break=A0statement jumps out of the fou=
rth-nearest enclosing=A0do, for, switch,=A0or=A0while=A0statement.<br>
>><br>
><br>
> break;<br>
> break(2);<br>
> break(3);<br>
> break(4);<br>
> =A0<br>
> (and break(1) would also work).<br>
><br>
> Not sure about runtime values<br>
><br>
> int n =3D ...<br>
> break(n);<br>
><br>
> And I'd rather have:<br>
><br>
> break name;<br>
><br>
> For a named loop construct somehow. Maybe<br>
><br>
> label: for (;;)<br>
> {<br>
> =A0=A0 break label;<br>
> }<br>
><br>
><br>
> And all that is not saying I agree with any of it, or really want it; =
just some suggestions.</p>
<p dir=3D"ltr">I think I would prefer </p>
<p dir=3D"ltr">for outer (...) {<br>
=A0 for (...) {<br>
=A0=A0=A0 if (...)<br>
=A0=A0=A0=A0=A0 break outer;<br>
=A0 }<br>
}</p>
<p dir=3D"ltr">Using a label to refer to its labeled statement feels like a=
n abuse of the facility to me.</p>
<p dir=3D"ltr">> Tony<br>
><br>
> -- <br>
> =A0<br>
> --- <br>
> You received this message because you are subscribed to the Google Gro=
ups "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-=
proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/st=
d-proposals/?hl=3Den</a>.<br>
> =A0<br>
> =A0<br>
</p>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--14dae93410f938d51b04d9b642dd--
.
Author: temptony@freemail.hu
Date: Sat, 6 Apr 2013 12:37:56 -0700 (PDT)
Raw View
------=_Part_347_22799174.1365277076340
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, April 6, 2013 9:32:05 PM UTC+2, Richard Smith wrote:
I think I would prefer
>
> for outer (...) {
> for (...) {
> if (...)
> break outer;
> }
> }
>
> Using a label to refer to its labeled statement feels like an abuse of the
> facility to me.
>
Please, can we leave labels and other identifiers out of this? You don't
have to support my proposal, but I wish you wouldn't all try to distort it
like this. You can submit your own proposals, after all.
--
---
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/?hl=en.
------=_Part_347_22799174.1365277076340
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>On Saturday, April 6, 2013 9:32:05 PM UTC+2, Richard Smith wrote:<br><=
/div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"=
ltr">I think I would prefer<br></p>
<p dir=3D"ltr">for outer (...) {<br>
for (...) {<br>
if (...)<br>
break outer;<br>
}<br>
}</p>
<p dir=3D"ltr">Using a label to refer to its labeled statement feels like a=
n abuse of the facility to me.</p></blockquote><div> </div><div>Please=
, can we leave labels and other identifiers out of this? You don't have to =
support my proposal, but I wish you wouldn't all try to distort it like thi=
s. You can submit your own proposals, after all.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_347_22799174.1365277076340--
.
Author: Patrick Michael Niedzielski <patrickniedzielski@gmail.com>
Date: Sat, 06 Apr 2013 00:26:49 +0000
Raw View
On ven, 2013-04-05 at 12:53 -0700, Andrew Sandoval wrote:
> How about *return*? That way you are pushed towards keeping your functions
> simple.
[slightly off-topic, but keeping the same thread for now]
For large and complex loops, this is good advice. For small and short
nested loops (looping a single statement over a two dimensional array),
breaking the code off into a separate function can (*can*, not *will*)
make the code harder to understand. It should be determined on a
case-by-case basis whether breaking the code into a separate function is
actually productive or makes the flow and reasoning behind the code less
clear.
This is actually an okay place for a goto, if the loops are short and
clear, and breaking the two loops into a separate function doesn't make
sense. Just be sure to document the reason for its use in the code.
Cheers,
Patrick Niedzielski
--
---
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/?hl=en.
.
Author: Chris Jefferson <chris@bubblescope.net>
Date: Sun, 07 Apr 2013 11:06:12 +0100
Raw View
This is a multi-part message in MIME format.
--------------020904000105000403000405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 05/04/13 20:23, temptony@freemail.hu wrote:
> I hesitate to suggest this simple enhancement to the language, because
> it's so obvious that /somebody/ must have thought of it before. In
> which case there must have been a good reason for rejecting it! But
> here goes:
>
> /Problem/
> The *break* statement jumps out of the nearest enclosing *do, for,
> switch, *or *while *statement. All programmers know that breaking out
> of a nested for-loop to the /second/-nearest enclosing *do, for,
> switch, *or *while *statement is a pain, and requires a
> *goto* statement or worse.
>
> /Suggestion/
> I suggest the following syntax:
>
> The *break break* statement jumps out of the second-nearest enclosing
> *do, for, switch, *or *while *statement.
> The *break break* *break *statement jumps out of the third-nearest
> enclosing *do, for, switch, *or *while *statement.
> The *break break* *break break *statement jumps out of the
> fourth-nearest enclosing *do, for, switch, *or *while *statement.
>
> And so on. For instance:
>
> for (int i = 0 ; i < 10 ; i++)
> for (int j = 0 ; j < 10 ; j++)
> for (int k = 0 ; k < 10 ; k++) {
> // do stuff
> if (a[i][j][k] == 0) break break break ; // the same as "goto
> ContinueExecution ;"
> }
> ContinueExecution:
>
> Easy to understand. Easy to implement. 100% backwards compatible.
> What's not to like?
Serious question: If this is equivalent to 'goto ContinueExecution',
then why not just teach people to use goto? That has the advantage that
I don't have to be careful to figure out where 'break break break;' will
go, I can see the label!
Chris
--
---
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/?hl=en.
--------------020904000105000403000405
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 05/04/13 20:23, <a class="moz-txt-link-abbreviated" href="mailto:temptony@freemail.hu">temptony@freemail.hu</a>
wrote:<br>
</div>
<blockquote
cite="mid:1f964e4b-2762-43b8-85e5-41392926b07a@isocpp.org"
type="cite">I hesitate to suggest this simple enhancement to the
language, because it's so obvious that <i>somebody</i> must have
thought of it before. In which case there must have been a good
reason for rejecting it! But here goes:
<div>
<div><br>
</div>
<div><i>Problem</i></div>
<div>The <b>break</b> statement jumps out of the nearest
enclosing <b>do, for, switch, </b>or <b>while </b>statement.
All programmers know that breaking out of a nested for-loop to
the <i>second</i>-nearest enclosing <b>do, for, switch, </b>or <b>while </b>statement
is a pain, and requires a <b>goto</b> statement or worse.</div>
<div><br>
</div>
<div><i>Suggestion</i></div>
<div>I suggest the following syntax:</div>
<div><br>
</div>
<div>The <b>break break</b> statement jumps out of the
second-nearest enclosing <b>do, for, switch, </b>or <b>while </b>statement.<br>
</div>
<div>The <b>break break</b> <b>break </b>statement jumps out of
the third-nearest enclosing <b>do, for, switch, </b>or <b>while </b>statement.<br>
</div>
<div>The <b>break break</b> <b>break break </b>statement jumps
out of the fourth-nearest enclosing <b>do, for, switch, </b>or <b>while </b>statement.<br>
</div>
<div><br>
</div>
<div>And so on. For instance:</div>
<div><br>
</div>
<div>for (int i = 0 ; i < 10 ; i++)</div>
<div> for (int j = 0 ; j < 10 ; j++)</div>
<div> for (int k = 0 ; k < 10 ; k++) {<br>
</div>
<div> // do stuff</div>
<div> if (a[i][j][k] == 0) break break break ; // the same
as "goto ContinueExecution ;"</div>
<div> }</div>
<div>ContinueExecution:<br>
</div>
<div><br>
</div>
<div>Easy to understand. Easy to implement. 100% backwards
compatible. What's not to like?</div>
</div>
</blockquote>
<br>
Serious question: If this is equivalent to 'goto ContinueExecution',
then why not just teach people to use goto? That has the advantage
that I don't have to be careful to figure out where 'break break
break;' will go, I can see the label!<br>
<br>
Chris<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------020904000105000403000405--
.
Author: temptony@freemail.hu
Date: Sun, 7 Apr 2013 04:32:06 -0700 (PDT)
Raw View
------=_Part_3414_14335724.1365334326017
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, April 7, 2013 12:06:12 PM UTC+2, Chris Jefferson wrote:
Serious question: If this is equivalent to 'goto ContinueExecution', then
> why not just teach people to use goto? That has the advantage that I don't
> have to be careful to figure out where 'break break break;' will go, I can
> see the label!
>
> Chris
>
You could ask exactly the same question about the simple *break* statement,
which many programmers find very handy!
--
---
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/?hl=en.
------=_Part_3414_14335724.1365334326017
Content-Type: text/html; charset=ISO-8859-1
On Sunday, April 7, 2013 12:06:12 PM UTC+2, Chris Jefferson wrote:<div><br><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000">
<div>Serious question: If this is equivalent to 'goto ContinueExecution',
then why not just teach people to use goto? That has the advantage
that I don't have to be careful to figure out where 'break break
break;' will go, I can see the label!<br></div>
<br>
Chris<br></div></blockquote><div><br></div><div>You could ask exactly the same question about the simple *break* statement, which many programmers find very handy!</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
------=_Part_3414_14335724.1365334326017--
.
Author: Patrick Michael Niedzielski <patrickniedzielski@gmail.com>
Date: Sun, 07 Apr 2013 11:48:57 +0000
Raw View
On dim, 2013-04-07 at 04:32 -0700, temptony@freemail.hu wrote:
> On Sunday, April 7, 2013 12:06:12 PM UTC+2, Chris Jefferson wrote:
>
> Serious question: If this is equivalent to 'goto
> ContinueExecution', then why not just teach people to use
> goto? That has the advantage that I don't have to be careful
> to figure out where 'break break break;' will go, I can see
> the label!
>
>
> Chris
>
>
>
> You could ask exactly the same question about the simple *break*
> statement, which many programmers find very handy!
That's a red herring and/or is starting down a slippery slope. You
could ask the same thing about loops themselves (which can just as
easily be written with if statements and goto statements), function
calls (which set up the stack and then jump), or the else part of an if
statement (which are jumped to if the condition is false).
The difference between `break break ...' and the other examples is that
they are *extremely* common code patterns. While all of them encode
some sort of semantic information that the equivalent jump or goto would
lack, a `break break ...' statement would be used much, *much* less
frequently. I personally think this has diminishing returns. You want
a `goto' that only works in one place (which in and of itself is an okay
or good thing, like `break', `return', and `continue'), but that one
place is somewhere that won't be commonly encountered. While it would
be useful when it is encountered, it's not exactly a corner case, it
doesn't really provide much benefit.
Best,
Patrick Niedzielski
--
---
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/?hl=en.
.
Author: Chris Jefferson <chris@bubblescope.net>
Date: Sun, 07 Apr 2013 14:04:53 +0100
Raw View
This is a multi-part message in MIME format.
--------------090702050207060107040905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 07/04/13 12:32, temptony@freemail.hu wrote:
> On Sunday, April 7, 2013 12:06:12 PM UTC+2, Chris Jefferson wrote:
>
> Serious question: If this is equivalent to 'goto
> ContinueExecution', then why not just teach people to use goto?
> That has the advantage that I don't have to be careful to figure
> out where 'break break break;' will go, I can see the label!
>
> Chris
>
>
> You could ask exactly the same question about the simple *break*
> statement, which many programmers find very handy!
I would ask the same statement if someone was suggesting introducing the
'break' statement today, but they are not, and I certainly wouldn't
suggest breaking piles of code by taking it out.
As someone who teaches C and C++, I feel every new feature has to add
enough benefit to be worth the extra teaching load. Seeing as this
feature seems to be identical (as you say) to a goto, just avoiding
having to give the label, then I do not think personally the benefits
outweight the costs.
Chris
--
---
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/?hl=en.
--------------090702050207060107040905
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 07/04/13 12:32, <a class="moz-txt-link-abbreviated" href="mailto:temptony@freemail.hu">temptony@freemail.hu</a>
wrote:<br>
</div>
<blockquote
cite="mid:c053c353-90d7-4925-aee6-f1ea92eaa671@isocpp.org"
type="cite">On Sunday, April 7, 2013 12:06:12 PM UTC+2, Chris
Jefferson wrote:
<div><br>
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000">
<div>Serious question: If this is equivalent to 'goto
ContinueExecution', then why not just teach people to use
goto? That has the advantage that I don't have to be
careful to figure out where 'break break break;' will go,
I can see the label!<br>
</div>
<br>
Chris<br>
</div>
</blockquote>
<div><br>
</div>
<div>You could ask exactly the same question about the simple
*break* statement, which many programmers find very handy!</div>
</div>
</blockquote>
<br>
I would ask the same statement if someone was suggesting introducing
the 'break' statement today, but they are not, and I certainly
wouldn't suggest breaking piles of code by taking it out.<br>
<br>
As someone who teaches C and C++, I feel every new feature has to
add enough benefit to be worth the extra teaching load. Seeing as
this feature seems to be identical (as you say) to a goto, just
avoiding having to give the label, then I do not think personally
the benefits outweight the costs.<br>
<br>
Chris<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------090702050207060107040905--
.
Author: Martinho Fernandes <martinho.fernandes@gmail.com>
Date: Sun, 07 Apr 2013 20:34:42 +0200
Raw View
On 07.04.2013 13:48, Patrick Michael Niedzielski wrote:
> The difference between `break break ...' and the other examples is=20
> that they are *extremely* common code patterns. While all of them=20
> encode some sort of semantic information that the equivalent jump or=20
> goto would lack, a `break break ...' statement would be used much,=20
> *much* less frequently. I personally think this has diminishing=20
> returns. You want a `goto' that only works in one place (which in and=20
> of itself is an okay or good thing, like `break', `return', and=20
> `continue'), but that one place is somewhere that won't be commonly=20
> encountered. While it would be useful when it is encountered, it's not=20
> exactly a corner case, it doesn't really provide much benefit. Best,=20
> Patrick Niedzielski=20
And more often than not, this "break break" thing only feels necessary=20
when you eschew using algorithms, or when you are lacking the proper=20
iterators. IMO if there is a looping pattern you are repeating over and=20
over, you should put it in an algorithm and call it a day. That is more=20
flexible than new syntax, less verbose, and clearer (because you named=20
your algorithm well, right?).
--=20
Mit freundlichen Gr=FC=DFen,
Martinho Fernandes
--=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/?hl=3Den.
.
Author: Benjamin Lindley <benjameslindley@gmail.com>
Date: Sun, 7 Apr 2013 11:40:04 -0700 (PDT)
Raw View
------=_Part_2210_722238.1365360004986
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, April 7, 2013 5:06:12 AM UTC-5, Chris Jefferson wrote:
>
> On 05/04/13 20:23, temp...@freemail.hu <javascript:> wrote:
>
> I hesitate to suggest this simple enhancement to the language, because
> it's so obvious that *somebody* must have thought of it before. In which
> case there must have been a good reason for rejecting it! But here goes:
>
> *Problem*
> The *break* statement jumps out of the nearest enclosing *do, for,
> switch, *or *while *statement. All programmers know that breaking out of
> a nested for-loop to the *second*-nearest enclosing *do, for, switch, *or
> *while *statement is a pain, and requires a *goto* statement or worse.
>
> *Suggestion*
> I suggest the following syntax:
>
> The *break break* statement jumps out of the second-nearest enclosing *do,
> for, switch, *or *while *statement.
> The *break break* *break *statement jumps out of the third-nearest
> enclosing *do, for, switch, *or *while *statement.
> The *break break* *break break *statement jumps out of the
> fourth-nearest enclosing *do, for, switch, *or *while *statement.
>
> And so on. For instance:
>
> for (int i = 0 ; i < 10 ; i++)
> for (int j = 0 ; j < 10 ; j++)
> for (int k = 0 ; k < 10 ; k++) {
> // do stuff
> if (a[i][j][k] == 0) break break break ; // the same as "goto
> ContinueExecution ;"
> }
> ContinueExecution:
>
> Easy to understand. Easy to implement. 100% backwards compatible. What's
> not to like?
>
>
> Serious question: If this is equivalent to 'goto ContinueExecution', then
> why not just teach people to use goto? That has the advantage that I don't
> have to be careful to figure out where 'break break break;' will go, I can
> see the label!
>
> Chris
>
It's only equivalent if the label ContinueExecution is actually there.
With the goto, you can't be sure where it's actually going to until you
actually find that label. That could be up or down any distance within the
function. With "break break;", you know exactly where to look. Down to the
end of the loop, and then down to the end of the next one. Doesn't seem
that hard to me.
--
---
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/?hl=en.
------=_Part_2210_722238.1365360004986
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sunday, April 7, 2013 5:06:12 AM UTC-5, Chris Jefferson wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>On 05/04/13 20:23, <a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"mQMdeiDu2aEJ">temp...@freemail.hu</a>
wrote:<br>
</div>
<blockquote type=3D"cite">I hesitate to suggest this simple enhancement=
to the
language, because it's so obvious that <i>somebody</i> must have
thought of it before. In which case there must have been a good
reason for rejecting it! But here goes:
<div>
<div><br>
</div>
<div><i>Problem</i></div>
<div>The <b>break</b> statement jumps out of the nearest
enclosing <b>do, for, switch, </b>or <b>while </b>statement.
All programmers know that breaking out of a nested for-loop to
the <i>second</i>-nearest enclosing <b>do, for, switch, =
;</b>or <b>while </b>statement
is a pain, and requires a <b>goto</b> statement or worse.</d=
iv>
<div><br>
</div>
<div><i>Suggestion</i></div>
<div>I suggest the following syntax:</div>
<div><br>
</div>
<div>The <b>break break</b> statement jumps out of the
second-nearest enclosing <b>do, for, switch, </b>or&nbs=
p;<b>while </b>statement.<br>
</div>
<div>The <b>break break</b> <b>break </b>statem=
en<wbr>t jumps out of
the third-nearest enclosing <b>do, for, switch, </b>or&=
nbsp;<b>while </b>statement.<br>
</div>
<div>The <b>break break</b> <b>break break </b>=
statement jumps
out of the fourth-nearest enclosing <b>do, for, switch, =
;</b>or <b>while </b>statement.<br>
</div>
<div><br>
</div>
<div>And so on. For instance:</div>
<div><br>
</div>
<div>for (int i =3D 0 ; i < 10 ; i++)</div>
<div> for (int j =3D 0 ; j < 10 ; j++)</div>
<div> for (int k =3D 0 ; k < 10 ; k++) {<br>
</div>
<div> // do stuff</div>
<div> if (a[i][j][k] =3D=3D 0) break break brea=
k ; // the same
as "goto ContinueExecution ;"</div>
<div> }</div>
<div>ContinueExecution:<br>
</div>
<div><br>
</div>
<div>Easy to understand. Easy to implement. 100% backwards
compatible. What's not to like?</div>
</div>
</blockquote>
<br>
Serious question: If this is equivalent to 'goto ContinueExecution',
then why not just teach people to use goto? That has the advantage
that I don't have to be careful to figure out where 'break break
break;' will go, I can see the label!<br>
<br>
Chris<br></div></blockquote><div> <br>It's only equivalent if the =
label ContinueExecution is actually there. With the goto, you can't b=
e sure where it's actually going to until you actually find that label.&nbs=
p; That could be up or down any distance within the function. With "b=
reak break;", you know exactly where to look. Down to the end of the loop, =
and then down to the end of the next one. Doesn't seem that hard to m=
e.<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2210_722238.1365360004986--
.
Author: Vlad from Moscow <vlad.moscow@mail.ru>
Date: Sun, 7 Apr 2013 12:47:10 -0700 (PDT)
Raw View
------=_Part_927_23670915.1365364030402
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, April 7, 2013 10:40:04 PM UTC+4, Benjamin Lindley wrote:
>
> On Sunday, April 7, 2013 5:06:12 AM UTC-5, Chris Jefferson wrote:
>>
>> On 05/04/13 20:23, temp...@freemail.hu wrote:
>>
>> I hesitate to suggest this simple enhancement to the language, because
>> it's so obvious that *somebody* must have thought of it before. In which
>> case there must have been a good reason for rejecting it! But here goes:
>>
>> *Problem*
>> The *break* statement jumps out of the nearest enclosing *do, for,
>> switch, *or *while *statement. All programmers know that breaking out of
>> a nested for-loop to the *second*-nearest enclosing *do, for, switch, *
>> or *while *statement is a pain, and requires a *goto* statement or worse.
>>
>> *Suggestion*
>> I suggest the following syntax:
>>
>> The *break break* statement jumps out of the second-nearest enclosing *do,
>> for, switch, *or *while *statement.
>> The *break break* *break *statement jumps out of the third-nearest
>> enclosing *do, for, switch, *or *while *statement.
>> The *break break* *break break *statement jumps out of the
>> fourth-nearest enclosing *do, for, switch, *or *while *statement.
>>
>> And so on. For instance:
>>
>> for (int i = 0 ; i < 10 ; i++)
>> for (int j = 0 ; j < 10 ; j++)
>> for (int k = 0 ; k < 10 ; k++) {
>> // do stuff
>> if (a[i][j][k] == 0) break break break ; // the same as "goto
>> ContinueExecution ;"
>> }
>> ContinueExecution:
>>
>> Easy to understand. Easy to implement. 100% backwards compatible.
>> What's not to like?
>>
>>
>> Serious question: If this is equivalent to 'goto ContinueExecution', then
>> why not just teach people to use goto? That has the advantage that I don't
>> have to be careful to figure out where 'break break break;' will go, I can
>> see the label!
>>
>> Chris
>>
>
> It's only equivalent if the label ContinueExecution is actually there.
> With the goto, you can't be sure where it's actually going to until you
> actually find that label. That could be up or down any distance within the
> function. With "break break;", you know exactly where to look. Down to the
> end of the loop, and then down to the end of the next one. Doesn't seem
> that hard to me.
>
In my opinion break break is even worst then the goto statement. Using
break break you should be very cautious counting loops and finding them. If
due to refactoring some internal loop will be deleted break break passes
the control in the invalid place. If I use the goto statement I will know
at least where the control will be passed even if loops will be
rearranged.:)
So I am against such a proposal.
--
---
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/?hl=en.
------=_Part_927_23670915.1365364030402
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br>On Sunday, April 7, 2013 10:40:04 PM UTC+4, Benjamin Lindley wrote:<blo=
ckquote 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=
;" class=3D"gmail_quote">On Sunday, April 7, 2013 5:06:12 AM UTC-5, Chris J=
efferson wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;" class=3D"gmail_quote">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div>On 05/04/13 20:23, <a>temp...@freemail.hu</a>
wrote:<br>
</div>
<blockquote type=3D"cite">I hesitate to suggest this simple enhancement=
to the
language, because it's so obvious that <i>somebody</i> must have
thought of it before. In which case there must have been a good
reason for rejecting it! But here goes:
<div>
<div><br>
</div>
<div><i>Problem</i></div>
<div>The <b>break</b> statement jumps out of the nearest
enclosing <b>do, for, switch, </b>or <b>while </b>statement.
All programmers know that breaking out of a nested for-loop to
the <i>second</i>-nearest enclosing <b>do, for, switch, =
;</b>or <b>while </b>statement
is a pain, and requires a <b>goto</b> statement or worse.</d=
iv>
<div><br>
</div>
<div><i>Suggestion</i></div>
<div>I suggest the following syntax:</div>
<div><br>
</div>
<div>The <b>break break</b> statement jumps out of the
second-nearest enclosing <b>do, for, switch, </b>or&nbs=
p;<b>while </b>statement.<br>
</div>
<div>The <b>break break</b> <b>break </b>statem=
en<wbr>t jumps out of
the third-nearest enclosing <b>do, for, switch, </b>or&=
nbsp;<b>while </b>statement.<br>
</div>
<div>The <b>break break</b> <b>break break </b>=
statement jumps
out of the fourth-nearest enclosing <b>do, for, switch, =
;</b>or <b>while </b>statement.<br>
</div>
<div><br>
</div>
<div>And so on. For instance:</div>
<div><br>
</div>
<div>for (int i =3D 0 ; i < 10 ; i++)</div>
<div> for (int j =3D 0 ; j < 10 ; j++)</div>
<div> for (int k =3D 0 ; k < 10 ; k++) {<br>
</div>
<div> // do stuff</div>
<div> if (a[i][j][k] =3D=3D 0) break break brea=
k ; // the same
as "goto ContinueExecution ;"</div>
<div> }</div>
<div>ContinueExecution:<br>
</div>
<div><br>
</div>
<div>Easy to understand. Easy to implement. 100% backwards
compatible. What's not to like?</div>
</div>
</blockquote>
<br>
Serious question: If this is equivalent to 'goto ContinueExecution',
then why not just teach people to use goto? That has the advantage
that I don't have to be careful to figure out where 'break break
break;' will go, I can see the label!<br>
<br>
Chris<br></div></blockquote><div> <br>It's only equivalent if the =
label ContinueExecution is actually there. With the goto, you can't b=
e sure where it's actually going to until you actually find that label.&nbs=
p; That could be up or down any distance within the function. With "b=
reak break;", you know exactly where to look. Down to the end of the loop, =
and then down to the end of the next one. Doesn't seem that hard to m=
e.<br></div></blockquote><div> </div><div> </div><div>In my =
opinion break break is even worst then the goto statement. Using break=
break you should be very cautious counting loops and finding the=
m. If due to refactoring some internal loop will be deleted break break pas=
ses the control in the invalid place. If I use the goto statement=
I will know at least where the control will be passed even if loops w=
ill be rearranged.:)</div><div> </div><div>So I am against such a prop=
osal. </div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_927_23670915.1365364030402--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 7 Apr 2013 19:06:38 -0700 (PDT)
Raw View
------=_Part_3930_3918084.1365386798374
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, April 7, 2013 11:40:04 AM UTC-7, Benjamin Lindley wrote:
>
> On Sunday, April 7, 2013 5:06:12 AM UTC-5, Chris Jefferson wrote:
>>
>> On 05/04/13 20:23, temp...@freemail.hu wrote:
>>
>> I hesitate to suggest this simple enhancement to the language, because
>> it's so obvious that *somebody* must have thought of it before. In which
>> case there must have been a good reason for rejecting it! But here goes:
>>
>> *Problem*
>> The *break* statement jumps out of the nearest enclosing *do, for,
>> switch, *or *while *statement. All programmers know that breaking out of
>> a nested for-loop to the *second*-nearest enclosing *do, for, switch, *
>> or *while *statement is a pain, and requires a *goto* statement or worse.
>>
>> *Suggestion*
>> I suggest the following syntax:
>>
>> The *break break* statement jumps out of the second-nearest enclosing *do,
>> for, switch, *or *while *statement.
>> The *break break* *break *statement jumps out of the third-nearest
>> enclosing *do, for, switch, *or *while *statement.
>> The *break break* *break break *statement jumps out of the
>> fourth-nearest enclosing *do, for, switch, *or *while *statement.
>>
>> And so on. For instance:
>>
>> for (int i = 0 ; i < 10 ; i++)
>> for (int j = 0 ; j < 10 ; j++)
>> for (int k = 0 ; k < 10 ; k++) {
>> // do stuff
>> if (a[i][j][k] == 0) break break break ; // the same as "goto
>> ContinueExecution ;"
>> }
>> ContinueExecution:
>>
>> Easy to understand. Easy to implement. 100% backwards compatible.
>> What's not to like?
>>
>>
>> Serious question: If this is equivalent to 'goto ContinueExecution', then
>> why not just teach people to use goto? That has the advantage that I don't
>> have to be careful to figure out where 'break break break;' will go, I can
>> see the label!
>>
>> Chris
>>
>
> It's only equivalent if the label ContinueExecution is actually there.
> With the goto, you can't be sure where it's actually going to until you
> actually find that label. That could be up or down any distance within the
> function. With "break break;", you know exactly where to look. Down to the
> end of the loop, and then down to the end of the next one. Doesn't seem
> that hard to me.
>
I'm with everyone else; we shouldn't add syntax that encourages people to
write such loops. They should be sufficiently exceptional circumstances in
your code that people should have to use exceptional syntax (ie: gotos) to
do it.
--
---
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/?hl=en.
------=_Part_3930_3918084.1365386798374
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sunday, April 7, 2013 11:40:04 AM UTC-7, Benjamin Lindley wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">On Sunday, April 7, 2013 5:06:12 AM UT=
C-5, Chris Jefferson wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>On 05/04/13 20:23, <a>temp...@freemail.hu</a>
wrote:<br>
</div>
<blockquote type=3D"cite">I hesitate to suggest this simple enhancement=
to the
language, because it's so obvious that <i>somebody</i> must have
thought of it before. In which case there must have been a good
reason for rejecting it! But here goes:
<div>
<div><br>
</div>
<div><i>Problem</i></div>
<div>The <b>break</b> statement jumps out of the nearest
enclosing <b>do, for, switch, </b>or <b>while </b>statement.
All programmers know that breaking out of a nested for-loop to
the <i>second</i>-nearest enclosing <b>do, for, switch, =
;</b>or <b>while </b>statement
is a pain, and requires a <b>goto</b> statement or worse.</d=
iv>
<div><br>
</div>
<div><i>Suggestion</i></div>
<div>I suggest the following syntax:</div>
<div><br>
</div>
<div>The <b>break break</b> statement jumps out of the
second-nearest enclosing <b>do, for, switch, </b>or&nbs=
p;<b>while </b>statement.<br>
</div>
<div>The <b>break break</b> <b>break </b>statem=
en<wbr>t jumps out of
the third-nearest enclosing <b>do, for, switch, </b>or&=
nbsp;<b>while </b>statement.<br>
</div>
<div>The <b>break break</b> <b>break break </b>=
statement jumps
out of the fourth-nearest enclosing <b>do, for, switch, =
;</b>or <b>while </b>statement.<br>
</div>
<div><br>
</div>
<div>And so on. For instance:</div>
<div><br>
</div>
<div>for (int i =3D 0 ; i < 10 ; i++)</div>
<div> for (int j =3D 0 ; j < 10 ; j++)</div>
<div> for (int k =3D 0 ; k < 10 ; k++) {<br>
</div>
<div> // do stuff</div>
<div> if (a[i][j][k] =3D=3D 0) break break brea=
k ; // the same
as "goto ContinueExecution ;"</div>
<div> }</div>
<div>ContinueExecution:<br>
</div>
<div><br>
</div>
<div>Easy to understand. Easy to implement. 100% backwards
compatible. What's not to like?</div>
</div>
</blockquote>
<br>
Serious question: If this is equivalent to 'goto ContinueExecution',
then why not just teach people to use goto? That has the advantage
that I don't have to be careful to figure out where 'break break
break;' will go, I can see the label!<br>
<br>
Chris<br></div></blockquote><div> <br>It's only equivalent if the =
label ContinueExecution is actually there. With the goto, you can't b=
e sure where it's actually going to until you actually find that label.&nbs=
p; That could be up or down any distance within the function. With "b=
reak break;", you know exactly where to look. Down to the end of the loop, =
and then down to the end of the next one. Doesn't seem that hard to m=
e.<br></div></blockquote><div><br>I'm with everyone else; we shouldn't add =
syntax that encourages people to write such loops. They should be sufficien=
tly exceptional circumstances in your code that people should have to use e=
xceptional syntax (ie: gotos) to do it. <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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_3930_3918084.1365386798374--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 8 Apr 2013 15:24:15 -0400
Raw View
--001a11c34d9aec3b5e04d9de6193
Content-Type: text/plain; charset=ISO-8859-1
> label: for (;;)
> > {
> > break label;
> > }
> >
> >
> > And all that is not saying I agree with any of it, or really want it;
> just some suggestions.
>
> I think I would prefer
>
> for outer (...) {
> for (...) {
> if (...)
> break outer;
> }
> }
>
> Using a label to refer to its labeled statement feels like an abuse of the
> facility to me.
>
You would think that using a label to refer to the statement it labels
would make complete sense :-), but I actually completely agree with you (I
suspect the C++ term 'label' has lost much of its similarity with the
actual English word over the years); and I would prefer your style (if we
were to ever do something like this).
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--001a11c34d9aec3b5e04d9de6193
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> label: for (;;)<br><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
class=3D"">
<div class=3D"h5"><p dir=3D"ltr">
> {<br>
> =A0=A0 break label;<br>
> }<br>
><br>
><br>
> And all that is not saying I agree with any of it, or really want it; =
just some suggestions.</p>
</div></div><p dir=3D"ltr">I think I would prefer </p>
<p dir=3D"ltr">for outer (...) {<br>
=A0 for (...) {<br>
=A0=A0=A0 if (...)<br>
=A0=A0=A0=A0=A0 break outer;<br>
=A0 }<br>
}</p>
<p dir=3D"ltr">Using a label to refer to its labeled statement feels like a=
n abuse of the facility to me.</p></blockquote><div><br></div><div>You woul=
d think that using a label to refer to the statement it labels would make c=
omplete sense :-), but I actually completely agree with you (I suspect the=
C++ term 'label' has lost much of its similarity with the actual E=
nglish word over the years);=A0 and I would prefer your style (if we were t=
o ever do something like this).<br>
</div><br></div>Tony<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--001a11c34d9aec3b5e04d9de6193--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 8 Apr 2013 15:32:27 -0400
Raw View
--001a11c34d9a3a930904d9de7f19
Content-Type: text/plain; charset=ISO-8859-1
On Sat, Apr 6, 2013 at 3:37 PM, <temptony@freemail.hu> wrote:
> On Saturday, April 6, 2013 9:32:05 PM UTC+2, Richard Smith wrote:
>
> I think I would prefer
>>
>> for outer (...) {
>> for (...) {
>> if (...)
>> break outer;
>> }
>> }
>>
>> Using a label to refer to its labeled statement feels like an abuse of
>> the facility to me.
>>
>
> Please, can we leave labels and other identifiers out of this? You don't
> have to support my proposal, but I wish you wouldn't all try to distort it
> like this. You can submit your own proposals, after all.
>
>
The purpose of this email list is, I think, to discuss proposals and
"pre-proposals" (ideas). Both here, and in actual committee meetings, I
think you should *expect* to get not just like/dislike but alternative
suggestions.
Also, note that many of the people commenting here are the same people that
would vote for/against your proposal in the committee.
In general, you should be prepared to modify/compromise your proposal if
you wish to get it (or at least its essence) accepted.
I agree you are absolutely free to submit a formal proposal of whatever you
think is best, as could someone else. But I would try to listen to and
consider the suggestions given.
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--001a11c34d9a3a930904d9de7f19
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sat, Apr 6, 2013 at 3:37 PM, <span dir=3D"ltr"><<a href=3D"m=
ailto:temptony@freemail.hu" target=3D"_blank">temptony@freemail.hu</a>><=
/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"im"><div>On Saturday, April 6,=
2013 9:32:05 PM UTC+2, Richard Smith wrote:<br></div><div><br></div><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">I think I would prefer<br></p>
<p dir=3D"ltr">for outer (...) {<br>
=A0 for (...) {<br>
=A0=A0=A0 if (...)<br>
=A0=A0=A0=A0=A0 break outer;<br>
=A0 }<br>
}</p>
<p dir=3D"ltr">Using a label to refer to its labeled statement feels like a=
n abuse of the facility to me.</p></blockquote><div>=A0</div></div><div>Ple=
ase, can we leave labels and other identifiers out of this? You don't h=
ave to support my proposal, but I wish you wouldn't all try to distort =
it like this. You can submit your own proposals, after all.</div>
<div class=3D"HOEnZb"><div class=3D"h5">
<br></div></div></blockquote><div><br></div><div>The purpose of this email =
list is, I think, to discuss proposals and "pre-proposals" (ideas=
).=A0 Both here, and in actual committee meetings, I think you should *expe=
ct* to get not just like/dislike but alternative suggestions.=A0 <br>
<br></div><div>Also, note that many of the people commenting here are the s=
ame people that would vote for/against your proposal in the committee.<br><=
br></div><div>In general, you should be prepared to modify/compromise your =
proposal if you wish to get it (or at least its essence) accepted.<br>
<br></div><div>I agree you are absolutely free to submit a formal proposal =
of whatever you think is best, as could someone else.=A0 But I would try to=
listen to and consider the suggestions given.<br><br>Tony<br></div></div>
<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--001a11c34d9a3a930904d9de7f19--
.