Topic: Control flow with named statements/blocks
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Mon, 08 Apr 2013 23:21:17 +0200
Raw View
This is a multi-part message in MIME format.
--------------090805030808010907050601
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I would like to present an alternative to the break break ... proposal
based on the restart/leave of the Beta language. The alternative takes
in account *break* and *continue* on nesting iteration statements.
*Motivation*
Exiting from an iteration statement that contains another iteration
statement or and switch statement needs to use an auxiliary label and a
goto
while(cnd1)
{
while(cnd2)
{
if (cnd3)
goto while_1; // leave first while
}
//...
}
while_1:
while(cnd1)
{
switch(cnd2)
{
case a:
goto while_1; // don't use break to leave while
// ...
}
//...
}
while_1:
or an auxiliary variable if we want to preserve the well know
'structured programming'
while(cnd1)
{
bool must_leave_1 = false;
while(cnd2)
{
if (cnd3) {
must_leave_1 = true; break;
}
// ...
}
if (must_leave_1) break;
//...
} while_1:
while(cnd1)
{
bool must_leave_1 = false;
switch(cnd2)
{
case a:
must_leave_1 = true; break;
// ...
}
if (must_leave_1) break;
//...
} while_1:
The same occurs when continuing an external loop including an internal
loop.
while(cnd1)
{
while(cnd2)
{
if (cnd4)
goto continue_1; // continue first while
}
//...
continue_1:
} break_1:
In the general case we need either two variables or two labels.
while(cnd1)
{
while(cnd2)
{
if (cnd3)
goto break_1; // leave first while
if (cnd4)
goto continue_1; // continue first while
}
//...
continue_1:
}
break_1:
Using auxiliary variables is cumbersome and adding the auxiliary labels
introduce too much opportunities for escaping the structured programming
paradigm.
*One possible ***structured *solution**
*
/labeled iteration statements//
/
An alternative used by the language Beta is to name the statements so
that we can either leave the named statement or continue it iteration
using named break and named continue statements as in
L:: while(cnd1)
{
while(cnd2)
{
if (cnd3)
break L;
if (cnd4)
continue L;
}
//...
}
Are goto allowed on this kind of labels?
I don't think this is neither needed nor desirable.
/labeled blocks/
Having labeled iteration statements and switch statements but not
labeled blocks could seem counter-intuitive.
The user could be tempted to do artificial things like
L:: do {
// ...
if (cnd) break L;
// ...
} while(false);
while the following seams more natural
L::
{
// ...
if (cnd) break L;
// ...
}
The main advantages respect to a label/goto solution are:
* this labels can be used only inside the named statement/block
preserving the structure of the code and
* no need to duplicate the label in case break and continue are needed,
only one label is enough.
Best,
Vicente
--
---
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.
--------------090805030808010907050601
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
I would like to present an alternative to the break break ...
proposal based on the restart/leave of the Beta language. The
alternative takes in account <b>break</b> and <b>continue</b> on
nesting iteration statements.<br>
<br>
<b> Motivation</b><br>
<br>
Exiting from an iteration statement that contains another iteration
statement or and switch statement needs to use an auxiliary label
and a goto <br>
<br>
<br>
while(cnd1) <br>
{<br>
while(cnd2)<br>
{<br>
if (cnd3) <br>
goto while_1; // leave first while<br>
}<br>
//...<br>
} <br>
while_1:<br>
<br>
while(cnd1) <br>
{<br>
switch(cnd2)<br>
{<br>
case a: <br>
goto while_1; // don't use break to leave while<br>
// ...<br>
}<br>
//...<br>
} <br>
while_1:<br>
<br>
or an auxiliary variable if we want to preserve the well know
'structured programming'<br>
<br>
while(cnd1) <br>
{<br>
bool must_leave_1 = false;<br>
while(cnd2)<br>
{<br>
if (cnd3) {<br>
must_leave_1 = true; break; <br>
}<br>
// ...<br>
}<br>
if (must_leave_1) break;<br>
//...<br>
} while_1:<br>
<br>
<br>
while(cnd1) <br>
{<br>
bool must_leave_1 = false;<br>
switch(cnd2)<br>
{<br>
case a: <br>
must_leave_1 = true; break; <br>
// ...<br>
}<br>
if (must_leave_1) break;<br>
//...<br>
} while_1:<br>
<br>
The same occurs when continuing an external loop including an
internal loop. <br>
<br>
while(cnd1) <br>
{<br>
while(cnd2)<br>
{<br>
if (cnd4) <br>
goto continue_1; // continue first while<br>
}<br>
//...<br>
continue_1:<br>
} break_1:<br>
<br>
In the general case we need either two variables or two labels.<br>
<br>
while(cnd1) <br>
{<br>
while(cnd2)<br>
{<br>
if (cnd3) <br>
goto break_1; // leave first while<br>
if (cnd4) <br>
goto continue_1; // continue first while<br>
}<br>
//...<br>
continue_1:<br>
} <br>
break_1:<br>
<br>
<br>
Using auxiliary variables is cumbersome and adding the auxiliary
labels introduce too much opportunities for escaping the structured
programming paradigm.<br>
<br>
<b>One possible </b><b><b>structured </b>solution</b><b><br>
</b><br>
<i>labeled iteration statements</i><i><br>
</i><br>
An alternative used by the language Beta is to name the statements
so that we can either leave the named statement or continue it
iteration using named break and named continue statements as in <br>
<br>
L:: while(cnd1) <br>
{<br>
while(cnd2)<br>
{<br>
if (cnd3) <br>
break L;<br>
if (cnd4) <br>
continue L;<br>
}<br>
//...<br>
} <br>
<br>
Are goto allowed on this kind of labels?<br>
I don't think this is neither needed nor desirable.<br>
<br>
<br>
<i> labeled blocks</i><br>
<br>
Having labeled iteration statements and switch statements but not
labeled blocks could seem counter-intuitive.<br>
<br>
The user could be tempted to do artificial things like<br>
<br>
L:: do {<br>
// ...<br>
if (cnd) break L;<br>
// ...<br>
} while(false);<br>
<br>
while the following seams more natural<br>
<br>
L:: <br>
{<br>
// ...<br>
if (cnd) break L;<br>
// ...<br>
} <br>
<br>
<br>
The main advantages respect to a label/goto solution are:<br>
<br>
* this labels can be used only inside the named statement/block
preserving the structure of the code and<br>
* no need to duplicate the label in case break and continue are
needed, only one label is enough.<br>
<br>
<br>
<br>
Best,<br>
Vicente<br>
<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 />
--------------090805030808010907050601--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 8 Apr 2013 20:30:48 -0700 (PDT)
Raw View
------=_Part_59_31507059.1365478249176
Content-Type: text/plain; charset=ISO-8859-1
On Monday, April 8, 2013 2:21:17 PM UTC-7, Vicente J. Botet Escriba wrote:
>
> Using auxiliary variables is cumbersome and adding the auxiliary labels
> introduce too much opportunities for escaping the structured programming
> paradigm.
>
But you *already* escaped structured programming by wanting to do this at
all. You're wanting to jump to a rather arbitrary location, a location that
is not immediately obvious given your current code location. So I don't see
the problem. Labeling the loop statements isn't that much better than
current labeled gotos.
`break` and `continue` are structured concessions to certain special cased
needs. `goto` is an exception handler; you use it when nothing else will be
cleaner. The "cumbersome" nature of the solution should be a continued
reminder to avoid doing this wherever possible. We shouldn't make it more
convenient.
I don't think that the problem outlined here needs a solution. You should
avoid writing such code and loops to begin with. Yes, sometimes there's no
cleaner way to write some code. But it should not be *often* when this
happens. Not often enough that it needs language-level 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_59_31507059.1365478249176
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Monday, April 8, 2013 2:21:17 PM UTC-7, Vicente J. Botet Escriba wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
=20
Using auxiliary variables is cumbersome and adding the auxiliary
labels introduce too much opportunities for escaping the structured
programming paradigm.<br></div></blockquote><div><br>But you <i>already=
</i> escaped structured programming by wanting to do this at all. You're wa=
nting to jump to a rather arbitrary location, a location that is not immedi=
ately obvious given your current code location. So I don't see the problem.=
Labeling the loop statements isn't that much better than current labeled g=
otos.<br><br>`break` and `continue` are structured concessions to certain s=
pecial cased needs. `goto` is an exception handler; you use it when nothing=
else will be cleaner. The "cumbersome" nature of the solution should be a =
continued reminder=20
to avoid doing this wherever possible. We shouldn't make it more=20
convenient.</div><br>I don't think that the problem outlined here needs a s=
olution. You should avoid writing such code and loops to begin with. Yes, s=
ometimes there's no cleaner way to write some code. But it should not be <i=
>often</i> when this happens. Not often enough that it needs language-level=
support.<br><br><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_59_31507059.1365478249176--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 09 Apr 2013 18:24:31 +0200
Raw View
This is a multi-part message in MIME format.
--------------090204040901020400090507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 09/04/13 05:30, Nicol Bolas a =E9crit :
> On Monday, April 8, 2013 2:21:17 PM UTC-7, Vicente J. Botet Escriba=20
> wrote:
>
> Using auxiliary variables is cumbersome and adding the auxiliary
> labels introduce too much opportunities for escaping the
> structured programming paradigm.
>
>
> But you /already/ escaped structured programming by wanting to do this=20
> at all. You're wanting to jump to a rather arbitrary location, a=20
> location that is not immediately obvious given your current code=20
> location. So I don't see the problem. Labeling the loop statements=20
> isn't that much better than current labeled gotos.
>
There is a clear difference, these labels are not usable via gotos, so=20
jumping to them is controlled and structured as break and continue are,=20
which IMO is better.
> `break` and `continue` are structured concessions to certain special=20
> cased needs. `goto` is an exception handler; you use it when nothing=20
> else will be cleaner. The "cumbersome" nature of the solution should=20
> be a continued reminder to avoid doing this wherever possible. We=20
> shouldn't make it more convenient.
>
Could you show how you could code the examples of the original post with=20
structured programming?
> I don't think that the problem outlined here needs a solution. You=20
> should avoid writing such code and loops to begin with. Yes, sometimes=20
> there's no cleaner way to write some code. But it should not be=20
> /often/ when this happens. Not often enough that it needs=20
> language-level support.
>
I know some of you could think this doesn't goes towards structures=20
programming, but IMO it is more structured than using labels and gotos.=20
return provides already something like that, jumping to a know location=20
but unaccessible via goto label.
I'll not discus if it is worth or not modifying the language to take=20
care of this. Anyhow this alternative seems better to me than the break=20
break break; proposal. So if a change is made to the standard I would=20
prefer this alternative.
Vicente
--=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.
--------------090204040901020400090507
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">Le 09/04/13 05:30, Nicol Bolas a
écrit :<br>
</div>
<blockquote
cite="mid:18c38737-88a0-4694-8770-f9f62b67abb1@isocpp.org"
type="cite">On Monday, April 8, 2013 2:21:17 PM UTC-7, Vicente J.
Botet Escriba wrote:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000"> Using auxiliary variables
is cumbersome and adding the auxiliary labels introduce too
much opportunities for escaping the structured programming
paradigm.<br>
</div>
</blockquote>
<div><br>
But you <i>already</i> escaped structured programming by
wanting to do this at all. You're wanting to jump to a rather
arbitrary location, a location that is not immediately obvious
given your current code location. So I don't see the problem.
Labeling the loop statements isn't that much better than current
labeled gotos.<br>
<br>
</div>
</blockquote>
There is a clear difference, these labels are not usable via gotos,
so jumping to them is controlled and structured as break and
continue are, which IMO is better.<br>
<blockquote
cite="mid:18c38737-88a0-4694-8770-f9f62b67abb1@isocpp.org"
type="cite">
<div>`break` and `continue` are structured concessions to certain
special cased needs. `goto` is an exception handler; you use it
when nothing else will be cleaner. The "cumbersome" nature of
the solution should be a continued reminder to avoid doing this
wherever possible. We shouldn't make it more convenient.</div>
<br>
</blockquote>
Could you show how you could code the examples of the original post
with structured programming?<br>
<blockquote
cite="mid:18c38737-88a0-4694-8770-f9f62b67abb1@isocpp.org"
type="cite">I don't think that the problem outlined here needs a
solution. You should avoid writing such code and loops to begin
with. Yes, sometimes there's no cleaner way to write some code.
But it should not be <i>often</i> when this happens. Not often
enough that it needs language-level support.<br>
<br>
</blockquote>
I know some of you could think this doesn't goes towards structures
programming, but IMO it is more structured than using labels and
gotos. return provides already something like that, jumping to a
know location but unaccessible via goto label. <br>
<br>
I'll not discus if it is worth or not modifying the language to take
care of this. Anyhow this alternative seems better to me than the
break break break; proposal. So if a change is made to the standard
I would prefer this alternative.<br>
<br>
Vicente<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 />
--------------090204040901020400090507--
.
Author: rich.h.delaney@gmail.com
Date: Mon, 21 Apr 2014 18:18:26 -0700 (PDT)
Raw View
------=_Part_5833_1692538.1398129506559
Content-Type: text/plain; charset=UTF-8
The same thought occurred to me some time ago. I really want this in the
language. It feels more right and natural than double-breaks, gotos, and
flags. This is a way to say what you really want to say in C++, "I want to
break out of loop A," "I want to continue loop B." The language doesn't
allow us to do this as of now. Furthermore this is really great if you
decide to add another loop around the break/continue, in which case you
have less code to change or to have produce unexpected results. Honestly I
think every break or continue should have a loop name attached to it as a
point of coding style, and some loops that don't even have breaks/continues
could be more self documenting if they had a name that says what the loop
does, much like any other name says what that construct does. Another
advantage of this over gotos is that you can trigger for-loop update code
in an outer loop using continue, something you couldn't do with gotos
(without changing the for loop to a while loop that is).
Generalizing this to be able to name any scope is not something I had
thought of, but it's a great idea and this also seems like the right thing
to do to me. As far as the syntax, I had had something more like this in
mind:
while L(cnd1)
{
while(cnd2)
{
if (cnd3)
break L;
if (cnd4)
continue L;
}
//...
}
Here's another idea for the syntax: C++11 introduced the syntax "enum
class" for strongly typed enums with scoped enum values. Here, an existing
language construct was extended to have additional scoping by adding the
class keyword in front of it. So another way to go about the syntax for
named loops would be to follow suit:
while class L(cnd1)
{
while(cnd2)
{
if (cnd3)
break L;
if (cnd4)
continue L;
}
//...
}
However this sort of syntax will break if we want to name an arbitrary
scope specified with {} that is not a loop, and that does seem like
something we would want to be able to do. On that note, going back to the
originally proposed syntax, since the name is attached to a scope and not
really the loop itself, I think the following syntax for loops might be
more consistent with the scope naming syntax:
while (cnd1) L::
{ // the "L::" is on the previous line so braces line up
while(cnd2)
{
if (cnd3)
break L;
if (cnd4)
continue L;
}
//...
}
This is still a little weird because it's as if we are referring to
something inside a scope before the scope itself is defined as a namespace,
class, or anything else. Adding the keyword "scope" would be really natural
here to declare a scope, but I believe that could break existing code (I
think). On possibility would be to add a colon after it so it looks like a
label, it would then need to be followed by a statement like any other
label. I still think this might break existing code but I'm not sure how
(I'd like it if anyone could reply and say if this is safe), I think the
colon might save us from ambiguities.
Here is an example of that syntax:
while (cnd1)
scope L:
{ // the "L::" is on the previous line so braces line up
while(cnd2)
{
if (cnd3)
break L;
if (cnd4)
continue L;
}
//...
}
-Rich
On Monday, April 8, 2013 2:21:17 PM UTC-7, Vicente J. Botet Escriba wrote:
>
>
> I would like to present an alternative to the break break ... proposal
> based on the restart/leave of the Beta language. The alternative takes in
> account *break* and *continue* on nesting iteration statements.
>
> * Motivation*
>
> Exiting from an iteration statement that contains another iteration
> statement or and switch statement needs to use an auxiliary label and a
> goto
>
>
> while(cnd1)
> {
> while(cnd2)
> {
> if (cnd3)
> goto while_1; // leave first while
> }
> //...
> }
> while_1:
>
> while(cnd1)
> {
> switch(cnd2)
> {
> case a:
> goto while_1; // don't use break to leave while
> // ...
> }
> //...
> }
> while_1:
>
> or an auxiliary variable if we want to preserve the well know 'structured
> programming'
>
> while(cnd1)
> {
> bool must_leave_1 = false;
> while(cnd2)
> {
> if (cnd3) {
> must_leave_1 = true; break;
> }
> // ...
> }
> if (must_leave_1) break;
> //...
> } while_1:
>
>
> while(cnd1)
> {
> bool must_leave_1 = false;
> switch(cnd2)
> {
> case a:
> must_leave_1 = true; break;
> // ...
> }
> if (must_leave_1) break;
> //...
> } while_1:
>
> The same occurs when continuing an external loop including an internal
> loop.
>
> while(cnd1)
> {
> while(cnd2)
> {
> if (cnd4)
> goto continue_1; // continue first while
> }
> //...
> continue_1:
> } break_1:
>
> In the general case we need either two variables or two labels.
>
> while(cnd1)
> {
> while(cnd2)
> {
> if (cnd3)
> goto break_1; // leave first while
> if (cnd4)
> goto continue_1; // continue first while
> }
> //...
> continue_1:
> }
> break_1:
>
>
> Using auxiliary variables is cumbersome and adding the auxiliary labels
> introduce too much opportunities for escaping the structured programming
> paradigm.
>
> *One possible **structured solution*
>
> *labeled iteration statements*
>
> An alternative used by the language Beta is to name the statements so that
> we can either leave the named statement or continue it iteration using
> named break and named continue statements as in
>
> L:: while(cnd1)
> {
> while(cnd2)
> {
> if (cnd3)
> break L;
> if (cnd4)
> continue L;
> }
> //...
> }
>
> Are goto allowed on this kind of labels?
> I don't think this is neither needed nor desirable.
>
>
> * labeled blocks*
>
> Having labeled iteration statements and switch statements but not labeled
> blocks could seem counter-intuitive.
>
> The user could be tempted to do artificial things like
>
> L:: do {
> // ...
> if (cnd) break L;
> // ...
> } while(false);
>
> while the following seams more natural
>
> L::
> {
> // ...
> if (cnd) break L;
> // ...
> }
>
>
> The main advantages respect to a label/goto solution are:
>
> * this labels can be used only inside the named statement/block preserving
> the structure of the code and
> * no need to duplicate the label in case break and continue are needed,
> only one label is enough.
>
>
>
> Best,
> Vicente
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_5833_1692538.1398129506559
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The same thought occurred to me some time ago. I really wa=
nt this in the language. It feels more right and natural than double-b=
reaks, gotos, and flags. This is a way to say what you really want to say i=
n C++, "I want to break out of loop A," "I want to continue loop B." The la=
nguage doesn't allow us to do this as of now. Furthermore this is really gr=
eat if you decide to add another loop around the break/continue, in which c=
ase you have less code to change or to have produce unexpected results. Hon=
estly I think every break or continue should have a loop name attached to i=
t as a point of coding style, and some loops that don't even have breaks/co=
ntinues could be more self documenting if they had a name that says what th=
e loop does, much like any other name says what that construct does. Anothe=
r advantage of this over gotos is that you can trigger for-loop update code=
in an outer loop using continue, something you couldn't do with gotos (wit=
hout changing the for loop to a while loop that is).<div><br></div><div>Gen=
eralizing this to be able to name any scope is not something I had thought =
of, but it's a great idea and this also seems like the right thing to do to=
me. As far as the syntax, I had had something more like this in mind:</div=
><div><br></div><div>while L(cnd1) <br>{<br> while(cnd2)<br>&nbs=
p; {<br> if (cnd3) <br>  =
; break L;<br> if (cnd4) <br>  =
; continue L;<br> }<br> //...<br>} <br></div><div><b=
r></div><div>Here's another idea for the syntax: C++11 introduced the synta=
x "enum class" for strongly typed enums with scoped enum values. Here, an e=
xisting language construct was extended to have additional scoping by addin=
g the class keyword in front of it. So another way to go about the syntax f=
or named loops would be to follow suit:<br></div><div><br></div><div>while =
class L(cnd1) <br>{<br> while(cnd2)<br> {<br> &=
nbsp; if (cnd3) <br> break L;<br> &=
nbsp; if (cnd4) <br> continue L;<b=
r> }<br> //...<br>} <br></div><div><br></div><div>However =
this sort of syntax will break if we want to name an arbitrary scope specif=
ied with {} that is not a loop, and that does seem like something we would =
want to be able to do. On that note, going back to the originally proposed =
syntax, since the name is attached to a scope and not really the loop itsel=
f, I think the following syntax for loops might be more consistent with the=
scope naming syntax:</div><div><br></div><div>while (cnd1) L::</div><=
div>{ // the "L::" is on the previous line so braces line up<br> whil=
e(cnd2)<br> {<br> if (cnd3) <br> &n=
bsp; break L;<br> if (cnd4) <br> &n=
bsp; continue L;<br> }<br> //...<br>} <b=
r></div><div><br></div><div>This is still a little weird because it's as if=
we are referring to something inside a scope before the scope itself is de=
fined as a namespace, class, or anything else. Adding the keyword "scope" w=
ould be really natural here to declare a scope, but I believe that could br=
eak existing code (I think). On possibility would be to add a colon after i=
t so it looks like a label, it would then need to be followed by a statemen=
t like any other label. I still think this might break existing code but I'=
m not sure how (I'd like it if anyone could reply and say if this is safe),=
I think the colon might save us from ambiguities.</div><div><br></div><div=
>Here is an example of that syntax:</div><div><br></div><div><div>while (cn=
d1)</div><div>scope L:</div><div>{ // the "L::" is on the previous line so =
braces line up<br> while(cnd2)<br> {<br> if (=
cnd3) <br> break L;<br>  =
; if (cnd4) <br> continue L;<br> }=
<br> //...<br>} </div></div><div><br></div><div>-Rich<br><div><d=
iv><br>On Monday, April 8, 2013 2:21:17 PM UTC-7, Vicente J. Botet Escriba =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
I would like to present an alternative to the break break ...
proposal based on the restart/leave of the Beta language. The
alternative takes in account <b>break</b> and <b>continue</b> on
nesting iteration statements.<br>
<br>
<b> Motivation</b><br>
<br>
Exiting from an iteration statement that contains another iteration
statement or and switch statement needs to use an auxiliary label
and a goto <br>
<br>
<br>
while(cnd1) <br>
{<br>
while(cnd2)<br>
{<br>
if (cnd3) <br>
goto while_1; // leave first while<br>
}<br>
//...<br>
} <br>
while_1:<br>
<br>
while(cnd1) <br>
{<br>
switch(cnd2)<br>
{<br>
case a: <br>
goto while_1; // don't use break to leav=
e while<br>
// ...<br>
}<br>
//...<br>
} <br>
while_1:<br>
<br>
or an auxiliary variable if we want to preserve the well know
'structured programming'<br>
<br>
while(cnd1) <br>
{<br>
bool must_leave_1 =3D false;<br>
while(cnd2)<br>
{<br>
if (cnd3) {<br>
must_leave_1 =3D true; break; <br>
}<br>
// ...<br>
}<br>
if (must_leave_1) break;<br>
//...<br>
} while_1:<br>
<br>
<br>
while(cnd1) <br>
{<br>
bool must_leave_1 =3D false;<br>
switch(cnd2)<br>
{<br>
case a: <br>
must_leave_1 =3D true; break; <br>
// ...<br>
}<br>
if (must_leave_1) break;<br>
//...<br>
} while_1:<br>
<br>
The same occurs when continuing an external loop including an
internal loop. <br>
<br>
while(cnd1) <br>
{<br>
while(cnd2)<br>
{<br>
if (cnd4) <br>
goto continue_1; // continue first while=
<br>
}<br>
//...<br>
continue_1:<br>
} break_1:<br>
<br>
In the general case we need either two variables or two labels.<b=
r>
<br>
while(cnd1) <br>
{<br>
while(cnd2)<br>
{<br>
if (cnd3) <br>
goto break_1; // leave first while<br>
if (cnd4) <br>
goto continue_1; // continue first while=
<br>
}<br>
//...<br>
continue_1:<br>
} <br>
break_1:<br>
<br>
<br>
Using auxiliary variables is cumbersome and adding the auxiliary
labels introduce too much opportunities for escaping the structured
programming paradigm.<br>
<br>
<b>One possible </b><b><b>structured </b>solution</b><b><br>
</b><br>
<i>labeled iteration statements</i><i><br>
</i><br>
An alternative used by the language Beta is to name the statements
so that we can either leave the named statement or continue it
iteration using named break and named continue statements as in <br>
<br>
L:: while(cnd1) <br>
{<br>
while(cnd2)<br>
{<br>
if (cnd3) <br>
break L;<br>
if (cnd4) <br>
continue L;<br>
}<br>
//...<br>
} <br>
<br>
Are goto allowed on this kind of labels?<br>
I don't think this is neither needed nor desirable.<br>
<br>
<br>
<i> labeled blocks</i><br>
<br>
Having labeled iteration statements and switch statements but not
labeled blocks could seem counter-intuitive.<br>
<br>
The user could be tempted to do artificial things like<br>
<br>
L:: do {<br>
// ...<br>
if (cnd) break L;<br>
// ...<br>
} while(false);<br>
<br>
while the following seams more natural<br>
<br>
L:: <br>
{<br>
// ...<br>
if (cnd) break L;<br>
// ...<br>
} <br>
<br>
<br>
The main advantages respect to a label/goto solution are:<br>
<br>
* this labels can be used only inside the named statement/block
preserving the structure of the code and<br>
* no need to duplicate the label in case break and continue are
needed, only one label is enough.<br>
<br>
<br>
<br>
Best,<br>
Vicente<br>
<br>
</div>
</blockquote></div></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5833_1692538.1398129506559--
.
Author: rich.h.delaney@gmail.com
Date: Mon, 21 Apr 2014 18:20:39 -0700 (PDT)
Raw View
------=_Part_5983_13264647.1398129639121
Content-Type: text/plain; charset=UTF-8
The same thought occurred to me some time ago. I really want this in the
language. It feels more right and natural than double-breaks, gotos, and
flags. This is a way to say what you really want to say in C++, "I want to
break out of loop A," "I want to continue loop B." The language doesn't
allow us to do this as of now. Furthermore this is really great if you
decide to add another loop around the break/continue, in which case you
have less code to change or to have produce unexpected results. Honestly I
think every break or continue should have a loop name attached to it as a
point of coding style, and some loops that don't even have breaks/continues
could be more self documenting if they had a name that says what the loop
does, much like any other name says what that construct does. Another
advantage of this over gotos is that you can trigger for-loop update code
in an outer loop using continue, something you couldn't do with gotos
(without changing the for loop to a while loop that is).
Generalizing this to be able to name any scope is not something I had
thought of, but it's a great idea and this also seems like the right thing
to do to me. As far as the syntax, I had had something more like this in
mind:
while L(cnd1)
{
while(cnd2)
{
if (cnd3)
break L;
if (cnd4)
continue L;
}
//...
}
Here's another idea for the syntax: C++11 introduced the syntax "enum
class" for strongly typed enums with scoped enum values. Here, an existing
language construct was extended to have additional scoping by adding the
class keyword in front of it. So another way to go about the syntax for
named loops would be to follow suit:
while class L(cnd1)
{
while(cnd2)
{
if (cnd3)
break L;
if (cnd4)
continue L;
}
//...
}
However this sort of syntax will break if we want to name an arbitrary
scope specified with {} that is not a loop, and that does seem like
something we would want to be able to do. On that note, going back to the
originally proposed syntax, since the name is attached to a scope and not
really the loop itself, I think the following syntax for loops might be
more consistent with the scope naming syntax:
while (cnd1) L::
{ // the "L::" is on the previous line so braces line up
while(cnd2)
{
if (cnd3)
break L;
if (cnd4)
continue L;
}
//...
}
This is still a little weird because it's as if we are referring to
something inside a scope before the scope itself is defined as a namespace,
class, or anything else. Adding the keyword "scope" would be really natural
here to declare a scope, but I believe that could break existing code (I
think). On possibility would be to add a colon after it so it looks like a
label, it would then need to be followed by a statement like any other
label. I still think this might break existing code but I'm not sure how
(I'd like it if anyone could reply and say if this is safe), I think the
colon might save us from ambiguities.
Here is an example of that syntax:
while (cnd1)
scope L:
{ // the "L::" is on the previous line so braces line up
while(cnd2)
{
if (cnd3)
break L;
if (cnd4)
continue L;
}
//...
}
-Rich
On Monday, April 8, 2013 2:21:17 PM UTC-7, Vicente J. Botet Escriba wrote:
>
>
> I would like to present an alternative to the break break ... proposal
> based on the restart/leave of the Beta language. The alternative takes in
> account *break* and *continue* on nesting iteration statements.
>
> * Motivation*
>
> Exiting from an iteration statement that contains another iteration
> statement or and switch statement needs to use an auxiliary label and a
> goto
>
>
> while(cnd1)
> {
> while(cnd2)
> {
> if (cnd3)
> goto while_1; // leave first while
> }
> //...
> }
> while_1:
>
> while(cnd1)
> {
> switch(cnd2)
> {
> case a:
> goto while_1; // don't use break to leave while
> // ...
> }
> //...
> }
> while_1:
>
> or an auxiliary variable if we want to preserve the well know 'structured
> programming'
>
> while(cnd1)
> {
> bool must_leave_1 = false;
> while(cnd2)
> {
> if (cnd3) {
> must_leave_1 = true; break;
> }
> // ...
> }
> if (must_leave_1) break;
> //...
> } while_1:
>
>
> while(cnd1)
> {
> bool must_leave_1 = false;
> switch(cnd2)
> {
> case a:
> must_leave_1 = true; break;
> // ...
> }
> if (must_leave_1) break;
> //...
> } while_1:
>
> The same occurs when continuing an external loop including an internal
> loop.
>
> while(cnd1)
> {
> while(cnd2)
> {
> if (cnd4)
> goto continue_1; // continue first while
> }
> //...
> continue_1:
> } break_1:
>
> In the general case we need either two variables or two labels.
>
> while(cnd1)
> {
> while(cnd2)
> {
> if (cnd3)
> goto break_1; // leave first while
> if (cnd4)
> goto continue_1; // continue first while
> }
> //...
> continue_1:
> }
> break_1:
>
>
> Using auxiliary variables is cumbersome and adding the auxiliary labels
> introduce too much opportunities for escaping the structured programming
> paradigm.
>
> *One possible **structured solution*
>
> *labeled iteration statements*
>
> An alternative used by the language Beta is to name the statements so that
> we can either leave the named statement or continue it iteration using
> named break and named continue statements as in
>
> L:: while(cnd1)
> {
> while(cnd2)
> {
> if (cnd3)
> break L;
> if (cnd4)
> continue L;
> }
> //...
> }
>
> Are goto allowed on this kind of labels?
> I don't think this is neither needed nor desirable.
>
>
> * labeled blocks*
>
> Having labeled iteration statements and switch statements but not labeled
> blocks could seem counter-intuitive.
>
> The user could be tempted to do artificial things like
>
> L:: do {
> // ...
> if (cnd) break L;
> // ...
> } while(false);
>
> while the following seams more natural
>
> L::
> {
> // ...
> if (cnd) break L;
> // ...
> }
>
>
> The main advantages respect to a label/goto solution are:
>
> * this labels can be used only inside the named statement/block preserving
> the structure of the code and
> * no need to duplicate the label in case break and continue are needed,
> only one label is enough.
>
>
>
> Best,
> Vicente
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_5983_13264647.1398129639121
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>The same thought occurred to me some time ago. I real=
ly want this in the language. It feels more right and natural than double-b=
reaks, gotos, and flags. This is a way to say what you really want to say i=
n C++, "I want to break out of loop A," "I want to continue loop B." The la=
nguage doesn't allow us to do this as of now. Furthermore this is really gr=
eat if you decide to add another loop around the break/continue, in which c=
ase you have less code to change or to have produce unexpected results. Hon=
estly I think every break or continue should have a loop name attached to i=
t as a point of coding style, and some loops that don't even have breaks/co=
ntinues could be more self documenting if they had a name that says what th=
e loop does, much like any other name says what that construct does. Anothe=
r advantage of this over gotos is that you can trigger for-loop update code=
in an outer loop using continue, something you couldn't do with gotos (wit=
hout changing the for loop to a while loop that is).</div><div><br></div><d=
iv>Generalizing this to be able to name any scope is not something I had th=
ought of, but it's a great idea and this also seems like the right thing to=
do to me. As far as the syntax, I had had something more like this in mind=
:</div><div><br></div><div>while L(cnd1) </div><div>{</div><div> =
while(cnd2)</div><div> {</div><div> if (cnd3) </di=
v><div> break L;</div><div> if (cnd4) =
;</div><div> continue L;</div><div> }</div><div>&=
nbsp; //...</div><div>} </div><div><br></div><div>Here's another idea =
for the syntax: C++11 introduced the syntax "enum class" for strongly typed=
enums with scoped enum values. Here, an existing language construct was ex=
tended to have additional scoping by adding the class keyword in front of i=
t. So another way to go about the syntax for named loops would be to follow=
suit:</div><div><br></div><div>while class L(cnd1) </div><div>{</div>=
<div> while(cnd2)</div><div> {</div><div> if (cnd3=
) </div><div> break L;</div><div> if =
(cnd4) </div><div> continue L;</div><div> }<=
/div><div> //...</div><div>} </div><div><br></div><div>However t=
his sort of syntax will break if we want to name an arbitrary scope specifi=
ed with {} that is not a loop, and that does seem like something we would w=
ant to be able to do. On that note, going back to the originally proposed s=
yntax, since the name is attached to a scope and not really the loop itself=
, I think the following syntax for loops might be more consistent with the =
scope naming syntax:</div><div><br></div><div>while (cnd1) L::</div><div>{ =
// the "L::" is on the previous line so braces line up</div><div> whi=
le(cnd2)</div><div> {</div><div> if (cnd3) </div><d=
iv> break L;</div><div> if (cnd4) </d=
iv><div> continue L;</div><div> }</div><div> =
; //...</div><div>} </div><div><br></div><div>This is still a little w=
eird because it's as if we are referring to something inside a scope before=
the scope itself is defined as a namespace, class, or anything else. Addin=
g the keyword "scope" would be really natural here to declare a scope, but =
I believe that could break existing code (I think). On possibility would be=
to add a colon after it so it looks like a label, it would then need to be=
followed by a statement like any other label. I still think this might bre=
ak existing code but I'm not sure how (I'd like it if anyone could reply an=
d say if this is safe), I think the colon might save us from ambiguities.</=
div><div><br></div><div>Here is an example of that syntax:</div><div><br></=
div><div>while (cnd1)</div><div>scope L:</div><div>{ // the "L::" is on the=
previous line so braces line up</div><div> while(cnd2)</div><div>&nb=
sp; {</div><div> if (cnd3) </div><div>  =
; break L;</div><div> if (cnd4) </div><div> =
continue L;</div><div> }</div><div> //...</div><div>}&nb=
sp;</div><div><br></div><div>-Rich</div><br>On Monday, April 8, 2013 2:21:1=
7 PM UTC-7, Vicente J. Botet Escriba wrote:<blockquote 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">
<br>
I would like to present an alternative to the break break ...
proposal based on the restart/leave of the Beta language. The
alternative takes in account <b>break</b> and <b>continue</b> on
nesting iteration statements.<br>
<br>
<b> Motivation</b><br>
<br>
Exiting from an iteration statement that contains another iteration
statement or and switch statement needs to use an auxiliary label
and a goto <br>
<br>
<br>
while(cnd1) <br>
{<br>
while(cnd2)<br>
{<br>
if (cnd3) <br>
goto while_1; // leave first while<br>
}<br>
//...<br>
} <br>
while_1:<br>
<br>
while(cnd1) <br>
{<br>
switch(cnd2)<br>
{<br>
case a: <br>
goto while_1; // don't use break to leav=
e while<br>
// ...<br>
}<br>
//...<br>
} <br>
while_1:<br>
<br>
or an auxiliary variable if we want to preserve the well know
'structured programming'<br>
<br>
while(cnd1) <br>
{<br>
bool must_leave_1 =3D false;<br>
while(cnd2)<br>
{<br>
if (cnd3) {<br>
must_leave_1 =3D true; break; <br>
}<br>
// ...<br>
}<br>
if (must_leave_1) break;<br>
//...<br>
} while_1:<br>
<br>
<br>
while(cnd1) <br>
{<br>
bool must_leave_1 =3D false;<br>
switch(cnd2)<br>
{<br>
case a: <br>
must_leave_1 =3D true; break; <br>
// ...<br>
}<br>
if (must_leave_1) break;<br>
//...<br>
} while_1:<br>
<br>
The same occurs when continuing an external loop including an
internal loop. <br>
<br>
while(cnd1) <br>
{<br>
while(cnd2)<br>
{<br>
if (cnd4) <br>
goto continue_1; // continue first while=
<br>
}<br>
//...<br>
continue_1:<br>
} break_1:<br>
<br>
In the general case we need either two variables or two labels.<b=
r>
<br>
while(cnd1) <br>
{<br>
while(cnd2)<br>
{<br>
if (cnd3) <br>
goto break_1; // leave first while<br>
if (cnd4) <br>
goto continue_1; // continue first while=
<br>
}<br>
//...<br>
continue_1:<br>
} <br>
break_1:<br>
<br>
<br>
Using auxiliary variables is cumbersome and adding the auxiliary
labels introduce too much opportunities for escaping the structured
programming paradigm.<br>
<br>
<b>One possible </b><b><b>structured </b>solution</b><b><br>
</b><br>
<i>labeled iteration statements</i><i><br>
</i><br>
An alternative used by the language Beta is to name the statements
so that we can either leave the named statement or continue it
iteration using named break and named continue statements as in <br>
<br>
L:: while(cnd1) <br>
{<br>
while(cnd2)<br>
{<br>
if (cnd3) <br>
break L;<br>
if (cnd4) <br>
continue L;<br>
}<br>
//...<br>
} <br>
<br>
Are goto allowed on this kind of labels?<br>
I don't think this is neither needed nor desirable.<br>
<br>
<br>
<i> labeled blocks</i><br>
<br>
Having labeled iteration statements and switch statements but not
labeled blocks could seem counter-intuitive.<br>
<br>
The user could be tempted to do artificial things like<br>
<br>
L:: do {<br>
// ...<br>
if (cnd) break L;<br>
// ...<br>
} while(false);<br>
<br>
while the following seams more natural<br>
<br>
L:: <br>
{<br>
// ...<br>
if (cnd) break L;<br>
// ...<br>
} <br>
<br>
<br>
The main advantages respect to a label/goto solution are:<br>
<br>
* this labels can be used only inside the named statement/block
preserving the structure of the code and<br>
* no need to duplicate the label in case break and continue are
needed, only one label is enough.<br>
<br>
<br>
<br>
Best,<br>
Vicente<br>
<br>
</div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5983_13264647.1398129639121--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Mon, 21 Apr 2014 18:41:04 -0700 (PDT)
Raw View
------=_Part_751_28134132.1398130864398
Content-Type: text/plain; charset=UTF-8
On Monday, April 8, 2013 11:21:17 PM UTC+2, Vicente J. Botet Escriba wrote:
>
> I would like to present an alternative to the break break ... proposal
> based on the restart/leave of the Beta language. The alternative takes in
> account *break* and *continue* on nesting iteration statements.
>
Have you read N3879 ?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3879.pdf
As part of it we propose the addition to C++ of the break label and
continue label statements from Java, which would seem to address your use
cases in way proven with existing practice.
It would be great if you could review it and let us know if it does indeed
address your needs.
Thanks,
Andrew.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_751_28134132.1398130864398
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, April 8, 2013 11:21:17 PM UTC+2, Vicente J. Bot=
et Escriba wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">I would like to present an alte=
rnative to the break break ...
proposal based on the restart/leave of the Beta language. The
alternative takes in account <b>break</b> and <b>continue</b> on
nesting iteration statements.<br></div></blockquote><div><br></div><div=
>Have you read N3879 ?</div><div><br></div><div> http://www.op=
en-std.org/jtc1/sc22/wg21/docs/papers/2014/n3879.pdf</div><div><br></div><d=
iv>As part of it we propose the addition to C++ of the break label and cont=
inue label statements from Java, which would seem to address your use cases=
in way proven with existing practice.</div><div><br></div><div>It would be=
great if you could review it and let us know if it does indeed address you=
r needs.</div><div><br></div><div>Thanks,</div><div>Andrew.</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_751_28134132.1398130864398--
.
Author: rich.h.delaney@gmail.com
Date: Tue, 22 Apr 2014 18:01:36 -0700 (PDT)
Raw View
------=_Part_6914_13241206.1398214896086
Content-Type: text/plain; charset=UTF-8
I hadn't' seen/read N3879, but I have now. Thank you for pointing it out
Andrew.
First, let me amend something I stated previously. I think the
label/scope-identifier belongs on the loop not the enclosed statement as
I'd stated previously. The loop is itself a statement so this is consistent.
In short, yes N3879 addresses my needs.
In detail:
I'm fairly indifferent on adding an *explicit switch* (I use case
fall-though a lot), but an explicit switch would have it's uses and I can
see it saving extra lines of code (now occupied with {} and break;) and
logic errors. Of course the good old fashioned switch statement will still
be there. Something about the syntax and scoping of the *explicit switch*strikes me as a little non-C++-like, but that could just be me.There are
very few instances In the language where scope ends without a curly brace.
I don't want C++ to become C#.
As far as the *goto case*, I suppose this would also be useful and I have
no real objections, however it maybe worth noting this could be
accomplished with an additional label and a goto, so perhaps the feature is
somewhat redundant. Using the example from N3879 I've removed a space and
added a label to achieve the same thing without the use of a goto case
statement:
switch (cond)
{
casefoo:
case foo:
do_foo();
break;
case bar:
do_bar();
goto casefoo;
case baz:
do_baz();
};
I'll also say if the feature was added it might be worth considering adding
a syntax to jump to cases in enclosing switch statements, it seems more
complete and in keeping with adding a syntax to jump to or from outer
loops, why not outer switch statements too? Perhaps if the switch statement
was also named and you could say "goto outerswitch case outercase;" or
something. But this can also be accomplished today with a goto.
I do really like the syntax of labeling loops. It's worth noting that it is
the exact same syntax as a goto label. In fact, as specified there could be
c++ code out there in the wild that once-compiled under this feature will
have named loops that are not being used; I assume that was intentional.
That's because someone today can put a label before a loop and goto that
label. It's interesting though, because no syntax is really being added
here to name a loop. Rather, syntax is being added to break and continue to
interact with loops that appear in conjunction with what will now be
goto/loop labels. I also assume continue will behave correctly with for
loop update code, though I think it's a little vague in the linked PDF.
One thing N3879 doesn't have is general scope naming as proposed in the
original post in this thread. I kind of liked that idea, and I see no
reason it can't be applied in keeping with he syntax and spirit proposed in
N3879.
That is, you could have code like this:
namedscope:
{
if (foo())
break namedscope; // break from namedscope, jump after bar() call
bar();
}
Of course then this would be valid too:
namedscope: // optional
{
if (foo())
break; // break from namedscope (the enclosing scope), jump after
bar() call
bar();
}
As would this:
{
if (foo())
break; // break from enclosing scope, jump after bar() call
bar();
}
And of course this would too:
outerscope:
{
innerscope: // optional
{
if (foo())
break outerscope; // break from outer {}, jump after foobar() call
bar();
}
foobar();
}
On closer inspection adding named scope also means one should be able to
break out of unnamed scopes, something one can not do in C++ today. And,
similarly to the *goto case* feature, it yields nothing one could not do
with a goto today.
Code like this:
{
{
if (foo())
goto breakouterscope; // this accomplishes the same thing as the
examples above
bar();
}
foobar();
}
breakouterscope:
So then the question is do we want this sort of redundancy in the language?
That is both *goto case* and generalized scope labeling; I think they are
in the same bucket. And, in turn the question to ask around this is, "Does
this improve code maintainability and quality over use gotos or other
available language constructs?" "Or is there no inherent value in this and
it just hides code just as well written with a goto?"
On Monday, April 21, 2014 6:41:04 PM UTC-7, Andrew Tomazos wrote:
>
> On Monday, April 8, 2013 11:21:17 PM UTC+2, Vicente J. Botet Escriba wrote:
>>
>> I would like to present an alternative to the break break ... proposal
>> based on the restart/leave of the Beta language. The alternative takes in
>> account *break* and *continue* on nesting iteration statements.
>>
>
> Have you read N3879 ?
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3879.pdf
>
> As part of it we propose the addition to C++ of the break label and
> continue label statements from Java, which would seem to address your use
> cases in way proven with existing practice.
>
> It would be great if you could review it and let us know if it does indeed
> address your needs.
>
> Thanks,
> Andrew.
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_6914_13241206.1398214896086
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I hadn't' seen/read N3879, but I have now. Thank you =
for pointing it out Andrew.<div><br></div><div>First, let me amend somethin=
g I stated previously. I think the label/scope-identifier belongs on the lo=
op not the enclosed statement as I'd stated previously. The loop is itself =
a statement so this is consistent.</div><div><br></div><div>In short, yes N=
3879 addresses my needs.</div><div>In detail:</div><div><br></div><div>I'm =
fairly indifferent on adding an <i>explicit switch</i> (I use case fall-tho=
ugh a lot), but an explicit switch would have it's uses and I can see it sa=
ving extra lines of code (now occupied with {} and break;) and logic errors=
.. Of course the good old fashioned switch statement will still be there. So=
mething about the syntax and scoping of the <i>explicit switch</i> strikes =
me as a little non-C++-like, but that could just be me.There are very few i=
nstances In the language where scope ends without a curly brace. I don't wa=
nt C++ to become C#.</div><div><br></div><div>As far as the <i>goto case</i=
>, I suppose this would also be useful and I have no real objections, howev=
er it maybe worth noting this could be accomplished with an additional labe=
l and a goto, so perhaps the feature is somewhat redundant. Using the examp=
le from N3879 I've removed a space and added a label to achieve the same th=
ing without the use of a goto case statement:</div><div><br></div><div><div=
>switch (cond)</div><div>{</div><div>casefoo:</div><div>case foo:</div><div=
> do_foo();</div><div> break;</div><div>case bar:</div><div>&nb=
sp; do_bar();</div><div> goto casefoo;</div><div>case baz:</div><div>=
do_baz();</div><div>};</div></div><div><br></div><div>I'll also say =
if the feature was added it might be worth considering adding a syntax to j=
ump to cases in enclosing switch statements, it seems more complete and in =
keeping with adding a syntax to jump to or from outer loops, why not outer =
switch statements too? Perhaps if the switch statement was also named and y=
ou could say "goto outerswitch case outercase;" or something. But this can =
also be accomplished today with a goto.</div><div><br></div><div>I do reall=
y like the syntax of labeling loops. It's worth noting that it is the exact=
same syntax as a goto label. In fact, as specified there could be c++ code=
out there in the wild that once-compiled under this feature will have name=
d loops that are not being used; I assume that was intentional. That's beca=
use someone today can put a label before a loop and goto that label. It's i=
nteresting though, because no syntax is really being added here to name a l=
oop. Rather, syntax is being added to break and continue to interact with l=
oops that appear in conjunction with what will now be goto/loop labels. I a=
lso assume continue will behave correctly with for loop update code, though=
I think it's a little vague in the linked PDF.</div><div><br></div><div>On=
e thing N3879 doesn't have is general scope naming as proposed in=
the original post in this thread. I kind of liked that idea, and I see no =
reason it can't be applied in keeping with he syntax and spirit proposed in=
N3879.</div><div>That is, you could have code like this:</div><div><br></d=
iv><div>namedscope:</div><div>{</div><div> if (foo())</div><div> =
; break namedscope; // break from namedscope, jump after bar() =
call</div><div> bar();</div><div>}</div><div><br></div><div>Of course=
then this would be valid too:</div><div><br></div><div><div>namedscope: //=
optional</div><div>{</div><div> if (foo())</div><div> b=
reak; // break from namedscope (the enclosing scope), jump after=
bar() call</div><div> bar();</div><div>}</div></div><div><br></div><=
div>As would this:</div><div><br></div><div><div>{</div><div> if (foo=
())</div><div> break; // break from enclosing scope, jump afte=
r bar() call</div><div> bar();</div><div>}</div></div><div><br></div>=
<div>And of course this would too:</div><div><br></div><div>outerscope:</di=
v><div>{</div><div><div> innerscope: // optional</div><div> {</=
div><div> if (foo())</div><div> break oute=
rscope; // break from outer {}, jump after foobar() call</div><div> &=
nbsp; bar();</div><div> }</div><div> foobar();</div><div>}</div=
></div><div><br></div><div>On closer inspection adding named scope also mea=
ns one should be able to break out of unnamed scopes, something one can not=
do in C++ today. And, similarly to the <i>goto case</i> feature, it yields=
nothing one could not do with a goto today.</div><div>Code like this:</div=
><div><br></div><div><div>{</div><div><div> {</div><div> =
if (foo())</div><div> goto breakouterscope; // this ac=
complishes the same thing as the examples above</div><div> bar=
();</div><div> }</div><div> foobar();</div><div>}</div></div></=
div><div>breakouterscope:<br></div><div><br></div><div>So then the question=
is do we want this sort of redundancy in the language? That is both <i>got=
o case</i> and generalized scope labeling; I think they are in the same buc=
ket. And, in turn the question to ask around this is, "Does this impr=
ove code maintainability and quality over use gotos or other available lang=
uage constructs?" "Or is there no inherent value in this and it just h=
ides code just as well written with a goto?"</div><div><br></div><div><br>O=
n Monday, April 21, 2014 6:41:04 PM UTC-7, Andrew Tomazos wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Monday, April 8, 2013=
11:21:17 PM UTC+2, Vicente J. Botet Escriba wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">I would like to present an alte=
rnative to the break break ...
proposal based on the restart/leave of the Beta language. The
alternative takes in account <b>break</b> and <b>continue</b> on
nesting iteration statements.<br></div></blockquote><div><br></div><div=
>Have you read N3879 ?</div><div><br></div><div> <a href=3D"ht=
tp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3879.pdf" target=3D"=
_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2=
F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn3879.pd=
f\46sa\75D\46sntz\0751\46usg\75AFQjCNHmF8VfGZj-Dx_BiuiAjB6nNSyAwg';return t=
rue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fww=
w.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn3879.pdf\46sa=
\75D\46sntz\0751\46usg\75AFQjCNHmF8VfGZj-Dx_BiuiAjB6nNSyAwg';return true;">=
http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2014/<wbr>n3879.pdf=
</a></div><div><br></div><div>As part of it we propose the addition to C++ =
of the break label and continue label statements from Java, which would see=
m to address your use cases in way proven with existing practice.</div><div=
><br></div><div>It would be great if you could review it and let us know if=
it does indeed address your needs.</div><div><br></div><div>Thanks,</div><=
div>Andrew.</div><div><br></div></div></blockquote></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_6914_13241206.1398214896086--
.
Author: gmisocpp@gmail.com
Date: Wed, 23 Apr 2014 06:26:44 -0700 (PDT)
Raw View
------=_Part_7749_8083376.1398259604820
Content-Type: text/plain; charset=UTF-8
Hi
I'm not fond of goto style labels floating near flow control elements. I
prefer names bound to them..
int main()
{
for named l1 (int i = 0; i< 100; ++i)
{
// goto l2; would be error... name not known yet.
// continue l2; would be error...
for named l2 (int j = 0; j < 100; ++j)
{
if (j==50)
break l1; // or continue l1 etc.
switch named s1 (j)
{
case 1:
int x = whatever();
switch named s2 (x)
{
case 1:
something();
break s1; // outer switch.
case 2 named of_questionable_value:
break l2; inner loop
case 3:
whatever();
continue of_questionable_value;
default:
break l1; // outer loop
}
break;
}
}
}
// goto l1; would be error... name forgotten now.
// continue l1; would be error..
{ named how_useful: // label syntax better here? but label != scope...
int x;
for ( I = 0; I < 10; ++I)
{
if (I == 5)
break how_useful; // ok, guess so.
// continue how_useful, goto how_useful? hmmm, not liking this..
printf("not always seen");
{
int x;
printf("%d %d\n", x , how_useful::x ); // maybe.
}
}
printf("not always seen");
}
}
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_7749_8083376.1398259604820
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi</div><div><br></div><div>I'm not fond of goto styl=
e labels floating near flow control elements. I prefer names boun=
d to them..</div><div><br></div><div>int main()<br>{ <br> for n=
amed l1 (int i =3D 0; i< 100; ++i)<br> {<br> &nbs=
p; // goto l2; would be error... name not known yet.<br>&=
nbsp; // continue l2; would be error...<br>&n=
bsp;<br> for named l2 (int j =3D 0; j &=
lt; 100; ++j)<br> {<br> &nbs=
p; if (j=3D=3D50)<br> =
br=
eak l1; // or continue l1 etc.</div><div> &nbs=
p; switch named s1 (j)<br> &=
nbsp; {<br> &nbs=
p; case 1:<br> &=
nbsp; int=
x =3D whatever();<br>  =
; switch named s2 (x)<br> &n=
bsp;  =
; {<br> &n=
bsp; case 1:<br>  =
; &n=
bsp; something();<br> =
&nb=
sp; break s1; // outer swit=
ch.<br> &n=
bsp; case 2 named of_questionable=
_value:<br> &nbs=
p; =
break l2; inner loop<br> &nb=
sp; case 3:<br>=
&nb=
sp; whatever();=
<br>  =
; continu=
e of_questionable_value;<br>  =
; default=
:<br> &nbs=
p; break =
l1; // outer loop<br> =
}<br> &nb=
sp; break;<br> &=
nbsp; }<br> &nbs=
p; }<br> }<br> &=
nbsp; // goto l1; would be error... name forgotten now.<br> &nbs=
p; // continue l1; would be error..</div><div> { named ho=
w_useful: // label syntax better here? but label !=3D scope...</div><=
div> int x;</div><div> =
for ( I =3D 0; I < 10; ++I)<br>&nbs=
p; {<br> &=
nbsp; if (I =3D=3D 5)<br> &n=
bsp; brea=
k how_useful; // ok, guess so.</div><div> &nbs=
p; // continue how_useful, goto how_useful? h=
mmm, not liking this..<br> &=
nbsp; printf("not always seen");</div><div> &n=
bsp; {</div><div> &nbs=
p; int x;</div>=
<div> &nbs=
p; printf("%d %d\n", x , how_useful::x ); // maybe.</div><div>&=
nbsp; }<br> &nbs=
p; } <br> &=
nbsp; printf("not always seen");<br> }<br>}</div><d=
iv><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_7749_8083376.1398259604820--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 23 Apr 2014 09:58:11 -0400
Raw View
On 2014-04-22 21:01, rich.h.delaney@gmail.com wrote:
> One thing N3879 doesn't have is general scope naming as proposed in the
> original post in this thread. [...]
>
> Of course then this would be valid too:
>
> namedscope: // optional
> {
> if (foo())
> break; // break from namedscope (the enclosing scope), jump after
> bar() call
> bar();
> }
This code (assuming all of the above is inside some other loop or a
switch) is AFAIK entirely valid right now, with a known meaning. Making
such a change could therefore break existing code. I don't think we
should/can allow this.
> As would this:
>
> {
> if (foo())
> break; // break from enclosing scope, jump after bar() call
> bar();
> }
....and this is even worse!
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: rich.h.delaney@gmail.com
Date: Wed, 23 Apr 2014 10:51:55 -0700 (PDT)
Raw View
------=_Part_3988_5866172.1398275515240
Content-Type: text/plain; charset=UTF-8
>
> > namedscope: // optional
> > {
> > if (foo())
> > break; // break from namedscope (the enclosing scope), jump after
> > bar() call
> > bar();
> > }
> This code (assuming all of the above is inside some other loop or a
> switch) is AFAIK entirely valid right now, with a known meaning. Making
> such a change could therefore break existing code. I don't think we
> should/can allow this.
> > As would this:
> >
> > {
> > if (foo())
> > break; // break from enclosing scope, jump after bar() call
> > bar();
> > }
> ...and this is even worse!
-Matthew
Yes you are completely correct! This breaks existing code, good catch! I
was attempting to expand the syntax presented in the linked N3879 to
include features originally presented in this thread; it seems the
straightforward generalization of the N3879 syntax to named scopes is
flawed.
I'm not fond of goto style labels floating near flow control elements. I
> prefer names bound to them..
-gmis...
Honestly, the more I think about it I am not fond of the floating label
names either. Right now I think this is my preferred syntax: (which was
kind of what I had in mind originally)
do outername {
for innername(int i = 0; i < 100; ++i) {
if (Foo())
continue outername; // check do-while condition and continue loop if
true
else
switch (Bar()) {
case 0:
return;
case 1:
break innername; // exit for loop
case 3;
LogHit();
break; // exit switch
default:
LogMiss();
};
}
} while (NotDone());
If the above syntax is chosen (or something similar), then the open
questions are this:
- Is named scope desired as part of this language feature?
- Is it desirable to be able to name if and else blocks as well? If so I
believe it definitely belongs in this feature with the same syntax as used
for loops.
- Is something of the form *goto case *(as described in N3879) desired
for switch statement control flow, and does it belong with this feature?
- Are *explicit case* statements with per-case scooping (as described in N3879)
desired, and does it belong with this feature?
For any of these to which the answer is "yes," a syntax needs to be settled
upon (with the exception of the second bullet point). My revised ideas for
a syntax for the first bullet include:
declscope(somescope) { // name this scope somescope
if (Foo())
break somescope; // jump past end of the curly brace out of thisscope
Bar();
}
and this would be valid too:
declscope(somescope) { // name this scope somescope
if (Foo())
break; // jump past end of the curly brace out of thisscope. this
cannot break existing code because it will only work with scopes declared
with the new declscope keyword.
Bar();
}
However, this will require adding a keyword that could break existing code.
In the example the keyword is *declscope* with parenthesis much like the *decltype
*keyword new to C++11, but it could also be done with a keyword *scope* and
no parenthesis.
That said, for the above 4 bullet points, I have no strong personal
feelings on them. I just want to call out that they are open questions.
-Rich
On Wednesday, April 23, 2014 6:58:11 AM UTC-7, Matthew Woehlke wrote:
>
> On 2014-04-22 21:01, rich.h....@gmail.com <javascript:> wrote:
> > One thing N3879 doesn't have is general scope naming as proposed in the
> > original post in this thread. [...]
> >
> > Of course then this would be valid too:
> >
> > namedscope: // optional
> > {
> > if (foo())
> > break; // break from namedscope (the enclosing scope), jump after
> > bar() call
> > bar();
> > }
>
> This code (assuming all of the above is inside some other loop or a
> switch) is AFAIK entirely valid right now, with a known meaning. Making
> such a change could therefore break existing code. I don't think we
> should/can allow this.
>
> > As would this:
> >
> > {
> > if (foo())
> > break; // break from enclosing scope, jump after bar() call
> > bar();
> > }
>
> ...and this is even worse!
>
> --
> Matthew
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_3988_5866172.1398275515240
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); =
border-left-style: solid; padding-left: 1ex;">> namedscope: // optional&=
nbsp;<br>> { <br>> if (foo()) <br>> =
break; // break from namedscope (the enclosing scope), j=
ump after <br>> bar() call <br>> bar(); <=
br>> } <br>This code (assuming all of the above is inside some othe=
r loop or a <br>switch) is AFAIK entirely valid right now, with a know=
n meaning. Making <br>such a change could therefore break existing cod=
e. I don't think we <br>should/can allow this. <br>> As would =
this: <br>> <br>> { <br>> if (foo())&n=
bsp;<br>> break; // break from enclosing scope, jump=
after bar() call <br>> bar(); <br>> } <b=
r>...and this is even worse! </blockquote><div>-Matthew </div><di=
v><br></div><div>Yes you are completely correct! This breaks existing code,=
good catch! I was attempting to expand the syntax presented in the linked =
N3879 to include features originally presented in this thread; it seems the=
straightforward generalization of the N3879 syntax to named scopes is flaw=
ed.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204,=
204); border-left-style: solid; padding-left: 1ex;">I'm not fond of goto s=
tyle labels floating near flow control elements. I prefer names b=
ound to them..</blockquote><div>-gmis... </div><div><br></div><div>Hon=
estly, the more I think about it I am not fond of the floating label names =
either. Right now I think this is my preferred syntax: (which was kind of w=
hat I had in mind originally)</div><div><br></div><div class=3D"prettyprint=
" style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(187,=
187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">do</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> oute=
rname </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">for</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> innername</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> i </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"sty=
led-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
i </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #066;" class=3D"styled-by-prettify">100</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">++</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">i</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Foo</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">())</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">continue</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> outername</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// check do-while condition and continue loop if tr=
ue</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
else</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">switch</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Bar</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">())</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">case</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">return</span><font color=
=3D"#000000"><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan></font><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">case</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">break</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> innername</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">// exit for=
loop</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">case</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">3</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>  =
; </span><span style=3D"color: #606;" class=3D"styled-=
by-prettify">LogHit</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">break</span><font color=3D"#000000"><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800=
;" class=3D"styled-by-prettify">// exit switch</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span></font><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">default</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Log=
Miss</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &n=
bsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">while</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">NotDone</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">());</span></div></code></div><div><br></div><div>If the above =
syntax is chosen (or something similar), then the open questions are this:<=
/div><div><ul><li>Is named scope desired as part of this language feature?<=
br></li><li>Is it desirable to be able to name if and else blocks as well? =
If so I believe it definitely belongs in this feature with the same syntax =
as used for loops.</li><li>Is something of the form <i>goto case </i>(as de=
scribed in <span style=3D"line-height: normal;">N3879) </span>des=
ired for switch statement control flow, and does it belong with this featur=
e?</li><li>Are <i>explicit case</i> statements with per-case scooping (as d=
escribed in <span style=3D"line-height: normal;">N3879) desired, and d=
oes it belong with this feature?</span></li></ul><div>For any of these to w=
hich the answer is "yes," a syntax needs to be settled upon (with the excep=
tion of the second bullet point). My revised ideas for a syntax for the fir=
st bullet include:</div></div><div><br></div><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187,=
187); word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">dec=
lscope</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: rgb(136, 0, 0);"><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">somescope</span></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =
name this scope somescope</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">if</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">())</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">break</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: rgb(136, 0, 0);"><span style=3D"color: #000;" class=3D"styled-by=
-prettify">somescope</span></span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">/=
/ jump past end of the curly brace out of thisscope</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br> </span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Bar</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span></div></code></div><div><br></div><div>and =
this would be valid too:</div><div><br></div><div><div class=3D"prettyprint=
" style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(187,=
187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">declscope</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">somesco=
pe</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;=
" class=3D"styled-by-prettify">// name this scope somescope</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Foo</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">())</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">break</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// ju=
mp past end of the curly brace out of thisscope. this cannot break existing=
code because it will only work with scopes declared with the new declscope=
keyword.</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
Bar</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code=
></div><span class=3D"styled-by-prettify" style=3D"font-family: monospace; =
background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);"><br></span>=
However, this will require adding a keyword that could break existing code.=
In the example the keyword is <i>declscope</i> with parenthesis much =
like the <i>decltype </i>keyword new to C++11, but it could also be done wi=
th a keyword <i>scope</i> and no parenthesis.</div><div><br></div><div=
>That said, for the above 4 bullet points, I have no strong personal feelin=
gs on them. I just want to call out that they are open questions.</div><div=
><br></div><div>-Rich</div><br>On Wednesday, April 23, 2014 6:58:11 AM UTC-=
7, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 20=
14-04-22 21:01, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"LMNPImK5LdgJ" onmousedown=3D"this.href=3D'javascript:';return true;=
" onclick=3D"this.href=3D'javascript:';return true;">rich.h....@gmail.com</=
a> wrote:
<br>> One thing N3879 doesn't have is general scope naming as proposed i=
n the
<br>> original post in this thread. [...]
<br>>
<br>> Of course then this would be valid too:
<br>>
<br>> namedscope: // optional
<br>> {
<br>> if (foo())
<br>> break; // break from namedscope (the enc=
losing scope), jump after
<br>> bar() call
<br>> bar();
<br>> }
<br>
<br>This code (assuming all of the above is inside some other loop or a=20
<br>switch) is AFAIK entirely valid right now, with a known meaning. Making=
=20
<br>such a change could therefore break existing code. I don't think we=20
<br>should/can allow this.
<br>
<br>> As would this:
<br>>
<br>> {
<br>> if (foo())
<br>> break; // break from enclosing scope, jump aft=
er bar() call
<br>> bar();
<br>> }
<br>
<br>...and this is even worse!
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3988_5866172.1398275515240--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 23 Apr 2014 20:56:57 +0300
Raw View
On 23 April 2014 20:51, <rich.h.delaney@gmail.com> wrote:
> If the above syntax is chosen (or something similar), then the open
> questions are this:
> Is named scope desired as part of this language feature?
Before we go there, let's ask this one:
Is this language extension worth its cost?
--
---
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/.
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Wed, 23 Apr 2014 21:03:09 +0300
Raw View
------GDIOSE259OPA0CXHUKQCSSYHU0GK02
Content-Type: text/plain; charset=UTF-8
Most likely not.
On April 23, 2014 8:56:57 PM EEST, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>On 23 April 2014 20:51, <rich.h.delaney@gmail.com> wrote:
>> If the above syntax is chosen (or something similar), then the open
>> questions are this:
>> Is named scope desired as part of this language feature?
>
>Before we go there, let's ask this one:
>Is this language extension worth its cost?
>
>--
>
>---
>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/.
--
---
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/.
------GDIOSE259OPA0CXHUKQCSSYHU0GK02
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><p dir=3D"ltr">Most likely not.</p>
<br><br><div class=3D"gmail_quote">On April 23, 2014 8:56:57 PM EEST, Ville=
Voutilainen <ville.voutilainen@gmail.com> wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rg=
b(204, 204, 204); padding-left: 1ex;">
<pre class=3D"k9mail">On 23 April 2014 20:51, <rich.h.delaney@gmail.com=
> wrote:<br /><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt=
1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> If the abo=
ve syntax is chosen (or something similar), then the open<br /> questions a=
re this:<br /> Is named scope desired as part of this language feature?<br =
/></blockquote><br />Before we go there, let's ask this one:<br />Is this l=
anguage extension worth its cost?<br /></pre></blockquote></div></body></ht=
ml>
<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------GDIOSE259OPA0CXHUKQCSSYHU0GK02--
.
Author: rich.h.delaney@gmail.com
Date: Wed, 23 Apr 2014 11:13:51 -0700 (PDT)
Raw View
------=_Part_7835_21866941.1398276831242
Content-Type: text/plain; charset=UTF-8
I think it's important to realize that the language will continue to evolve
one way or another. This being the case, I personally consider named loops
to be a very worthy path of evolution and in keeping with many of the other
newly added features such as strongly-typed enums, and probably more true
to the flavor of C++ than newly added features such as the *auto* keyword
and range based for loops. Furthermore, if it's implemented in it's purest
form (just loop naming), then it's not going to break any existing code;
and it's going to be one of the easiest features for compiler vendors to
implement. I see no reason not to include it with the set of features in
the next major iteration of C++.
On Wednesday, April 23, 2014 11:03:09 AM UTC-7, George Makrydakis wrote:
>
> Most likely not.
>
>
> On April 23, 2014 8:56:57 PM EEST, Ville Voutilainen <
> ville.vo...@gmail.com <javascript:>> wrote:
>>
>> On 23 April 2014 20:51, <rich.h....@gmail.com <javascript:>> wrote:
>>
>>> If the above syntax is chosen (or something similar), then the open
>>> questions are this:
>>> Is named scope desired as part of this language feature?
>>>
>>
>> Before we go there, let's ask this one:
>> Is this language extension worth its cost?
>>
>>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_7835_21866941.1398276831242
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think it's important to realize that the language will c=
ontinue to evolve one way or another. This being the case, I personally con=
sider named loops to be a very worthy path of evolution and in keeping with=
many of the other newly added features such as strongly-typed enums, and p=
robably more true to the flavor of C++ than newly added features such as th=
e <i>auto</i> keyword and range based for loops. Furthermore, if it's =
implemented in it's purest form (just loop naming), then it's not going to =
break any existing code; and it's going to be one of the easiest features f=
or compiler vendors to implement. I see no reason not to include it with th=
e set of features in the next major iteration of C++.<br><br>On Wednesday, =
April 23, 2014 11:03:09 AM UTC-7, George Makrydakis wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div><p dir=3D"ltr">Most likely not.</p>
<br><br><div class=3D"gmail_quote">On April 23, 2014 8:56:57 PM EEST, Ville=
Voutilainen <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"W8i1H2O5qNgJ" onmousedown=3D"this.href=3D'javascript:';return true=
;" onclick=3D"this.href=3D'javascript:';return true;">ville.vo...@gmail.com=
</a>> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0p=
t 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<pre>On 23 April 2014 20:51, <<a href=3D"javascript:" target=3D"_blank"=
gdf-obfuscated-mailto=3D"W8i1H2O5qNgJ" onmousedown=3D"this.href=3D'javascr=
ipt:';return true;" onclick=3D"this.href=3D'javascript:';return true;">rich=
..h....@gmail.com</a>> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0pt 0pt 1ex 0.8ex;border-left:1px solid #729fcf;padding-left:1ex=
"> If the above syntax is chosen (or something similar), then the open<br> =
questions are this:<br> Is named scope desired as part of this language fea=
ture?<br></blockquote><br>Before we go there, let's ask this one:<br>Is thi=
s language extension worth its cost?<br></pre></blockquote></div></div></bl=
ockquote></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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_7835_21866941.1398276831242--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 23 Apr 2014 21:14:05 +0300
Raw View
On 23 April 2014 21:03, George Makrydakis <irrequietus@gmail.com> wrote:
> Most likely not.
For what it's worth, here's a piece of code with a "labeled block":
int main()
{
struct myblock{}; []() /* -> myblock, if you want */ {
// whatever code here
return myblock{};
}();
}
or alternatively
int main()
{
[]() {
struct MY_BLOCK{};
// whatever code here
return MY_BLOCK{}; }();
}
--
---
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/.
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Wed, 23 Apr 2014 11:18:17 -0700 (PDT)
Raw View
------=_Part_5968_3487507.1398277097412
Content-Type: text/plain; charset=UTF-8
The label syntax even works with "anonymous" blocks, so long as named
breaks are always used. e.g., the following is fully backwards-compatible:
label: {
if (condition)
break label; // jumps to end of the named enclosing scope
bar();
}
Granted, I have no idea of what a realistic use case would be here when you
could just use !condition as the test and move the following code into the
if-statement. If it is something that does have a real use case then it's
trivially supported using the far less intrusive and consistent (with some
other languages) label approach.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_5968_3487507.1398277097412
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>The label syntax even works with "anonymous" blocks, =
so long as named breaks are always used. e.g., the following is fully backw=
ards-compatible:<br></div><div><br></div><div> label: {</div><d=
iv> if (condition)</div><div> break =
label; // jumps to end of the named enclosing scope</div><div> =
bar();</div><div> }</div><div><br></div><div>Granted, I =
have no idea of what a realistic use case would be here when you could just=
use !condition as the test and move the following code into the if-stateme=
nt. If it is something that does have a real use case then it's trivially s=
upported using the far less intrusive and consistent (with some other langu=
ages) label approach.</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5968_3487507.1398277097412--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 23 Apr 2014 21:18:44 +0300
Raw View
On 23 April 2014 21:13, <rich.h.delaney@gmail.com> wrote:
> I think it's important to realize that the language will continue to evolve
> one way or another. This being the case, I personally consider named loops
Then it should perhaps evolve into a direction that matters.
> to be a very worthy path of evolution and in keeping with many of the other
> newly added features such as strongly-typed enums, and probably more true to
> the flavor of C++ than newly added features such as the auto keyword and
> range based for loops. Furthermore, if it's implemented in it's purest form
I don't see it being very closely related to things like auto, enum classes and
range-for. It's apparently trying to make already messy code easier to
read, which I doubt
will be the real end result.
> (just loop naming), then it's not going to break any existing code; and it's
> going to be one of the easiest features for compiler vendors to implement. I
> see no reason not to include it with the set of features in the next major
> iteration of C++.
I would recommend implementing it then, first, and finding out what
the implementation
cost seemingly is.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Wed, 23 Apr 2014 21:23:19 +0300
Raw View
--001a11c1271cac813b04f7b9d31f
Content-Type: text/plain; charset=UTF-8
On Wed, Apr 23, 2014 at 9:14 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 23 April 2014 21:03, George Makrydakis <irrequietus@gmail.com> wrote:
> > Most likely not.
>
> For what it's worth, here's a piece of code with a "labeled block":
>
> int main()
> {
> struct myblock{}; []() /* -> myblock, if you want */ {
> // whatever code here
> return myblock{};
> }();
> }
>
> or alternatively
>
> int main()
> {
> []() {
> struct MY_BLOCK{};
> // whatever code here
> return MY_BLOCK{}; }();
> }
>
> Which proves that the "labeled blocks" already exist if a clever use of
lambdas is made as in these examples. Or that somebody simply implements a
function (a really fundamental feature) for when that code block should
live on its own. This is one of the reasons why I disagree with the OP of
this thread; "labeled blocks" would only be a shorthand making difficult to
read code even more difficult to read due to its context sensitivity. It is
not that we use nested scopes all the time either. That kind of speaks for
itself. So, I do not think that a proposal with named statements / blocks
would be actually beneficial to the language, if not for giving a shorthand
of dubious value when code in said "labeled" blocks gets complex beyond
reason. And that can be the case in C++.
--
---
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/.
--001a11c1271cac813b04f7b9d31f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Apr 23, 2014 at 9:14 PM, Ville Voutilainen <span d=
ir=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_bl=
ank">ville.voutilainen@gmail.com</a>></span> wrote:<br><div class=3D"gma=
il_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 April 2014 =
21:03, George Makrydakis <<a href=3D"mailto:irrequietus@gmail.com">irreq=
uietus@gmail.com</a>> wrote:<br>
> Most likely not.<br>
<br>
For what it's worth, here's a piece of code with a "labeled bl=
ock":<br>
<br>
int main()<br>
{<br>
=C2=A0 =C2=A0 struct myblock{}; []() /* -> myblock, if you want */ {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // whatever code here<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return myblock{};<br>
=C2=A0 =C2=A0 }();<br>
}<br>
<br>
or alternatively<br>
<br>
int main()<br>
{<br>
=C2=A0 =C2=A0 []() {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct MY_BLOCK{};<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // whatever code here<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return MY_BLOCK{}; }();<br>
<div class=3D"HOEnZb"><div class=3D"h5">}<br>
<br></div></div></blockquote><div>Which proves that the "labeled block=
s" already exist if a clever use of lambdas is made as in these exampl=
es. Or that somebody simply implements a function (a really fundamental fea=
ture) for when that code block should live on its own. This is one of the r=
easons why I disagree with the OP of this thread; "labeled blocks"=
; would only be a shorthand making difficult to read code even more difficu=
lt to read due to its context sensitivity. It is not that we use nested sco=
pes all the time either. That kind of speaks for itself. So, I do not think=
that a proposal with named statements / blocks would be actually beneficia=
l to the language, if not for giving a shorthand of dubious value when code=
in said "labeled" blocks gets complex beyond reason. And that ca=
n be the case in C++.<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c1271cac813b04f7b9d31f--
.
Author: rich.h.delaney@gmail.com
Date: Wed, 23 Apr 2014 13:40:17 -0700 (PDT)
Raw View
------=_Part_1324_28701798.1398285617214
Content-Type: text/plain; charset=UTF-8
On Wednesday, April 23, 2014 11:18:44 AM UTC-7, Ville Voutilainen wrote:
> On 23 April 2014 21:13, <rich.h....@gmail.com> wrote:
> > I think it's important to realize that the language will continue to
> evolve
> > one way or another. This being the case, I personally consider named
> loops
>
> Then it should perhaps evolve into a direction that matters.
IMO being able to write more readable and cleaner code is a direction that
matters. (and in a sense *anything *added to a Turing Complete language is
syntactic sugar)
Why do I believe this leads to cleaner code?
It encourages the goto-fearing (most programmers) from using flags set in
an inner loop to break out of an outer loop; not only is this ugly code,
it's another needless hurdle for the compiler to optimize away (if it can).
Every loop I've ever written has has a purpose that can be easily described
in English. i.e. outer: "for each line of text" inner: "for each character"
(breaks on newlines), but here the inner needs to needs to set a flag for
outer to check.
Without named loops this is accomplished with flags like this:
for (;;) { // for each line of text in the file
while (!CurCharIsNL()) { // for each character in the line
if (CurCharIsEOF()) {
valid = false;
break;
}
// update code
}
if (!valid)
break;
// more update code
}
CodeToRunBeforeReturning();
With named loops it can be done like this: (Isn't this more readable? And
for that matter self-documenting.)
for LinesInFile (;;) {
while CharsInLine (!CurCharIsNL()) {
if (CurCharIsEOF())
break LinesInFile;
// update code
}
// more update code
}
CodeToRunBeforeReturning();
One might argue: "Well that's what goto is for; and it's not my fault if
some programmers are afraid use it" and it is what goto is for, but in many
ways goto is a catch-all throwback feature that is used when C++ doesn't
really support the control flow you actually want; so why not make C++
support it?
For the sake of completeness, here is what it would look like with goto:
(Isn't this more readable and self-documenting with named loops? Even if
this is your style, many programmers will avoid this at all costs as goto
is often considered a hack)
for (;;) { // for each line of text in the file
while (!CurCharIsNL()) { // for each character in the line
if (CurCharIsEOF())
goto foundEOF;
// update code
}
// more update code
}
foundEOF:
CodeToRunBeforeReturning();
On Wednesday, April 23, 2014 11:18:17 AM UTC-7, Sean Middleditch wrote:
>
> The label syntax even works with "anonymous" blocks, so long as named
> breaks are always used. e.g., the following is fully backwards-compatible:
>
> label: {
> if (condition)
> break label; // jumps to end of the named enclosing scope
> bar();
> }
>
> Granted, I have no idea of what a realistic use case would be here when
> you could just use !condition as the test and move the following code into
> the if-statement. If it is something that does have a real use case then
> it's trivially supported using the far less intrusive and consistent (with
> some other languages) label approach.
>
This is true. And I too would have to struggle to come up with a realistic
usage as it's not something I've ever found myself wishing existed while
writing code.
What I don't like about always having to use named breaks for named blocks
is that it seems inconsistent with behavior that would occur in optionally
naming breaks within loops.
However I think the point may be moot as the feature is probably not needed
as described by the post regarding lambdas to implement named blocks below.
On Wednesday, April 23, 2014 11:14:05 AM UTC-7, Ville Voutilainen wrote:
>
> On 23 April 2014 21:03, George Makrydakis <irreq...@gmail.com> wrote:
> > Most likely not.
>
> For what it's worth, here's a piece of code with a "labeled block":
>
> int main()
> {
> struct myblock{}; []() /* -> myblock, if you want */ {
> // whatever code here
> return myblock{};
> }();
> }
>
> or alternatively
>
> int main()
> {
> []() {
> struct MY_BLOCK{};
> // whatever code here
> return MY_BLOCK{}; }();
> }
The point about using lambdas to implement named scope is valid; TBH I
haven't really used lambdas yet and the thought to use them here hadn't
occurred to me. I'm glad lambdas can do this, because with that in mind, I
see no need to include named scopes in the discussion any longer, and would
be just as happy leaving the other fringe topics out of this discussion as
they seem to distract too much from what is at the heart of the feature,
named loops.
That is: I'd now like to limit what I'm proposing as a contributor here to
the ability to name *for*, *while*, and *do-while* loops, for use with the *break
*and *continue *keywords.
On Wednesday, April 23, 2014 11:23:19 AM UTC-7, George Makrydakis wrote:
>
> On Wed, Apr 23, 2014 at 9:14 PM, Ville Voutilainen <ville.vo...@gmail.com<javascript:>
> > wrote:
>
>> On 23 April 2014 21:03, George Makrydakis <irreq...@gmail.com<javascript:>>
>> wrote:
>> > Most likely not.
>>
>> For what it's worth, here's a piece of code with a "labeled block":
>>
>> int main()
>> {
>> struct myblock{}; []() /* -> myblock, if you want */ {
>> // whatever code here
>> return myblock{};
>> }();
>> }
>>
>> or alternatively
>>
>> int main()
>> {
>> []() {
>> struct MY_BLOCK{};
>> // whatever code here
>> return MY_BLOCK{}; }();
>> }
>>
>> Which proves that the "labeled blocks" already exist if a clever use of
> lambdas is made as in these examples. Or that somebody simply implements a
> function (a really fundamental feature) for when that code block should
> live on its own. This is one of the reasons why I disagree with the OP of
> this thread; "labeled blocks" would only be a shorthand making difficult to
> read code even more difficult to read due to its context sensitivity. It is
> not that we use nested scopes all the time either. That kind of speaks for
> itself. So, I do not think that a proposal with named statements / blocks
> would be actually beneficial to the language, if not for giving a shorthand
> of dubious value when code in said "labeled" blocks gets complex beyond
> reason. And that can be the case in C++.
>
>
On Wednesday, April 23, 2014 11:23:19 AM UTC-7, George Makrydakis wrote:
>
> On Wed, Apr 23, 2014 at 9:14 PM, Ville Voutilainen <ville.vo...@gmail.com<javascript:>
> > wrote:
>
>> On 23 April 2014 21:03, George Makrydakis <irreq...@gmail.com<javascript:>>
>> wrote:
>> > Most likely not.
>>
>> For what it's worth, here's a piece of code with a "labeled block":
>>
>> int main()
>> {
>> struct myblock{}; []() /* -> myblock, if you want */ {
>> // whatever code here
>> return myblock{};
>> }();
>> }
>>
>> or alternatively
>>
>> int main()
>> {
>> []() {
>> struct MY_BLOCK{};
>> // whatever code here
>> return MY_BLOCK{}; }();
>> }
>>
>> Which proves that the "labeled blocks" already exist if a clever use of
> lambdas is made as in these examples. Or that somebody simply implements a
> function (a really fundamental feature) for when that code block should
> live on its own. This is one of the reasons why I disagree with the OP of
> this thread; "labeled blocks" would only be a shorthand making difficult to
> read code even more difficult to read due to its context sensitivity. It is
> not that we use nested scopes all the time either. That kind of speaks for
> itself. So, I do not think that a proposal with named statements / blocks
> would be actually beneficial to the language, if not for giving a shorthand
> of dubious value when code in said "labeled" blocks gets complex beyond
> reason. And that can be the case in C++.
>
>
On Wednesday, April 23, 2014 11:23:19 AM UTC-7, George Makrydakis wrote:
>
> On Wed, Apr 23, 2014 at 9:14 PM, Ville Voutilainen <ville.vo...@gmail.com<javascript:>
> > wrote:
>
>> On 23 April 2014 21:03, George Makrydakis <irreq...@gmail.com<javascript:>>
>> wrote:
>> > Most likely not.
>>
>> For what it's worth, here's a piece of code with a "labeled block":
>>
>> int main()
>> {
>> struct myblock{}; []() /* -> myblock, if you want */ {
>> // whatever code here
>> return myblock{};
>> }();
>> }
>>
>> or alternatively
>>
>> int main()
>> {
>> []() {
>> struct MY_BLOCK{};
>> // whatever code here
>> return MY_BLOCK{}; }();
>> }
>>
>> Which proves that the "labeled blocks" already exist if a clever use of
> lambdas is made as in these examples. Or that somebody simply implements a
> function (a really fundamental feature) for when that code block should
> live on its own. This is one of the reasons why I disagree with the OP of
> this thread; "labeled blocks" would only be a shorthand making difficult to
> read code even more difficult to read due to its context sensitivity. It is
> not that we use nested scopes all the time either. That kind of speaks for
> itself. So, I do not think that a proposal with named statements / blocks
> would be actually beneficial to the language, if not for giving a shorthand
> of dubious value when code in said "labeled" blocks gets complex beyond
> reason. And that can be the case in C++.
>
>
On Wednesday, April 23, 2014 11:23:19 AM UTC-7, George Makrydakis wrote:
>
> On Wed, Apr 23, 2014 at 9:14 PM, Ville Voutilainen <ville.vo...@gmail.com<javascript:>
> > wrote:
>
>> On 23 April 2014 21:03, George Makrydakis <irreq...@gmail.com<javascript:>>
>> wrote:
>> > Most likely not.
>>
>> For what it's worth, here's a piece of code with a "labeled block":
>>
>> int main()
>> {
>> struct myblock{}; []() /* -> myblock, if you want */ {
>> // whatever code here
>> return myblock{};
>> }();
>> }
>>
>> or alternatively
>>
>> int main()
>> {
>> []() {
>> struct MY_BLOCK{};
>> // whatever code here
>> return MY_BLOCK{}; }();
>> }
>>
>> Which proves that the "labeled blocks" already exist if a clever use of
> lambdas is made as in these examples. Or that somebody simply implements a
> function (a really fundamental feature) for when that code block should
> live on its own. This is one of the reasons why I disagree with the OP of
> this thread; "labeled blocks" would only be a shorthand making difficult to
> read code even more difficult to read due to its context sensitivity. It is
> not that we use nested scopes all the time either. That kind of speaks for
> itself. So, I do not think that a proposal with named statements / blocks
> would be actually beneficial to the language, if not for giving a shorthand
> of dubious value when code in said "labeled" blocks gets complex beyond
> reason. And that can be the case in C++.
>
>
On Wednesday, April 23, 2014 11:23:19 AM UTC-7, George Makrydakis wrote:
>
> On Wed, Apr 23, 2014 at 9:14 PM, Ville Voutilainen <ville.vo...@gmail.com<javascript:>
> > wrote:
>
>> On 23 April 2014 21:03, George Makrydakis <irreq...@gmail.com<javascript:>>
>> wrote:
>> > Most likely not.
>>
>> For what it's worth, here's a piece of code with a "labeled block":
>>
>> int main()
>> {
>> struct myblock{}; []() /* -> myblock, if you want */ {
>> // whatever code here
>> return myblock{};
>> }();
>> }
>>
>> or alternatively
>>
>> int main()
>> {
>> []() {
>> struct MY_BLOCK{};
>> // whatever code here
>> return MY_BLOCK{}; }();
>> }
>>
>> Which proves that the "labeled blocks" already exist if a clever use of
> lambdas is made as in these examples. Or that somebody simply implements a
> function (a really fundamental feature) for when that code block should
> live on its own. This is one of the reasons why I disagree with the OP of
> this thread; "labeled blocks" would only be a shorthand making difficult to
> read code even more difficult to read due to its context sensitivity. It is
> not that we use nested scopes all the time either. That kind of speaks for
> itself. So, I do not think that a proposal with named statements / blocks
> would be actually beneficial to the language, if not for giving a shorthand
> of dubious value when code in said "labeled" blocks gets complex beyond
> reason. And that can be the case in C++.
>
>
On Wednesday, April 23, 2014 11:23:19 AM UTC-7, George Makrydakis wrote:
>
> On Wed, Apr 23, 2014 at 9:14 PM, Ville Voutilainen <ville.vo...@gmail.com<javascript:>
> > wrote:
>
>> On 23 April 2014 21:03, George Makrydakis <irreq...@gmail.com<javascript:>>
>> wrote:
>> > Most likely not.
>>
>> For what it's worth, here's a piece of code with a "labeled block":
>>
>> int main()
>> {
>> struct myblock{}; []() /* -> myblock, if you want */ {
>> // whatever code here
>> return myblock{};
>> }();
>> }
>>
>> or alternatively
>>
>> int main()
>> {
>> []() {
>> struct MY_BLOCK{};
>> // whatever code here
>> return MY_BLOCK{}; }();
>> }
>>
>> Which proves that the "labeled blocks" already exist if a clever use of
> lambdas is made as in these examples. Or that somebody simply implements a
> function (a really fundamental feature) for when that code block should
> live on its own. This is one of the reasons why I disagree with the OP of
> this thread; "labeled blocks" would only be a shorthand making difficult to
> read code even more difficult to read due to its context sensitivity. It is
> not that we use nested scopes all the time either. That kind of speaks for
> itself. So, I do not think that a proposal with named statements / blocks
> would be actually beneficial to the language, if not for giving a shorthand
> of dubious value when code in said "labeled" blocks gets complex beyond
> reason. And that can be the case in C++.
>
>
On Wednesday, April 23, 2014 11:23:19 AM UTC-7, George Makrydakis wrote:
>
> On Wed, Apr 23, 2014 at 9:14 PM, Ville Voutilainen <ville.vo...@gmail.com<javascript:>
> > wrote:
>
>> On 23 April 2014 21:03, George Makrydakis <irreq...@gmail.com<javascript:>>
>> wrote:
>> > Most likely not.
>>
>> For what it's worth, here's a piece of code with a "labeled block":
>>
>> int main()
>> {
>> struct myblock{}; []() /* -> myblock, if you want */ {
>> // whatever code here
>> return myblock{};
>> }();
>> }
>>
>> or alternatively
>>
>> int main()
>> {
>> []() {
>> struct MY_BLOCK{};
>> // whatever code here
>> return MY_BLOCK{}; }();
>> }
>>
>> Which proves that the "labeled blocks" already exist if a clever use of
> lambdas is made as in these examples. Or that somebody simply implements a
> function (a really fundamental feature) for when that code block should
> live on its own. This is one of the reasons why I disagree with the OP of
> this thread; "labeled blocks" would only be a shorthand making difficult to
> read code even more difficult to read due to its context sensitivity. It is
> not that we use nested scopes all the time either. That kind of speaks for
> itself. So, I do not think that a proposal with named statements / blocks
> would be actually beneficial to the language, if not for giving a shorthand
> of dubious value when code in said "labeled" blocks gets complex beyond
> reason. And that can be the case in C++.
>
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1324_28701798.1398285617214
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>On Wednesday, April 23, 2014 11:18:44 AM UTC-7, Ville=
Voutilainen wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204,=
204, 204); border-left-style: solid; padding-left: 1ex;">On 23 April 2014 =
21:13, <<a target=3D"_blank" gdf-obfuscated-mailto=3D"Wi4tK0MHE9wJ=
" style=3D"color: rgb(102, 17, 204);">rich.h....@gmail.com</a>> wrote:&n=
bsp;<br>> I think it's important to realize that the language will conti=
nue to evolve <br>> one way or another. This being the case, I pers=
onally consider named loops <br><br>Then it should perhaps evolve into=
a direction that matters. </blockquote><div><br></div><div>IMO being =
able to write more readable and cleaner code is a direction that matters. (=
and in a sense <i>anything </i>added to a Turing Complete language is synta=
ctic sugar)</div><div><br></div><div>Why do I believe this leads to cleaner=
code?</div><div>It encourages the goto-fearing (most programmers) from usi=
ng flags set in an inner loop to break out of an outer loop; not only is th=
is ugly code, it's another needless hurdle for the compiler to optimize awa=
y (if it can).</div><div>Every loop I've ever written has has a purpose tha=
t can be easily described in English. i.e. outer: "for each line of text" i=
nner: "for each character" (breaks on newlines), but here the inner needs t=
o needs to set a flag for outer to check.</div><div><br></div><div>Without =
named loops this is accomplished with flags like this:</div><div><br></div>=
<div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); b=
order: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><font color=3D"#000088"><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">for</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span></font><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(;;)</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-p=
rettify">// for each line of text in the file</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br> </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">while</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(!</span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">CurCharIsNL</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">())</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #800;" class=3D"styled-by-prettify">// for each chara=
cter in the line</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br> </span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">if</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">CurCharIsEOF=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">())</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br> valid </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">false</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">break</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br> </span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">// update code </span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(!</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">valid</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">break</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// =
more update code</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #606;" class=3D"styled-by-prettify">CodeToRunBefore=
Returning</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
);</span></div></code></div><div><br></div><div>With named loops it can be =
done like this: (Isn't this more readable? And for that matter self-documen=
ting.)</div><div><br></div><div class=3D"prettyprint" style=3D"background-c=
olor: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: =
break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">for</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">LinesInFile</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">(;;)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">while</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">CharsIn=
Line</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(!</span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">CurCharIsNL</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">())</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br> </span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"styled-by=
-prettify">CurCharIsEOF</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">())</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">break</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pre=
ttify">LinesInFile</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">// update code </span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br> </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br> </span><span style=3D"color: #800;" class=3D"styled-by-prett=
ify">// more update code</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #606;" class=3D"styled-by-prettify">CodeToR=
unBeforeReturning</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">();</span></div></code></div><div><span class=3D"styled-by-prettify"=
style=3D"font-family: monospace; background-color: rgb(250, 250, 250); col=
or: rgb(102, 102, 0);"><br></span></div><div>One might argue: "Well that's =
what goto is for; and it's not my fault if some programmers are afraid use =
it" and it is what goto is for, but in many ways goto is a catch-all throwb=
ack feature that is used when C++ doesn't really support the control flow y=
ou actually want; so why not make C++ support it?<br></div><div><br></div><=
div>For the sake of completeness, here is what it would look like with goto=
: (Isn't this more readable and self-documenting with named loops? Even if =
this is your style, many programmers will avoid this at all costs as goto i=
s often considered a hack)</div><div><br></div><div><div class=3D"prettypri=
nt" style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(18=
7, 187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div clas=
s=3D"subprettyprint"><font color=3D"#000088"><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">for</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span></font><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(;;)</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #800;" class=3D"styled-by-prettify">// for each li=
ne of text in the file</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br> </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">while</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
!</span><span style=3D"color: #606;" class=3D"styled-by-prettify">CurCharIs=
NL</span><span style=3D"color: #660;" class=3D"styled-by-prettify">())</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #80=
0;" class=3D"styled-by-prettify">// for each character in the line</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">if</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">CurCharIsEOF</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">())</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br> </span><font colo=
r=3D"#000088"><span style=3D"color: #008;" class=3D"styled-by-prettify">got=
o</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
/font><span style=3D"color: #000;" class=3D"styled-by-prettify">foundEOF</s=
pan><font color=3D"#666600"><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span></font><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br> </span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">// update code </span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br> </span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">// more update code</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>foundEOF</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #606;" class=3D"styled-by-prettify">Co=
deToRunBeforeReturning</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">();</span></div></code></div></div><div><br></div><div>On Wedne=
sday, April 23, 2014 11:18:17 AM UTC-7, Sean Middleditch wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width=
: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; pad=
ding-left: 1ex;"><div dir=3D"ltr"><div>The label syntax even works with "an=
onymous" blocks, so long as named breaks are always used. e.g., the followi=
ng is fully backwards-compatible:<br></div><div><br></div><div>  =
;label: {</div><div> if (condition)</div><div> &nb=
sp; break label; // jumps to end of the named enclosing scope</div><=
div> bar();</div><div> }</div><div><br></div=
><div>Granted, I have no idea of what a realistic use case would be here wh=
en you could just use !condition as the test and move the following code in=
to the if-statement. If it is something that does have a real use case then=
it's trivially supported using the far less intrusive and consistent (with=
some other languages) label approach.</div></div></blockquote><div><br></d=
iv><div>This is true. And I too would have to struggle to come up with a re=
alistic usage as it's not something I've ever found myself wishing existed =
while writing code.</div></div><div>What I don't like about always having t=
o use named breaks for named blocks is that it seems inconsistent with beha=
vior that would occur in optionally naming breaks within loops.</div><div>H=
owever I think the point may be moot as the feature is probably not needed =
as described by the post regarding lambdas to implement named blocks below.=
</div><div><br></div><div>On Wednesday, April 23, 2014 11:14:05 AM UTC-7, V=
ille Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, =
204); border-left-style: solid; padding-left: 1ex;">On 23 April 2014 21:03,=
George Makrydakis <<a target=3D"_blank" gdf-obfuscated-mailto=3D"vVdqtr=
0pPyAJ" style=3D"color: rgb(102, 17, 204);">irreq...@gmail.com</a>> wrot=
e: <br>> Most likely not. <br><br>For what it's worth, here's =
a piece of code with a "labeled block": <br><br>int main() <br>{&=
nbsp;<br> struct myblock{}; []() /* -> myblock, if you want=
*/ { <br> // whatever code here <br>&=
nbsp; return myblock{}; <br> }();&nb=
sp;<br>} <br><br>or alternatively <br><br>int main() <br>{&n=
bsp;<br> []() { <br> struct MY=
_BLOCK{}; <br> // whatever code here <=
br> return MY_BLOCK{}; }(); <br>} </bl=
ockquote></div><div><br></div><div>The point about using lambdas to impleme=
nt named scope is valid; TBH I haven't really used lambdas yet and the thou=
ght to use them here hadn't occurred to me. I'm glad lambdas can do this, b=
ecause with that in mind, I see no need to include named scopes in the disc=
ussion any longer, and would be just as happy leaving the other fringe topi=
cs out of this discussion as they seem to distract too much from what is at=
the heart of the feature, named loops.</div><div><br></div><div>That is: <=
span style=3D"background-color: rgb(255, 229, 153);">I'd now like to limit =
what I'm proposing as a contributor here to the ability to name<font color=
=3D"#0000ff"> <i>for</i></font>, <i><font color=3D"#0000ff">while</font></i=
>, and <i><font color=3D"#0000ff">do-while</font></i> loops, for use with t=
he <i><font color=3D"#0000ff">break</font> </i>and <i><font color=3D"#0000f=
f">continue</font> </i>keywords.</span></div><br>On Wednesday, April 23, 20=
14 11:23:19 AM UTC-7, George Makrydakis wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr">On Wed, Apr 23, 2014 at 9:14 PM, Ville Vou=
tilainen <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"F5qCC3Rqm84J" onmousedown=3D"this.href=3D'javascript=
:';return true;" onclick=3D"this.href=3D'javascript:';return true;">ville.v=
o...@gmail.com</a>></span> wrote:<br><div>
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 April 2014 =
21:03, George Makrydakis <<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"F5qCC3Rqm84J" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">irreq...@=
gmail.com</a>> wrote:<br>
> Most likely not.<br>
<br>
For what it's worth, here's a piece of code with a "labeled block":<br>
<br>
int main()<br>
{<br>
struct myblock{}; []() /* -> myblock, if you want */ {<br>
// whatever code here<br>
return myblock{};<br>
}();<br>
}<br>
<br>
or alternatively<br>
<br>
int main()<br>
{<br>
[]() {<br>
struct MY_BLOCK{};<br>
// whatever code here<br>
return MY_BLOCK{}; }();<br>
<div><div>}<br>
<br></div></div></blockquote><div>Which proves that the "labeled blocks" al=
ready exist if a clever use of lambdas is made as in these examples. Or tha=
t somebody simply implements a function (a really fundamental feature) for =
when that code block should live on its own. This is one of the reasons why=
I disagree with the OP of this thread; "labeled blocks" would only be a sh=
orthand making difficult to read code even more difficult to read due to it=
s context sensitivity. It is not that we use nested scopes all the time eit=
her. That kind of speaks for itself. So, I do not think that a proposal wit=
h named statements / blocks would be actually beneficial to the language, i=
f not for giving a shorthand of dubious value when code in said "labeled" b=
locks gets complex beyond reason. And that can be the case in C++.<br>
</div></div><br></div></div>
</blockquote><br>On Wednesday, April 23, 2014 11:23:19 AM UTC-7, George Mak=
rydakis wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Wed, Apr 23, 2014 at 9:14 PM, Ville Voutilainen <span dir=3D"ltr"><<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"F5qCC3Rqm=
84J" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">ville.vo...@gmail.com</a>></span> wr=
ote:<br><div>
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 April 2014 =
21:03, George Makrydakis <<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"F5qCC3Rqm84J" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">irreq...@=
gmail.com</a>> wrote:<br>
> Most likely not.<br>
<br>
For what it's worth, here's a piece of code with a "labeled block":<br>
<br>
int main()<br>
{<br>
struct myblock{}; []() /* -> myblock, if you want */ {<br>
// whatever code here<br>
return myblock{};<br>
}();<br>
}<br>
<br>
or alternatively<br>
<br>
int main()<br>
{<br>
[]() {<br>
struct MY_BLOCK{};<br>
// whatever code here<br>
return MY_BLOCK{}; }();<br>
<div><div>}<br>
<br></div></div></blockquote><div>Which proves that the "labeled blocks" al=
ready exist if a clever use of lambdas is made as in these examples. Or tha=
t somebody simply implements a function (a really fundamental feature) for =
when that code block should live on its own. This is one of the reasons why=
I disagree with the OP of this thread; "labeled blocks" would only be a sh=
orthand making difficult to read code even more difficult to read due to it=
s context sensitivity. It is not that we use nested scopes all the time eit=
her. That kind of speaks for itself. So, I do not think that a proposal wit=
h named statements / blocks would be actually beneficial to the language, i=
f not for giving a shorthand of dubious value when code in said "labeled" b=
locks gets complex beyond reason. And that can be the case in C++.<br>
</div></div><br></div></div>
</blockquote><br>On Wednesday, April 23, 2014 11:23:19 AM UTC-7, George Mak=
rydakis wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Wed, Apr 23, 2014 at 9:14 PM, Ville Voutilainen <span dir=3D"ltr"><<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"F5qCC3Rqm=
84J" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">ville.vo...@gmail.com</a>></span> wr=
ote:<br><div>
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 April 2014 =
21:03, George Makrydakis <<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"F5qCC3Rqm84J" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">irreq...@=
gmail.com</a>> wrote:<br>
> Most likely not.<br>
<br>
For what it's worth, here's a piece of code with a "labeled block":<br>
<br>
int main()<br>
{<br>
struct myblock{}; []() /* -> myblock, if you want */ {<br>
// whatever code here<br>
return myblock{};<br>
}();<br>
}<br>
<br>
or alternatively<br>
<br>
int main()<br>
{<br>
[]() {<br>
struct MY_BLOCK{};<br>
// whatever code here<br>
return MY_BLOCK{}; }();<br>
<div><div>}<br>
<br></div></div></blockquote><div>Which proves that the "labeled blocks" al=
ready exist if a clever use of lambdas is made as in these examples. Or tha=
t somebody simply implements a function (a really fundamental feature) for =
when that code block should live on its own. This is one of the reasons why=
I disagree with the OP of this thread; "labeled blocks" would only be a sh=
orthand making difficult to read code even more difficult to read due to it=
s context sensitivity. It is not that we use nested scopes all the time eit=
her. That kind of speaks for itself. So, I do not think that a proposal wit=
h named statements / blocks would be actually beneficial to the language, i=
f not for giving a shorthand of dubious value when code in said "labeled" b=
locks gets complex beyond reason. And that can be the case in C++.<br>
</div></div><br></div></div>
</blockquote><br>On Wednesday, April 23, 2014 11:23:19 AM UTC-7, George Mak=
rydakis wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Wed, Apr 23, 2014 at 9:14 PM, Ville Voutilainen <span dir=3D"ltr"><<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"F5qCC3Rqm=
84J" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">ville.vo...@gmail.com</a>></span> wr=
ote:<br><div>
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 April 2014 =
21:03, George Makrydakis <<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"F5qCC3Rqm84J" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">irreq...@=
gmail.com</a>> wrote:<br>
> Most likely not.<br>
<br>
For what it's worth, here's a piece of code with a "labeled block":<br>
<br>
int main()<br>
{<br>
struct myblock{}; []() /* -> myblock, if you want */ {<br>
// whatever code here<br>
return myblock{};<br>
}();<br>
}<br>
<br>
or alternatively<br>
<br>
int main()<br>
{<br>
[]() {<br>
struct MY_BLOCK{};<br>
// whatever code here<br>
return MY_BLOCK{}; }();<br>
<div><div>}<br>
<br></div></div></blockquote><div>Which proves that the "labeled blocks" al=
ready exist if a clever use of lambdas is made as in these examples. Or tha=
t somebody simply implements a function (a really fundamental feature) for =
when that code block should live on its own. This is one of the reasons why=
I disagree with the OP of this thread; "labeled blocks" would only be a sh=
orthand making difficult to read code even more difficult to read due to it=
s context sensitivity. It is not that we use nested scopes all the time eit=
her. That kind of speaks for itself. So, I do not think that a proposal wit=
h named statements / blocks would be actually beneficial to the language, i=
f not for giving a shorthand of dubious value when code in said "labeled" b=
locks gets complex beyond reason. And that can be the case in C++.<br>
</div></div><br></div></div>
</blockquote><br>On Wednesday, April 23, 2014 11:23:19 AM UTC-7, George Mak=
rydakis wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Wed, Apr 23, 2014 at 9:14 PM, Ville Voutilainen <span dir=3D"ltr"><<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"F5qCC3Rqm=
84J" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">ville.vo...@gmail.com</a>></span> wr=
ote:<br><div>
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 April 2014 =
21:03, George Makrydakis <<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"F5qCC3Rqm84J" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">irreq...@=
gmail.com</a>> wrote:<br>
> Most likely not.<br>
<br>
For what it's worth, here's a piece of code with a "labeled block":<br>
<br>
int main()<br>
{<br>
struct myblock{}; []() /* -> myblock, if you want */ {<br>
// whatever code here<br>
return myblock{};<br>
}();<br>
}<br>
<br>
or alternatively<br>
<br>
int main()<br>
{<br>
[]() {<br>
struct MY_BLOCK{};<br>
// whatever code here<br>
return MY_BLOCK{}; }();<br>
<div><div>}<br>
<br></div></div></blockquote><div>Which proves that the "labeled blocks" al=
ready exist if a clever use of lambdas is made as in these examples. Or tha=
t somebody simply implements a function (a really fundamental feature) for =
when that code block should live on its own. This is one of the reasons why=
I disagree with the OP of this thread; "labeled blocks" would only be a sh=
orthand making difficult to read code even more difficult to read due to it=
s context sensitivity. It is not that we use nested scopes all the time eit=
her. That kind of speaks for itself. So, I do not think that a proposal wit=
h named statements / blocks would be actually beneficial to the language, i=
f not for giving a shorthand of dubious value when code in said "labeled" b=
locks gets complex beyond reason. And that can be the case in C++.<br>
</div></div><br></div></div>
</blockquote><br>On Wednesday, April 23, 2014 11:23:19 AM UTC-7, George Mak=
rydakis wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Wed, Apr 23, 2014 at 9:14 PM, Ville Voutilainen <span dir=3D"ltr"><<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"F5qCC3Rqm=
84J" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">ville.vo...@gmail.com</a>></span> wr=
ote:<br><div>
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 April 2014 =
21:03, George Makrydakis <<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"F5qCC3Rqm84J" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">irreq...@=
gmail.com</a>> wrote:<br>
> Most likely not.<br>
<br>
For what it's worth, here's a piece of code with a "labeled block":<br>
<br>
int main()<br>
{<br>
struct myblock{}; []() /* -> myblock, if you want */ {<br>
// whatever code here<br>
return myblock{};<br>
}();<br>
}<br>
<br>
or alternatively<br>
<br>
int main()<br>
{<br>
[]() {<br>
struct MY_BLOCK{};<br>
// whatever code here<br>
return MY_BLOCK{}; }();<br>
<div><div>}<br>
<br></div></div></blockquote><div>Which proves that the "labeled blocks" al=
ready exist if a clever use of lambdas is made as in these examples. Or tha=
t somebody simply implements a function (a really fundamental feature) for =
when that code block should live on its own. This is one of the reasons why=
I disagree with the OP of this thread; "labeled blocks" would only be a sh=
orthand making difficult to read code even more difficult to read due to it=
s context sensitivity. It is not that we use nested scopes all the time eit=
her. That kind of speaks for itself. So, I do not think that a proposal wit=
h named statements / blocks would be actually beneficial to the language, i=
f not for giving a shorthand of dubious value when code in said "labeled" b=
locks gets complex beyond reason. And that can be the case in C++.<br>
</div></div><br></div></div>
</blockquote><br>On Wednesday, April 23, 2014 11:23:19 AM UTC-7, George Mak=
rydakis wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Wed, Apr 23, 2014 at 9:14 PM, Ville Voutilainen <span dir=3D"ltr"><<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"F5qCC3Rqm=
84J" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this=
..href=3D'javascript:';return true;">ville.vo...@gmail.com</a>></span> wr=
ote:<br><div>
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 23 April 2014 =
21:03, George Makrydakis <<a href=3D"javascript:" target=3D"_blank" gdf-=
obfuscated-mailto=3D"F5qCC3Rqm84J" onmousedown=3D"this.href=3D'javascript:'=
;return true;" onclick=3D"this.href=3D'javascript:';return true;">irreq...@=
gmail.com</a>> wrote:<br>
> Most likely not.<br>
<br>
For what it's worth, here's a piece of code with a "labeled block":<br>
<br>
int main()<br>
{<br>
struct myblock{}; []() /* -> myblock, if you want */ {<br>
// whatever code here<br>
return myblock{};<br>
}();<br>
}<br>
<br>
or alternatively<br>
<br>
int main()<br>
{<br>
[]() {<br>
struct MY_BLOCK{};<br>
// whatever code here<br>
return MY_BLOCK{}; }();<br>
<div><div>}<br>
<br></div></div></blockquote><div>Which proves that the "labeled blocks" al=
ready exist if a clever use of lambdas is made as in these examples. Or tha=
t somebody simply implements a function (a really fundamental feature) for =
when that code block should live on its own. This is one of the reasons why=
I disagree with the OP of this thread; "labeled blocks" would only be a sh=
orthand making difficult to read code even more difficult to read due to it=
s context sensitivity. It is not that we use nested scopes all the time eit=
her. That kind of speaks for itself. So, I do not think that a proposal wit=
h named statements / blocks would be actually beneficial to the language, i=
f not for giving a shorthand of dubious value when code in said "labeled" b=
locks gets complex beyond reason. And that can be the case in C++.<br>
</div></div><br></div></div>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1324_28701798.1398285617214--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 24 Apr 2014 00:01:57 +0300
Raw View
On 23 April 2014 23:40, <rich.h.delaney@gmail.com> wrote:
> On Wednesday, April 23, 2014 11:18:44 AM UTC-7, Ville Voutilainen wrote:
>> > I think it's important to realize that the language will continue to
>> > evolve
>> > one way or another. This being the case, I personally consider named
>> > loops
>> Then it should perhaps evolve into a direction that matters.
> IMO being able to write more readable and cleaner code is a direction that
> matters. (and in a sense anything added to a Turing Complete language is
That's assuming that the end result is more readable and cleaner.
> for LinesInFile (;;) {
> while CharsInLine (!CurCharIsNL()) {
> if (CurCharIsEOF())
> break LinesInFile;
> // update code
> }
> // more update code
> }
> CodeToRunBeforeReturning();
> for (;;) { // for each line of text in the file
> while (!CurCharIsNL()) { // for each character in the line
> if (CurCharIsEOF())
> goto foundEOF;
> // update code
> }
> // more update code
> }
> foundEOF:
> CodeToRunBeforeReturning();
Why didn't you write
for /* LinesInFile */ (;;)
while /*CharsInLine */ (!CurCharIsNL()) {
if (CurCharIsEOF())
goto foundEOF;
// update code
}
// more update code
}
foundEOF:
CodeToRunBeforeReturning();
for a fair comparison? ;)
Now, in order to see where the code jumps, with these named loops I have to go
back and find the right named loop, then I have to look at where it
ends, and then
I'll know where it ends up. With the label, I can just search for the
targeted label and
I'll see where it ends up.
Perhaps what we should do is add goto_forward and goto_backward, thus
avoiding the guessing which direction a goto jumps? I would think _that_ is
easier to implement, and the labels are still easy to find, they stand out.
--
---
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/.
.
Author: gmisocpp@gmail.com
Date: Wed, 23 Apr 2014 17:13:12 -0700 (PDT)
Raw View
------=_Part_8499_25636565.1398298393008
Content-Type: text/plain; charset=UTF-8
On Thursday, April 24, 2014 9:01:57 AM UTC+12, Ville Voutilainen wrote:
>
> On 23 April 2014 23:40, <rich.h....@gmail.com <javascript:>> wrote:
> > On Wednesday, April 23, 2014 11:18:44 AM UTC-7, Ville Voutilainen wrote:
> >> > I think it's important to realize that the language will continue to
> >> > evolve
> >> > one way or another. This being the case, I personally consider named
> >> > loops
> >> Then it should perhaps evolve into a direction that matters.
> > IMO being able to write more readable and cleaner code is a direction
> that
> > matters. (and in a sense anything added to a Turing Complete language is
>
> That's assuming that the end result is more readable and cleaner.
>
> > for LinesInFile (;;) {
> > while CharsInLine (!CurCharIsNL()) {
> > if (CurCharIsEOF())
> > break LinesInFile;
> > // update code
> > }
> > // more update code
> > }
> > CodeToRunBeforeReturning();
>
> > for (;;) { // for each line of text in the file
> > while (!CurCharIsNL()) { // for each character in the line
> > if (CurCharIsEOF())
> > goto foundEOF;
> > // update code
> > }
> > // more update code
> > }
> > foundEOF:
> > CodeToRunBeforeReturning();
>
> Why didn't you write
>
> for /* LinesInFile */ (;;)
> while /*CharsInLine */ (!CurCharIsNL()) {
> if (CurCharIsEOF())
> goto foundEOF;
> // update code
> }
> // more update code
> }
> foundEOF:
> CodeToRunBeforeReturning();
>
> for a fair comparison? ;)
>
> Now, in order to see where the code jumps, with these named loops I have
> to go
> back and find the right named loop, then I have to look at where it
> ends, and then
> I'll know where it ends up. With the label, I can just search for the
> targeted label and
> I'll see where it ends up.
>
> Perhaps what we should do is add goto_forward and goto_backward, thus
> avoiding the guessing which direction a goto jumps? I would think _that_
> is
> easier to implement, and the labels are still easy to find, they stand
> out.
>
But you need two labels to provide continue and break. With named loops,
you need just one name.
Plus your labels have infinite scope. With named loops, the scope of it's
name ends with it's closing brace.
I also think goto just has such a bad wrap people avoid it even when it's
useful to get out simply of a deeply nested loops.
Named loops would make such breaks more acceptable.
Potentially referencing a variable in loop's scope is another possibility.
I'm not saying any of these are must have features, but basic labels don't
seem to offer any of these possibilities.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_8499_25636565.1398298393008
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, April 24, 2014 9:01:57 AM UTC+12, Vil=
le Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px=
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;">On 23 April 2014 23:40, &=
nbsp;<<a onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=3D"=
_blank" gdf-obfuscated-mailto=3D"KN8d_oTL-fYJ">rich.h....@gmail.com</a>>=
wrote:
<br>> On Wednesday, April 23, 2014 11:18:44 AM UTC-7, Ville Voutilainen =
wrote:
<br>>> > I think it's important to realize that the language will =
continue to
<br>>> > evolve
<br>>> > one way or another. This being the case, I personally con=
sider named
<br>>> > loops
<br>>> Then it should perhaps evolve into a direction that matters.
<br>> IMO being able to write more readable and cleaner code is a direct=
ion that
<br>> matters. (and in a sense anything added to a Turing Complete langu=
age is
<br>
<br>That's assuming that the end result is more readable and cleaner.
<br>
<br>> for LinesInFile (;;) {
<br>> while CharsInLine (!CurCharIsNL()) {
<br>> if (CurCharIsEOF())
<br>> break LinesInFile;
<br>> // update code
<br>> }
<br>> // more update code
<br>> }
<br>> CodeToRunBeforeReturning();
<br>
<br>> for (;;) { // for each line of text in the file
<br>> while (!CurCharIsNL()) { // for each character in the line
<br>> if (CurCharIsEOF())
<br>> goto foundEOF;
<br>> // update code
<br>> }
<br>> // more update code
<br>> }
<br>> foundEOF:
<br>> CodeToRunBeforeReturning();
<br>
<br>Why didn't you write
<br>
<br>for /* LinesInFile */ (;;)
<br> while /*CharsInLine */ (!CurCharIsNL()) {
<br> if (CurCharIsEOF())
<br> goto foundEOF;
<br> // update code
<br> }
<br> // more update code
<br>}
<br>foundEOF:
<br> CodeToRunBeforeReturning();
<br>
<br>for a fair comparison? ;)
<br>
<br>Now, in order to see where the code jumps, with these named loops I hav=
e to go
<br>back and find the right named loop, then I have to look at where it
<br>ends, and then
<br>I'll know where it ends up. With the label, I can just search for the
<br>targeted label and
<br>I'll see where it ends up.
<br>
<br>Perhaps what we should do is add goto_forward and goto_backward, thus
<br>avoiding the guessing which direction a goto jumps? I would think _that=
_ is
<br>easier to implement, and the labels are still easy to find, they stand =
out.
<br></blockquote><div><br></div><div>But you need two labels to provide con=
tinue and break. With named loops, you need just one name.</div><div>P=
lus your labels have infinite scope. With named loops, =
the scope of it's name ends with it's closing brace.</div><div>I also think=
goto just has such a bad wrap people avoid it even when it's useful to&nbs=
p;get out simply of a deeply nested loops.</div><div>Named loops =
would make such breaks more acceptable.</div><div>Potentially referenc=
ing a variable in loop's scope is another possibility.</div><div><br></div>=
<div>I'm not saying any of these are must have features, but basic lab=
els don't seem to offer any of these possibilities.</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_8499_25636565.1398298393008--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Wed, 23 Apr 2014 19:48:59 -0500
Raw View
--e89a8f3babd3521a8e04f7bf3986
Content-Type: text/plain; charset=UTF-8
On 23 April 2014 19:13, <gmisocpp@gmail.com> wrote:
> I also think goto just has such a bad wrap people avoid it even when it's
> useful to get out simply of a deeply nested loops.
>
In other words, goto encourages writing deeply nested loops.
I don't see the good in adding features to encourage this.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--e89a8f3babd3521a8e04f7bf3986
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 23 April 2014 19:13, <span dir=3D"ltr"><<a href=3D"=
mailto:gmisocpp@gmail.com" target=3D"_blank">gmisocpp@gmail.com</a>></sp=
an> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
<div dir=3D"ltr">I also think goto just has such a bad wrap people avoid it=
even when it's useful to=C2=A0get=C2=A0out=C2=A0simply of a deeply nes=
ted loops.<br></div></blockquote><div><br></div><div>In other words, goto e=
ncourages writing deeply nested loops.</div>
<div><br></div><div>I don't see the good in adding features to encourag=
e this.</div></div>-- <br>=C2=A0Nevin ":-)" Liber=C2=A0 <mailt=
o:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilove=
rlord.com</a>>=C2=A0 (847) 691-1404
</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--e89a8f3babd3521a8e04f7bf3986--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Thu, 24 Apr 2014 08:18:48 +0200
Raw View
There were a lot of different ideas considered like this one, and many
others, in preparing N3879. Ultimately, I decided to stick with
exactly and only what has been tested and proven by the millions of
programmers that use Java and C#. Anything more, and the proposal
loses that appeal to existing practice.
On Wed, Apr 23, 2014 at 7:56 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 23 April 2014 20:51, <rich.h.delaney@gmail.com> wrote:
>> If the above syntax is chosen (or something similar), then the open
>> questions are this:
>> Is named scope desired as part of this language feature?
>
> Before we go there, let's ask this one:
> Is this language extension worth its cost?
>
> --
>
> ---
> 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/.
--
---
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/.
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Thu, 24 Apr 2014 11:47:54 +0300
Raw View
--001a11c1271cab2b3f04f7c5e7bb
Content-Type: text/plain; charset=UTF-8
While I can understand the reasoning for the "explicit switch" in N3879, I
cannot come to terms with why named controlled structures provide any
benefit other than encouraging code that is more akin to poetic prose than
aiming towards a technical solution.
The "explicit" switch variant is declarative of a specific programmer
intent and therefore it is not just a shorthand. Named control structures
on the other hands are shorthands for goto occultation that are likely to
lead C++ in an even more complicated "goto algebra".
Unlike what most think, code is not poetry and attempts to enforce such a
policy result in increasing technical debt.
On Thu, Apr 24, 2014 at 9:18 AM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:
> There were a lot of different ideas considered like this one, and many
> others, in preparing N3879. Ultimately, I decided to stick with
> exactly and only what has been tested and proven by the millions of
> programmers that use Java and C#. Anything more, and the proposal
> loses that appeal to existing practice.
>
>
> On Wed, Apr 23, 2014 at 7:56 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
> > On 23 April 2014 20:51, <rich.h.delaney@gmail.com> wrote:
> >> If the above syntax is chosen (or something similar), then the open
> >> questions are this:
> >> Is named scope desired as part of this language feature?
> >
> > Before we go there, let's ask this one:
> > Is this language extension worth its cost?
> >
> > --
> >
> > ---
> > 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/.
>
> --
>
> ---
> 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/.
>
--
---
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/.
--001a11c1271cab2b3f04f7c5e7bb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">While I can understand the reasoning for the "explici=
t switch" in N3879, I cannot come to terms with why named controlled s=
tructures provide any benefit other than encouraging code that is more akin=
to poetic prose than aiming towards a technical solution.<br>
<br>The "explicit" switch variant is declarative of a specific pr=
ogrammer intent and therefore it is not just a shorthand. Named control str=
uctures on the other hands are shorthands for goto occultation that are lik=
ely to lead C++ in an even more complicated "goto algebra".<br>
<br>Unlike what most think, code is not poetry and attempts to enforce such=
a policy result in increasing technical debt.<br></div><div class=3D"gmail=
_extra"><br><br><div class=3D"gmail_quote">On Thu, Apr 24, 2014 at 9:18 AM,=
Andrew Tomazos <span dir=3D"ltr"><<a href=3D"mailto:andrewtomazos@gmail=
..com" target=3D"_blank">andrewtomazos@gmail.com</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">There were a lot of different ideas consider=
ed like this one, and many<br>
others, in preparing N3879. =C2=A0Ultimately, I decided to stick with<br>
exactly and only what has been tested and proven by the millions of<br>
programmers that use Java and C#. =C2=A0Anything more, and the proposal<br>
loses that appeal to existing practice.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
On Wed, Apr 23, 2014 at 7:56 PM, Ville Voutilainen<br>
<<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.=
com</a>> wrote:<br>
> On 23 April 2014 20:51, =C2=A0<<a href=3D"mailto:rich.h.delaney@gma=
il.com">rich.h.delaney@gmail.com</a>> wrote:<br>
>> If the above syntax is chosen (or something similar), then the ope=
n<br>
>> questions are this:<br>
>> Is named scope desired as part of this language feature?<br>
><br>
> Before we go there, let's ask this one:<br>
> Is this language extension worth its cost?<br>
><br>
> --<br>
><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/" target=3D"_blank">http://groups.google.com/a/isocpp.or=
g/group/std-proposals/</a>.<br>
<br>
--<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 <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c1271cab2b3f04f7c5e7bb--
.
Author: Farid Mehrabi <farid.mehrabi@gmail.com>
Date: Thu, 24 Apr 2014 21:25:15 +0430
Raw View
--047d7b86dc40ce225204f7ccb77a
Content-Type: text/plain; charset=UTF-8
I want to add just one note about existing practice. Although it is not
generally considered in software domain, HDLs(both verilog and VHDL) have
already implemented named block statements which are accessible through
dot-separated names.
regards,
FM.
On Thu, Apr 24, 2014 at 1:17 PM, George Makrydakis <irrequietus@gmail.com>wrote:
> While I can understand the reasoning for the "explicit switch" in N3879, I
> cannot come to terms with why named controlled structures provide any
> benefit other than encouraging code that is more akin to poetic prose than
> aiming towards a technical solution.
>
> The "explicit" switch variant is declarative of a specific programmer
> intent and therefore it is not just a shorthand. Named control structures
> on the other hands are shorthands for goto occultation that are likely to
> lead C++ in an even more complicated "goto algebra".
>
> Unlike what most think, code is not poetry and attempts to enforce such a
> policy result in increasing technical debt.
>
>
> On Thu, Apr 24, 2014 at 9:18 AM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:
>
>> There were a lot of different ideas considered like this one, and many
>> others, in preparing N3879. Ultimately, I decided to stick with
>> exactly and only what has been tested and proven by the millions of
>> programmers that use Java and C#. Anything more, and the proposal
>> loses that appeal to existing practice.
>>
>>
>> On Wed, Apr 23, 2014 at 7:56 PM, Ville Voutilainen
>> <ville.voutilainen@gmail.com> wrote:
>> > On 23 April 2014 20:51, <rich.h.delaney@gmail.com> wrote:
>> >> If the above syntax is chosen (or something similar), then the open
>> >> questions are this:
>> >> Is named scope desired as part of this language feature?
>> >
>> > Before we go there, let's ask this one:
>> > Is this language extension worth its cost?
>> >
>> > --
>> >
>> > ---
>> > 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/.
>>
>> --
>>
>> ---
>> 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/.
>>
>
> --
>
> ---
> 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/.
>
--
how am I supposed to end the twisted road of your hair in the dark night,
unless the candle of your face does not turn a lamp on up my way?
--
---
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/.
--047d7b86dc40ce225204f7ccb77a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I want to add just one note about existing practice. Altho=
ugh it is not generally considered in software domain, HDLs(both verilog an=
d VHDL) have already implemented named block statements which are accessibl=
e through dot-separated names.<div>
<br></div><div>regards,</div><div>FM.</div></div><div class=3D"gmail_extra"=
><br><br><div class=3D"gmail_quote">On Thu, Apr 24, 2014 at 1:17 PM, George=
Makrydakis <span dir=3D"ltr"><<a href=3D"mailto:irrequietus@gmail.com" =
target=3D"_blank">irrequietus@gmail.com</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 dir=3D"ltr">While I can understand the =
reasoning for the "explicit switch" in N3879, I cannot come to te=
rms with why named controlled structures provide any benefit other than enc=
ouraging code that is more akin to poetic prose than aiming towards a techn=
ical solution.<br>
<br>The "explicit" switch variant is declarative of a specific pr=
ogrammer intent and therefore it is not just a shorthand. Named control str=
uctures on the other hands are shorthands for goto occultation that are lik=
ely to lead C++ in an even more complicated "goto algebra".<br>
<br>Unlike what most think, code is not poetry and attempts to enforce such=
a policy result in increasing technical debt.<br></div><div class=3D"HOEnZ=
b"><div class=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">
On Thu, Apr 24, 2014 at 9:18 AM, Andrew Tomazos <span dir=3D"ltr"><<a hr=
ef=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail=
..com</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">There were a lot of different ideas consider=
ed like this one, and many<br>
others, in preparing N3879. =C2=A0Ultimately, I decided to stick with<br>
exactly and only what has been tested and proven by the millions of<br>
programmers that use Java and C#. =C2=A0Anything more, and the proposal<br>
loses that appeal to existing practice.<br>
<div><div><br>
<br>
On Wed, Apr 23, 2014 at 7:56 PM, Ville Voutilainen<br>
<<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.=
voutilainen@gmail.com</a>> wrote:<br>
> On 23 April 2014 20:51, =C2=A0<<a href=3D"mailto:rich.h.delaney@gma=
il.com" target=3D"_blank">rich.h.delaney@gmail.com</a>> wrote:<br>
>> If the above syntax is chosen (or something similar), then the ope=
n<br>
>> questions are this:<br>
>> Is named scope desired as part of this language feature?<br>
><br>
> Before we go there, let's ask this one:<br>
> Is this language extension worth its cost?<br>
><br>
> --<br>
><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" targ=
et=3D"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
> Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/g=
roup/std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.or=
g/group/std-proposals/</a>.<br>
<br>
--<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 <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
how am I supposed to end the twisted road of=C2=A0 your hair in the dark ni=
ght,<br>unless the candle of your face does not turn a lamp on up my way?<b=
r>
</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b86dc40ce225204f7ccb77a--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Thu, 24 Apr 2014 23:27:14 +0300
Raw View
This is a multi-part message in MIME format.
--------------030701040909090704080704
Content-Type: text/plain; charset=UTF-8; format=flowed
Actually, HDLs are an example of why named blocks are to readily prime
the programmer into dealing with a "goto algebra", only that in their
case it is "disable" doing the goto - ing.
Now, the "goto" instruction does not exist in VHDL or SystemVerilog and
that task is reserved for the "disable" instruction which unsurprisingly
stops the execution of any named begin / end code block in order to
achieve the same effect.
The important thing to remember is that for any given begin / end block
to be used by the "disable" instruction, it must be a named one! The
named begin / end block in VHDL may or may not reside within the process
containing that "disable" instruction. And then there are hierarchical
names that pose further rules on how "disable" is to behave.
This is an argument strong enough that labeled / named blocks are just
going to create a rather unnecessary and additional "goto algebra" layer
in C++. Isn't one "goto" enough?
On 04/24/2014 07:55 PM, Farid Mehrabi wrote:
> I want to add just one note about existing practice. Although it is
> not generally considered in software domain, HDLs(both verilog and
> VHDL) have already implemented named block statements which are
> accessible through dot-separated names.
>
> regards,
> FM.
>
>
> On Thu, Apr 24, 2014 at 1:17 PM, George Makrydakis
> <irrequietus@gmail.com <mailto:irrequietus@gmail.com>> wrote:
>
> While I can understand the reasoning for the "explicit switch" in
> N3879, I cannot come to terms with why named controlled structures
> provide any benefit other than encouraging code that is more akin
> to poetic prose than aiming towards a technical solution.
>
> The "explicit" switch variant is declarative of a specific
> programmer intent and therefore it is not just a shorthand. Named
> control structures on the other hands are shorthands for goto
> occultation that are likely to lead C++ in an even more
> complicated "goto algebra".
>
> Unlike what most think, code is not poetry and attempts to enforce
> such a policy result in increasing technical debt.
>
--
---
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/.
--------------030701040909090704080704
Content-Type: text/html; charset=UTF-8
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
Actually, HDLs are an example of why named blocks are to readily
prime the programmer into dealing with a "goto algebra", only that
in their case it is "disable" doing the goto - ing.<br>
<br>
Now, the "goto" instruction does not exist in VHDL or SystemVerilog
and that task is reserved for the "disable" instruction which
unsurprisingly stops the execution of any named begin / end code
block in order to achieve the same effect.<br>
<br>
The important thing to remember is that for any given begin / end
block to be used by the "disable" instruction, it must be a named
one! The named begin / end block in VHDL may or may not reside
within the process containing that "disable" instruction. And then
there are hierarchical names that pose further rules on how
"disable" is to behave.<br>
<br>
This is an argument strong enough that labeled / named blocks are
just going to create a rather unnecessary and additional "goto
algebra" layer in C++. Isn't one "goto" enough?<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 04/24/2014 07:55 PM, Farid Mehrabi
wrote:<br>
</div>
<blockquote
cite="mid:CALDL7dH8K9zTuujc_7-rHSU4R1wKg67Us2nOUiHBokgb9LY8og@mail.gmail.com"
type="cite">
<div dir="ltr">I want to add just one note about existing
practice. Although it is not generally considered in software
domain, HDLs(both verilog and VHDL) have already implemented
named block statements which are accessible through
dot-separated names.
<div>
<br>
</div>
<div>regards,</div>
<div>FM.</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Apr 24, 2014 at 1:17 PM, George
Makrydakis <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:irrequietus@gmail.com" target="_blank">irrequietus@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">While I can understand the reasoning for the
"explicit switch" in N3879, I cannot come to terms with
why named controlled structures provide any benefit other
than encouraging code that is more akin to poetic prose
than aiming towards a technical solution.<br>
<br>
The "explicit" switch variant is declarative of a specific
programmer intent and therefore it is not just a
shorthand. Named control structures on the other hands are
shorthands for goto occultation that are likely to lead
C++ in an even more complicated "goto algebra".<br>
<br>
Unlike what most think, code is not poetry and attempts to
enforce such a policy result in increasing technical debt.<br>
</div>
<br>
</blockquote>
</div>
</div>
</blockquote>
<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 <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------030701040909090704080704--
.