--047d7b343ca2b7885a04eb3a5d82
Content-Type: text/plain; charset=ISO-8859-1

On 15 November 2013 11:01, <kevingrant.engineer@gmail.com> wrote:

> *Proposal:* Add a new syntax to explicitly invert the standard
> fall-through behavior of a switch so that each case has an implicit break.
>

switch auto break (myValue) {
> case DEF:
> case GHI:
> doSomethingElse();
> // "break" is implicit here
>


Shouldn't there be an implicit break after case DEF?
--
 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/.

--047d7b343ca2b7885a04eb3a5d82
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 15 November 2013 11:01,  <span dir=3D"ltr">&lt;<a href=
=3D"mailto:kevingrant.engineer@gmail.com" target=3D"_blank">kevingrant.engi=
neer@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote">

<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"><b>Proposal:</b> Add a new =
syntax to explicitly invert the standard fall-through behavior of a <span s=
tyle=3D"font-family:courier new,monospace">switch</span> so that each case =
has an implicit <span style=3D"font-family:courier new,monospace">break</sp=
an>.</div>

</blockquote><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div style=
=3D"margin-left:40px"><div style=3D"margin-left:40px"><font face=3D"courier=
 new,monospace">switch auto break (<font face=3D"courier new,monospace">myV=
alue) {<br>

</font></font><tt>case DEF:</tt><br><tt>case GHI:<br></tt><div style=3D"mar=
gin-left:40px"><tt>doSomethingElse();<br>// &quot;break&quot; is implicit h=
ere<br></tt></div></div></div></div></blockquote><div><br><br></div><div>

Shouldn&#39;t there be an implicit break after case DEF?<br></div></div>-- =
<br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto:nevin@ev=
iloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=A0 (847) 6=
91-1404
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b343ca2b7885a04eb3a5d82--

.

--001a1134d2dad9e9f904eb3a8132
Content-Type: text/plain; charset=ISO-8859-1

On 15 November 2013 11:01, <kevingrant.engineer@gmail.com> wrote:

>
> Example:
> switch auto break (myValue) {
> case ABC:
> doSomething();
> // "break" is implicit here
> case DEF:
> case GHI:
> doSomethingElse();
> // "break" is implicit here
> case JKL:
> doJKLAction();
> goto case MNO; // in auto-break switch this is explicit fall-through
> case MNO:
> doJKLMNOAction();
> // "break" is implicit here
> default:
> doTheDefaultThing();
> // "break" is implicit here
> }
>
> Hmm... I wonder if a better solution for this problem (if it is worth
solving at all) would be with attributes, as in something like:

switch (myValue) [[nofallthrough]] {
case ABC:
doSomething();
break;
case DEF: [[fallthrough]]
case GHI:
doSomethingElse();
break;
case JKL:
doJKLAction();
[[fallthrough]]
case MNO:
doJKLMNOAction();
break;
default:
doTheDefaultThing();
break;
}
--
 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/.

--001a1134d2dad9e9f904eb3a8132
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 15 November 2013 11:01,  <span dir=3D"ltr">&lt;<a href=
=3D"mailto:kevingrant.engineer@gmail.com" target=3D"_blank">kevingrant.engi=
neer@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><div=
 style=3D"margin-left:40px">Example:<br><div style=3D"margin-left:40px"><fo=
nt face=3D"courier new,monospace">switch auto break (<font face=3D"courier =
new,monospace">myValue) {<br>

<font face=3D"courier new,monospace">case<font face=3D"courier new,monospac=
e"> <font face=3D"courier new,monospace">ABC</font>:<br></font></font></fon=
t></font><div style=3D"margin-left:40px"><tt>doSomething();<br>// &quot;bre=
ak&quot; is implicit here<br>

</tt></div><tt>case DEF:</tt><br><tt>case GHI:<br></tt><div style=3D"margin=
-left:40px"><tt>doSomethingElse();<br>// &quot;break&quot; is implicit here=
<br></tt></div><tt>case JKL:<br></tt><div style=3D"margin-left:40px"><tt>do=
JKLAction();</tt><br>

</div><div style=3D"margin-left:40px"><tt>goto case MNO;</tt><tt><tt> // in=
 auto-break switch this is explicit fall-through</tt><br></tt></div><tt>cas=
e MNO:</tt><br><div style=3D"margin-left:40px"><tt>doJKLMNOAction();</tt><b=
r>

</div><div style=3D"margin-left:40px"><tt>// &quot;break&quot; is implicit =
here</tt><br></div><tt>default:<br></tt><div style=3D"margin-left:40px"><tt=
>doTheDefaultThing();<br>// &quot;break&quot; is implicit here<br></tt></di=
v>

<font face=3D"courier new,monospace"><font face=3D"courier new,monospace"><=
font face=3D"courier new,monospace">}</font><span class=3D""><font color=3D=
"#888888"><br></font></span></font></font></div></div></div><span class=3D"=
"><font color=3D"#888888">

<p></p>

</font></span></blockquote></div>Hmm... I wonder if a better solution for t=
his problem (if it is worth solving at all) would be with attributes, as in=
 something like:<br><br><div style=3D"margin-left:40px"><font face=3D"couri=
er new,monospace">switch (<font face=3D"courier new,monospace">myValue) [[n=
ofallthrough]] {<br>

<font face=3D"courier new,monospace">case<font face=3D"courier new,monospac=
e"> <font face=3D"courier new,monospace">ABC</font>:<br></font></font></fon=
t></font><div style=3D"margin-left:40px"><tt>doSomething();<br>break;<br></=
tt></div>

<tt>case DEF:</tt> <tt>[[fallthrough]]</tt><br><tt>case GHI:<br></tt><div s=
tyle=3D"margin-left:40px"><tt>doSomethingElse();<br>break;<br></tt></div><t=
t>case JKL:<br></tt><div style=3D"margin-left:40px"><tt>doJKLAction();</tt>=
<br>

</div></div><div style=3D"margin-left:40px"><div style=3D"margin-left:40px"=
><tt>[[fallthrough]]</tt><tt><br></tt></div></div><div style=3D"margin-left=
:40px"><tt>case MNO:</tt><br><div style=3D"margin-left:40px"><tt>doJKLMNOAc=
tion();</tt><br>

</div><div style=3D"margin-left:40px"><tt>break;</tt><br></div><tt>default:=
<br></tt><div style=3D"margin-left:40px"><tt>doTheDefaultThing();<br>break;=
<br></tt></div><font face=3D"courier new,monospace"><font face=3D"courier n=
ew,monospace"><font face=3D"courier new,monospace">}</font><span class=3D""=
></span></font></font><br>

</div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"mailto=
:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1134d2dad9e9f904eb3a8132--

.

On 11/16/13 1:26 AM, Nevin Liber wrote:
> Hmm... I wonder if a better solution for this problem (if it is worth
> solving at all) would be with attributes, as in something like:
>
> switch (myValue) [[nofallthrough]] {

Attributes aren't supposed to have semantic effect.

Another solution (surely well explored by others) would be a macro:

#define breakcase break; case
#define breakdefault

switch ( value ) {
breakcase ABC:
doSomething();

breakcase DEF: case GHI:
doSomethingElse();

breakdefault:
doTheDefaultThing();
}

This puts a useless break; at the beginning instead of the end.

This is really a C language topic. C++ is somewhat different in that
cases with typical, non-fallthrough flow control idiomatically establish
scopes, so you need braces to avoid skipping over initialization of
variables that don't get used anyway. If (if!) C standardizes a syntax
for mutually exclusive cases, we could make C++ initialization semantics
fit by introducing implicit braces.

--

---
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/.

.

--089e013d1db2e0257504eb3b40e8
Content-Type: text/plain; charset=ISO-8859-1

On 15 November 2013 11:44, David Krauss <potswa@gmail.com> wrote:

> On 11/16/13 1:26 AM, Nevin Liber wrote:
>
>> Hmm... I wonder if a better solution for this problem (if it is worth
>> solving at all) would be with attributes, as in something like:
>>
>> switch (myValue) [[nofallthrough]] {
>>
>
> Attributes aren't supposed to have semantic effect.
>

What semantic effect was there in the code I wrote?  A compiler can ignore
the attributes or give warnings for violations.  In that respect, I don't
see how it is any different than what compilers can do with something like
[[deprecated]].
--
 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/.

--089e013d1db2e0257504eb3b40e8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 15 November 2013 11:44, David Krauss <span dir=3D"ltr">=
&lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com<=
/a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">

<div class=3D"im">On 11/16/13 1:26 AM, Nevin Liber wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hmm... I wonder if a better solution for this problem (if it is worth<br>
solving at all) would be with attributes, as in something like:<br>
<br>
switch (myValue) [[nofallthrough]] {<br>
</blockquote>
<br></div>
Attributes aren&#39;t supposed to have semantic effect.<br></blockquote><di=
v><br></div><div>What semantic effect was there in the code I wrote?=A0 A c=
ompiler can ignore the attributes or give warnings for violations.=A0 In th=
at respect, I don&#39;t see how it is any different than what compilers can=
 do with something like [[deprecated]].<br>

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e013d1db2e0257504eb3b40e8--

.

On 15 November 2013 19:44, David Krauss <potswa@gmail.com> wrote:
> On 11/16/13 1:26 AM, Nevin Liber wrote:
>>
>> Hmm... I wonder if a better solution for this problem (if it is worth
>> solving at all) would be with attributes, as in something like:
>>
>> switch (myValue) [[nofallthrough]] {
>
>
> Attributes aren't supposed to have semantic effect.
>
> Another solution (surely well explored by others) would be a macro:



Yet another solution is a variadic function template that takes the
value to test,
and a bag of case values and functors to run when a case value matches
the value to test. There are multiple such solutions in the wild.

The "relaxed switch statement" paper
(http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3627.html)
is somewhat related.


All "switch on steroids" ideas usually get a big "yawn" from me. Alternate
designs (maps, chains) tend to be superior, and making a core language
change to switch doesn't usually feel like it's worth its cost, to me.

--

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

.

--nextPart2973213.PXarLGfyoc
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On sexta-feira, 15 de novembro de 2013 12:19:50, Nevin Liber wrote:
> What semantic effect was there in the code I wrote?  A compiler can ignore
> the attributes or give warnings for violations.  In that respect, I don't
> see how it is any different than what compilers can do with something like
> [[deprecated]].

I was going to say the same, but after re-reading your example, it looks like
you did not remove the breaks. You just annotated the case labels that fall
through, which is the common practice today (except with a comment).
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--nextPart2973213.PXarLGfyoc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iD8DBQBShmrNM/XwBW70U1gRAiO+AKCokprpF+1gUVdDQSirlQFYeGtkRwCfXnfF
2Wqiqhx2f4F4vO5sxu1+vGg=
=jIMD
-----END PGP SIGNATURE-----

--nextPart2973213.PXarLGfyoc--


.

--047d7b624d34c8522504eb3ba0b7
Content-Type: text/plain; charset=ISO-8859-1

On 15 November 2013 12:41, Thiago Macieira <thiago@macieira.org> wrote:

>
> I was going to say the same, but after re-reading your example, it looks
> like
> you did not remove the breaks. You just annotated the case labels that fall
> through, which is the common practice today (except with a comment).
>

Isn't the problem being solved that people forget to put in the breaks?

A brand new language feature to save people from typing "break;" with its
own set of pitfalls (should fallthrough be allowed between n case labels
with no intervening statements?  Either way, someone will get burned),
doesn't seem worth it to me.
--
 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/.

--047d7b624d34c8522504eb3ba0b7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 15 November 2013 12:41, Thiago Macieira <span dir=3D"lt=
r">&lt;<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@maci=
eira.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br>
</div>I was going to say the same, but after re-reading your example, it lo=
oks like<br>
you did not remove the breaks. You just annotated the case labels that fall=
<br>
through, which is the common practice today (except with a comment).<br></b=
lockquote><div><br></div><div>Isn&#39;t the problem being solved that peopl=
e forget to put in the breaks?<br><br>A brand new language feature to save =
people from typing &quot;break;&quot; with its own set of pitfalls (should =
fallthrough be allowed between n case labels with no intervening statements=
?=A0 Either way, someone will get burned), doesn&#39;t seem worth it to me.=
<br>

</div></div>-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b624d34c8522504eb3ba0b7--

.

------=_Part_143_2697651.1384545602127
Content-Type: text/plain; charset=ISO-8859-1

My original example is missing a "goto case GHI;" after "case DEF:" to be
explicit about the fall-through from "DEF" to "GHI".

On Friday, November 15, 2013 11:01:13 AM UTC-6, kevingran...@gmail.com
wrote:
>
> *Proposal:* Add a new syntax to explicitly invert the standard
> fall-through behavior of a switch so that each case has an implicit break.
> In addition, add a syntax to make fall-through explicit in these kinds of
> switches.
>
> *Rationale:* A break is an exceedingly common requirement in a switchstatement.  In my experience working on various projects over many years,
> the standard fall-through behavior is not only extremely rare but when it's
> used it invariably comes with a comment like "intentional fall-through" to
> remind the reader that the fall-through hasn't been allowed by mistake.
> The cost in debugging a missing break in a case can be high, as it may
> lead to subtle misbehavior.
>
> *Suggested Syntax:* Reuse the auto, break, and goto keywords.  Reuse the
> fundamental structure of a switch statement (aside from no break and the
> new annotations, the rest remains the same).
> Example:
> switch auto break (myValue) {
> case ABC:
> doSomething();
> // "break" is implicit here
> case DEF:
> case GHI:
> doSomethingElse();
> // "break" is implicit here
> case JKL:
> doJKLAction();
> goto case MNO; // in auto-break switch this is explicit fall-through
> case MNO:
> doJKLMNOAction();
> // "break" is implicit here
> default:
> doTheDefaultThing();
> // "break" is implicit here
> }
>

--

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

------=_Part_143_2697651.1384545602127
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">My original example is missing a "<span style=3D"font-fami=
ly: courier new,monospace;">goto case GHI;</span>" after "<span style=3D"fo=
nt-family: courier new,monospace;">case DEF:</span>" to be explicit about t=
he fall-through from "DEF" to "GHI".<br><br>On Friday, November 15, 2013 11=
:01:13 AM UTC-6, kevingran...@gmail.com 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"><b>Proposal:</b> Add a new syntax to expli=
citly invert the standard fall-through behavior of a <span style=3D"font-fa=
mily:courier new,monospace">switch</span> so that each case has an implicit=
 <span style=3D"font-family:courier new,monospace">break</span>.&nbsp; In a=
ddition, add a syntax to make fall-through explicit in these kinds of switc=
hes.<br><br><b>Rationale:</b> A <span style=3D"font-family:courier new,mono=
space">break</span> is an exceedingly common requirement in a <span style=
=3D"font-family:courier new,monospace">switch</span> statement.&nbsp; In my=
 experience working on various projects over many years, the standard fall-=
through behavior is not only extremely rare but when it's used it invariabl=
y comes with a comment like "intentional fall-through" to remind the reader=
 that the fall-through hasn't been allowed by mistake.&nbsp; The cost in de=
bugging a missing <span style=3D"font-family:courier new,monospace">break</=
span> in a case can be high, as it may lead to subtle misbehavior.<br><br><=
b>Suggested Syntax:</b> Reuse the <span style=3D"font-family:courier new,mo=
nospace">auto</span>, <span style=3D"font-family:courier new,monospace">bre=
ak</span>, and <span style=3D"font-family:courier new,monospace">goto</span=
> keywords.&nbsp; Reuse the fundamental structure of a <span style=3D"font-=
family:courier new,monospace">switch</span> statement (aside from no <span =
style=3D"font-family:courier new,monospace">break</span> and the new annota=
tions, the rest remains the same).<br><div style=3D"margin-left:40px">Examp=
le:<br><div style=3D"margin-left:40px"><font face=3D"courier new,monospace"=
>switch auto break (<font face=3D"courier new,monospace">myValue) {<br><fon=
t face=3D"courier new,monospace">case<font face=3D"courier new,monospace"> =
<font face=3D"courier new,monospace">ABC</font>:<br></font></font></font></=
font><div style=3D"margin-left:40px"><tt>doSomething();<br>// "break" is im=
plicit here<br></tt></div><tt>case DEF:</tt><br><tt>case GHI:<br></tt><div =
style=3D"margin-left:40px"><tt>doSomethingElse();<br>// "break" is implicit=
 here<br></tt></div><tt>case JKL:<br></tt><div style=3D"margin-left:40px"><=
tt>doJKLAction();</tt><br></div><div style=3D"margin-left:40px"><tt>goto ca=
se MNO;</tt><tt><tt> // in auto-break switch this is explicit fall-through<=
/tt><br></tt></div><tt>case MNO:</tt><br><div style=3D"margin-left:40px"><t=
t>doJKLMNOAction();</tt><br></div><div style=3D"margin-left:40px"><tt>// "b=
reak" is implicit here</tt><br></div><tt>default:<br></tt><div style=3D"mar=
gin-left:40px"><tt>doTheDefaultThing();<br>// "break" is implicit here<br><=
/tt></div><font face=3D"courier new,monospace"><font face=3D"courier new,mo=
nospace"><font face=3D"courier new,monospace">}</font><br></font></font></d=
iv></div></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_143_2697651.1384545602127--

.

--20cf307ca4fa7166f804eb3dd2b8
Content-Type: text/plain; charset=ISO-8859-1

Clang already supports this (with a global flag rather than a
[[nofallthrough]] attribute):

http://clang.llvm.org/docs/LanguageExtensions.html#the-clang-fallthrough-attribute


On Fri, Nov 15, 2013 at 9:26 AM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 15 November 2013 11:01, <kevingrant.engineer@gmail.com> wrote:
>
>>
>> Example:
>> switch auto break (myValue) {
>> case ABC:
>> doSomething();
>> // "break" is implicit here
>> case DEF:
>> case GHI:
>> doSomethingElse();
>> // "break" is implicit here
>> case JKL:
>> doJKLAction();
>> goto case MNO; // in auto-break switch this is explicit fall-through
>> case MNO:
>> doJKLMNOAction();
>> // "break" is implicit here
>> default:
>> doTheDefaultThing();
>> // "break" is implicit here
>> }
>>
>> Hmm... I wonder if a better solution for this problem (if it is worth
> solving at all) would be with attributes, as in something like:
>
> switch (myValue) [[nofallthrough]] {
> case ABC:
> doSomething();
> break;
> case DEF: [[fallthrough]]
> case GHI:
> doSomethingElse();
> break;
> case JKL:
> doJKLAction();
> [[fallthrough]]
> case MNO:
> doJKLMNOAction();
> break;
> default:
> doTheDefaultThing();
> break;
> }
> --
>  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/.
>

--

---
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/.

--20cf307ca4fa7166f804eb3dd2b8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Clang already supports this (with a global flag rathe=
r than a [[nofallthrough]] attribute):</div><div><br></div><a href=3D"http:=
//clang.llvm.org/docs/LanguageExtensions.html#the-clang-fallthrough-attribu=
te">http://clang.llvm.org/docs/LanguageExtensions.html#the-clang-fallthroug=
h-attribute</a><br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri,=
 Nov 15, 2013 at 9:26 AM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"mail=
to:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"im">On 15 Nov=
ember 2013 11:01,  <span dir=3D"ltr">&lt;<a href=3D"mailto:kevingrant.engin=
eer@gmail.com" target=3D"_blank">kevingrant.engineer@gmail.com</a>&gt;</spa=
n> wrote:<br>
</div><div class=3D"gmail_extra"><div class=3D"im"><div class=3D"gmail_quot=
e">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><br><div=
 style=3D"margin-left:40px">Example:<br><div style=3D"margin-left:40px"><fo=
nt face=3D"courier new,monospace">switch auto break (<font face=3D"courier =
new,monospace">myValue) {<br>


<font face=3D"courier new,monospace">case<font face=3D"courier new,monospac=
e"> <font face=3D"courier new,monospace">ABC</font>:<br></font></font></fon=
t></font><div style=3D"margin-left:40px"><tt>doSomething();<br>// &quot;bre=
ak&quot; is implicit here<br>


</tt></div><tt>case DEF:</tt><br><tt>case GHI:<br></tt><div style=3D"margin=
-left:40px"><tt>doSomethingElse();<br>// &quot;break&quot; is implicit here=
<br></tt></div><tt>case JKL:<br></tt><div style=3D"margin-left:40px"><tt>do=
JKLAction();</tt><br>


</div><div style=3D"margin-left:40px"><tt>goto case MNO;</tt><tt><tt> // in=
 auto-break switch this is explicit fall-through</tt><br></tt></div><tt>cas=
e MNO:</tt><br><div style=3D"margin-left:40px"><tt>doJKLMNOAction();</tt><b=
r>


</div><div style=3D"margin-left:40px"><tt>// &quot;break&quot; is implicit =
here</tt><br></div><tt>default:<br></tt><div style=3D"margin-left:40px"><tt=
>doTheDefaultThing();<br>// &quot;break&quot; is implicit here<br></tt></di=
v>


<font face=3D"courier new,monospace"><font face=3D"courier new,monospace"><=
font face=3D"courier new,monospace">}</font><span><font color=3D"#888888"><=
br></font></span></font></font></div></div></div><span><font color=3D"#8888=
88">

<p></p>

</font></span></blockquote></div></div>Hmm... I wonder if a better solution=
 for this problem (if it is worth solving at all) would be with attributes,=
 as in something like:<br><br><div style=3D"margin-left:40px"><font face=3D=
"courier new,monospace">switch (<font face=3D"courier new,monospace">myValu=
e) [[nofallthrough]] {<br>


<font face=3D"courier new,monospace">case<font face=3D"courier new,monospac=
e"> <font face=3D"courier new,monospace">ABC</font>:<br></font></font></fon=
t></font><div style=3D"margin-left:40px"><tt>doSomething();<br>break;<br></=
tt></div>


<tt>case DEF:</tt> <tt>[[fallthrough]]</tt><br><tt>case GHI:<br></tt><div s=
tyle=3D"margin-left:40px"><tt>doSomethingElse();<br>break;<br></tt></div><t=
t>case JKL:<br></tt><div style=3D"margin-left:40px"><tt>doJKLAction();</tt>=
<br>


</div></div><div style=3D"margin-left:40px"><div style=3D"margin-left:40px"=
><tt>[[fallthrough]]</tt><tt><br></tt></div></div><div style=3D"margin-left=
:40px"><tt>case MNO:</tt><br><div style=3D"margin-left:40px"><tt>doJKLMNOAc=
tion();</tt><br>


</div><div style=3D"margin-left:40px"><tt>break;</tt><br></div><tt>default:=
<br></tt><div style=3D"margin-left:40px"><tt>doTheDefaultThing();<br>break;=
<br></tt></div><font face=3D"courier new,monospace"><font face=3D"courier n=
ew,monospace"><font face=3D"courier new,monospace">}</font><span></span></f=
ont></font><br>


</div><div class=3D"im">-- <br>=A0Nevin &quot;:-)&quot; Liber=A0 &lt;mailto=
:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilover=
lord.com</a>&gt;=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911=
404" target=3D"_blank">(847) 691-1404</a>
</div></div></div>

<p></p>

-- <br><div class=3D"HOEnZb"><div class=3D"h5">
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@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 />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--20cf307ca4fa7166f804eb3dd2b8--

.

------=_Part_760_32720247.1384565356968
Content-Type: text/plain; charset=ISO-8859-1

On Friday, November 15, 2013 6:01:13 PM UTC+1, kevingran...@gmail.com wrote:

> *Proposal:* Add a new syntax to explicitly invert the standard
> fall-through behavior of a switch


I've thought about the accidental fallthrough bug quite a lot.

It is a huge problem, not because it happens that often, but because when
it does the bug that ensues is an insideous fail-late logic bug that takes
an enormous amount of effort to debug.

This is due to the fact that the body of a case label is a totally
reasonable thing to happen at that point in the code.  So randomly
composing two of them (the effect of an accidental fallthrough) is usually
a totally reasonable thing to happen as well.  The misbehavior is therefore
caught some large distance away from the bug origin at run-time, sometimes,
even worse, with only intermittent or subtle effects.

The way this was originally solved in C# was to disallow implicit
fallthrough on a non-empty case, and there was a `fallthrough` statement
you had to use to explicitly fallthrough.  It appears this has been
mirrored by clang as an extension as Richard Smith mentions with the
[[clang::fallthrough]] attribute.

Newer versions of C# continue to disallow implicit fallthrough, but have a
new "goto case label" syntax as you show.  This generalizes the fallthrough
statement as you can goto the next case by naming it, or name some other
case.  In any case C# does not allow implicit fallthrough.

The accidental fall-through bug is definitely worth solving.  I would
tentatively propose the following:

- deprecate implicit fallthrough.  make it ill-formed no diagnostic
required, so compilers can start emitting a warning.
- standardize a [[fallthrough]] attribute statement from clang that
suppresses the warning.
- add "goto case label" statement

--

---
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_760_32720247.1384565356968
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, November 15, 2013 6:01:13 PM UTC+1, kevingran..=
..@gmail.com wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 2=
04); border-left-style: solid; padding-left: 1ex;"><b>Proposal:</b>&nbsp;Ad=
d a new syntax to explicitly invert the standard fall-through behavior of a=
&nbsp;<span style=3D"font-family: 'courier new', monospace;">switch</span><=
/blockquote><div><div><span style=3D"font-family: arial; font-size: small;"=
><br></span></div><div><span style=3D"font-family: arial; font-size: small;=
">I've thought about the accidental fallthrough bug quite a lot.</span><div=
 style=3D"font-family: arial; font-size: small;"><br></div><div style=3D"fo=
nt-family: arial; font-size: small;">It is a huge problem, not because it h=
appens that often, but because when it does the bug that ensues is an insid=
eous fail-late logic bug that takes an enormous amount of effort to debug.<=
/div><div style=3D"font-family: arial; font-size: small;"><br></div><div st=
yle=3D"font-family: arial; font-size: small;">This is due to the fact that =
the body of a case label is a totally reasonable thing to happen at that po=
int in the code. &nbsp;So randomly composing two of them (the effect of an =
accidental fallthrough) is usually a totally reasonable thing to happen as =
well. &nbsp;The misbehavior is therefore caught some large distance away fr=
om the bug origin at run-time, sometimes, even worse, with only intermitten=
t or subtle effects.</div></div></div><div style=3D"font-family: arial; fon=
t-size: small;"><br></div><div style=3D"font-family: arial; font-size: smal=
l;">The way this was originally solved in C# was to disallow implicit fallt=
hrough on a non-empty case, and there was a `fallthrough` statement you had=
 to use to explicitly fallthrough. &nbsp;It appears this has been mirrored =
by clang as an extension as Richard Smith mentions with the [[clang::fallth=
rough]] attribute.</div><div style=3D"font-family: arial; font-size: small;=
"><br></div><div style=3D"font-family: arial; font-size: small;">Newer vers=
ions of C# continue to disallow implicit fallthrough, but have a new "goto =
case label" syntax as you show. &nbsp;This generalizes the fallthrough stat=
ement as you can goto the next case by naming it, or name some other case. =
&nbsp;In any case C# does not allow implicit fallthrough.</div><div style=
=3D"font-family: arial; font-size: small;"><br></div><div style=3D"font-fam=
ily: arial; font-size: small;">The accidental fall-through bug is definitel=
y worth solving. &nbsp;I would tentatively propose the following:</div><div=
 style=3D"font-family: arial; font-size: small;"><br></div><div style=3D"fo=
nt-family: arial; font-size: small;">- deprecate implicit fallthrough. &nbs=
p;make it ill-formed no diagnostic required, so compilers can start emittin=
g a warning.</div><div style=3D"font-family: arial; font-size: small;">- st=
andardize a [[fallthrough]] attribute statement from clang that suppresses =
the warning.</div><div style=3D"font-family: arial; font-size: small;">- ad=
d "goto case label" statement</div><div style=3D"font-family: arial; font-s=
ize: small;"><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_760_32720247.1384565356968--

.

------=_Part_275_31384743.1384565804165
Content-Type: text/plain; charset=ISO-8859-1

On Saturday, November 16, 2013 2:29:16 AM UTC+1, Andrew Tomazos wrote:

> - deprecate implicit fallthrough.  make it ill-formed no diagnostic
> required, so compilers can start emitting a warning.
> - standardize a [[fallthrough]] attribute statement from clang that
> suppresses the warning.
> - add "goto case label" statement


Sorry, that should read "deprecate implicit fallthrough on *non-empty*cases"

--

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

------=_Part_275_31384743.1384565804165
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>On Saturday, November 16, 2013 2:29:16 AM UTC+1, Andr=
ew Tomazos wrote:&nbsp;</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;">- deprecate impli=
cit fallthrough. &nbsp;make it ill-formed no diagnostic required, so compil=
ers can start emitting a warning.<br>- standardize a [[fallthrough]] attrib=
ute statement from clang that suppresses the warning.<br><span style=3D"fon=
t-family: arial; font-size: small;">- add "goto case label" statement</span=
></blockquote><div><br></div><div>Sorry, that should read "deprecate implic=
it fallthrough on <u>non-empty</u> cases"</div><div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_275_31384743.1384565804165--

.

--089e0153859450e54004eb41a2f5
Content-Type: text/plain; charset=ISO-8859-1

If you want compilers to emit a warning, they've always been able to do
that. You don't want to all the sudden make huge Huge HUGE amounts of code
ill formed on a whim like this. If people want warnings, many
implementations are quire happy to give them warnings.

I'm confused about the usefulness of the goto case label statement. If you
want to jump to a completely unrelated part of the switch, then use plain
goto. What you're doing is evil, and you should have to use an evil
construct like plain goto to solve it.

[[fallthrough]] seems reasonable, and what's better, there's an
implementation already doing it. If you want a proposal, start there.

Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com


On Fri, Nov 15, 2013 at 5:29 PM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:

> On Friday, November 15, 2013 6:01:13 PM UTC+1, kevingran...@gmail.comwrote:
>
>> *Proposal:* Add a new syntax to explicitly invert the standard
>> fall-through behavior of a switch
>
>
> I've thought about the accidental fallthrough bug quite a lot.
>
> It is a huge problem, not because it happens that often, but because when
> it does the bug that ensues is an insideous fail-late logic bug that takes
> an enormous amount of effort to debug.
>
> This is due to the fact that the body of a case label is a totally
> reasonable thing to happen at that point in the code.  So randomly
> composing two of them (the effect of an accidental fallthrough) is usually
> a totally reasonable thing to happen as well.  The misbehavior is therefore
> caught some large distance away from the bug origin at run-time, sometimes,
> even worse, with only intermittent or subtle effects.
>
> The way this was originally solved in C# was to disallow implicit
> fallthrough on a non-empty case, and there was a `fallthrough` statement
> you had to use to explicitly fallthrough.  It appears this has been
> mirrored by clang as an extension as Richard Smith mentions with the
> [[clang::fallthrough]] attribute.
>
> Newer versions of C# continue to disallow implicit fallthrough, but have a
> new "goto case label" syntax as you show.  This generalizes the fallthrough
> statement as you can goto the next case by naming it, or name some other
> case.  In any case C# does not allow implicit fallthrough.
>
> The accidental fall-through bug is definitely worth solving.  I would
> tentatively propose the following:
>
> - deprecate implicit fallthrough.  make it ill-formed no diagnostic
> required, so compilers can start emitting a warning.
> - standardize a [[fallthrough]] attribute statement from clang that
> suppresses the warning.
> - add "goto case label" statement
>
>  --
>
> ---
> 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/.

--089e0153859450e54004eb41a2f5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>If you want compilers to emit a warning, they&#39;ve =
always been able to do that. You don&#39;t want to all the sudden make huge=
 Huge HUGE amounts of code ill formed on a whim like this. If people want w=
arnings, many implementations are quire happy to give them warnings.</div>

<div><br></div><div>I&#39;m confused about the usefulness of the goto case =
label statement. If you want to jump to a completely unrelated part of the =
switch, then use plain goto. What you&#39;re doing is evil, and you should =
have to use an evil construct like plain goto to solve it.</div>

<div><br></div><div>[[fallthrough]] seems reasonable, and what&#39;s better=
, there&#39;s an implementation already doing it. If you want a proposal, s=
tart there.</div></div><div class=3D"gmail_extra"><br clear=3D"all"><div><d=
iv dir=3D"ltr">

<div>Billy O&#39;Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal=
/" target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=
=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">htt=
p://stackoverflow.com/users/82320/billy-oneal</a></div>

<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Fri, Nov 15, 2013 at 5:29 PM, Andrew =
Tomazos <span dir=3D"ltr">&lt;<a href=3D"mailto:andrewtomazos@gmail.com" ta=
rget=3D"_blank">andrewtomazos@gmail.com</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">

<div dir=3D"ltr">On Friday, November 15, 2013 6:01:13 PM UTC+1, <a href=3D"=
mailto:kevingran...@gmail.com" target=3D"_blank">kevingran...@gmail.com</a>=
 wrote:<br><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-st=
yle:solid;padding-left:1ex">

<b>Proposal:</b>=A0Add a new syntax to explicitly invert the standard fall-=
through behavior of a=A0<span style=3D"font-family:&#39;courier new&#39;,mo=
nospace">switch</span></blockquote><div><div><span style=3D"font-family:ari=
al;font-size:small"><br>

</span></div><div><span style=3D"font-family:arial;font-size:small">I&#39;v=
e thought about the accidental fallthrough bug quite a lot.</span><div styl=
e=3D"font-family:arial;font-size:small"><br></div><div style=3D"font-family=
:arial;font-size:small">

It is a huge problem, not because it happens that often, but because when i=
t does the bug that ensues is an insideous fail-late logic bug that takes a=
n enormous amount of effort to debug.</div><div style=3D"font-family:arial;=
font-size:small">

<br></div><div style=3D"font-family:arial;font-size:small">This is due to t=
he fact that the body of a case label is a totally reasonable thing to happ=
en at that point in the code. =A0So randomly composing two of them (the eff=
ect of an accidental fallthrough) is usually a totally reasonable thing to =
happen as well. =A0The misbehavior is therefore caught some large distance =
away from the bug origin at run-time, sometimes, even worse, with only inte=
rmittent or subtle effects.</div>

</div></div><div style=3D"font-family:arial;font-size:small"><br></div><div=
 style=3D"font-family:arial;font-size:small">The way this was originally so=
lved in C# was to disallow implicit fallthrough on a non-empty case, and th=
ere was a `fallthrough` statement you had to use to explicitly fallthrough.=
 =A0It appears this has been mirrored by clang as an extension as Richard S=
mith mentions with the [[clang::fallthrough]] attribute.</div>

<div style=3D"font-family:arial;font-size:small"><br></div><div style=3D"fo=
nt-family:arial;font-size:small">Newer versions of C# continue to disallow =
implicit fallthrough, but have a new &quot;goto case label&quot; syntax as =
you show. =A0This generalizes the fallthrough statement as you can goto the=
 next case by naming it, or name some other case. =A0In any case C# does no=
t allow implicit fallthrough.</div>

<div style=3D"font-family:arial;font-size:small"><br></div><div style=3D"fo=
nt-family:arial;font-size:small">The accidental fall-through bug is definit=
ely worth solving. =A0I would tentatively propose the following:</div><div =
style=3D"font-family:arial;font-size:small">

<br></div><div style=3D"font-family:arial;font-size:small">- deprecate impl=
icit fallthrough. =A0make it ill-formed no diagnostic required, so compiler=
s can start emitting a warning.</div><div style=3D"font-family:arial;font-s=
ize:small">

- standardize a [[fallthrough]] attribute statement from clang that suppres=
ses the warning.</div><div style=3D"font-family:arial;font-size:small">- ad=
d &quot;goto case label&quot; statement</div><span class=3D"HOEnZb"><font c=
olor=3D"#888888"><div style=3D"font-family:arial;font-size:small">

<br></div></font></span></div><span class=3D"HOEnZb"><font color=3D"#888888=
">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@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>
</font></span></blockquote></div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0153859450e54004eb41a2f5--

.

------=_Part_710_20990073.1384569011884
Content-Type: text/plain; charset=ISO-8859-1

On Saturday, November 16, 2013 2:56:35 AM UTC+1, Billy O'Neal wrote:
>
> If you want compilers to emit a warning, they've always been able to do
> that. You don't want to all the sudden make huge Huge HUGE amounts of code
> ill formed on a whim like this. If people want warnings, many
> implementations are quire happy to give them warnings.
>

Yeah, you're right.  We can't even realistically emit a warning actually.
 There is a huge amount of code that uses implicit fallthrough
intentionally, and no-one is going to go through and update it all.  We
need to solve accidental fallthrough the same way we did with unscoped to
scoped enumerations.  Introduce a new syntax with the new behaviour.  I
propose "new switch".  That is add to selection-statement:

    selection-statement:
        if ( condition ) statement
        if ( condition ) statement else statement
        switch ( condition ) statement
        new switch ( condition ) statement    <--- HERE

and within a new switch implicit faillthrough is ill-formed (diagnostic
required).

Then add to:

    jump-statement:
        break;
        continue;
        return expression_opt;
        return braced-init-list ;
        goto identifier ;
        goto case constant-expression;   <--- HERE
        goto default;                    <--- AND HERE

goto case transfers control to that case, and goto default to the default
case.

I'm confused about the usefulness of the goto case label statement. If you
> want to jump to a completely unrelated part of the switch, then use plain
> goto. What you're doing is evil, and you should have to use an evil
> construct like plain goto to solve it.
>

a "case x:" doesn't actually introduce a label, it's a constant expression.
and cannot be used as the target of a goto, so we need a new syntax "goto
label expr".  Using it is exactly as evil as using a fallthrough or a goto,
and given the statement starts with the keyword goto, this is pretty clear.

We then teach everyone to always use "new switch" from now on instead of
"switch".

--

---
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_710_20990073.1384569011884
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, November 16, 2013 2:56:35 AM UTC+1, Billy O'N=
eal wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v>If you want compilers to emit a warning, they've always been able to do t=
hat. You don't want to all the sudden make huge Huge HUGE amounts of code i=
ll formed on a whim like this. If people want warnings, many implementation=
s are quire happy to give them warnings.</div></div></blockquote><div><br><=
/div><div>Yeah, you're right. &nbsp;We can't even realistically emit a warn=
ing actually. &nbsp;There is a huge amount of code that uses implicit fallt=
hrough intentionally, and no-one is going to go through and update it all. =
&nbsp;We need to solve accidental fallthrough the same way we did with unsc=
oped to scoped enumerations. &nbsp;Introduce a new syntax with the new beha=
viour. &nbsp;I propose "new switch". &nbsp;That is add to selection-stateme=
nt:</div><div><font face=3D"courier new, monospace"><br></font></div><div><=
div><font face=3D"courier new, monospace">&nbsp; &nbsp; selection-statement=
:</font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbs=
p; &nbsp; if ( condition ) statement</font></div><div><font face=3D"courier=
 new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; if ( condition ) statement els=
e statement</font></div><div><font face=3D"courier new, monospace">&nbsp; &=
nbsp; &nbsp; &nbsp; switch ( condition ) statement</font></div><div><font f=
ace=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; new switch ( con=
dition ) statement &nbsp; &nbsp;&lt;--- HERE</font></div><div><font face=3D=
"courier new, monospace"><br></font></div><div><font face=3D"arial, sans-se=
rif">and within a new switch implicit faillthrough is ill-formed (diagnosti=
c required).</font></div><div>&nbsp;<br></div></div><div>Then add to:</div>=
<div><br></div><div><div><font face=3D"courier new, monospace">&nbsp; &nbsp=
; jump-statement:</font></div><div><font face=3D"courier new, monospace">&n=
bsp; &nbsp; &nbsp; &nbsp; break;</font></div><div><font face=3D"courier new=
, monospace">&nbsp; &nbsp; &nbsp; &nbsp; continue;</font></div><div><font f=
ace=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; return expressio=
n_opt;</font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp;=
 &nbsp; &nbsp; return braced-init-list ;</font></div><div><font face=3D"cou=
rier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; goto identifier ;</font></=
div></div><div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; &nb=
sp; &nbsp; goto case constant-expression; &nbsp; &lt;--- HERE</font></div><=
/div><div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &=
nbsp; goto default; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;=
 &nbsp; &nbsp;&lt;--- AND HERE</font></div></div><div><font face=3D"courier=
 new, monospace"><br></font></div><div><font face=3D"courier new, monospace=
">goto case transfers control to that case, and goto default to the default=
 case.</font></div><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div></div><div>I'm confused about the usefulness of=
 the goto case label statement. If you want to jump to a completely unrelat=
ed part of the switch, then use plain goto. What you're doing is evil, and =
you should have to use an evil construct like plain goto to solve it.</div>=
</div></blockquote><div>&nbsp;</div><div>a "case x:" doesn't actually intro=
duce a label, it's a constant expression. and cannot be used as the target =
of a goto, so we need a new syntax "goto label expr". &nbsp;Using it is exa=
ctly as evil as using a fallthrough or a goto, and given the statement star=
ts with the keyword goto, this is pretty clear.</div><div><br></div><div>We=
 then teach everyone to always use "new switch" from now on instead of "swi=
tch".</div><div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_710_20990073.1384569011884--

.

------=_Part_579_13945722.1384569170192
Content-Type: text/plain; charset=ISO-8859-1

On Saturday, November 16, 2013 3:30:11 AM UTC+1, Andrew Tomazos wrote:
>
> so we need a new syntax "goto label expr".
>

Sigh. :) Should read "goto case expr"

--

---
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_579_13945722.1384569170192
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, November 16, 2013 3:30:11 AM UTC+1, Andrew To=
mazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>so we need a new syntax "goto label expr".</div></div></blockquote><div=
><br></div><div>Sigh. :) Should read "goto case expr"&nbsp;</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_579_13945722.1384569170192--

.

------=_Part_1063_32432187.1384582449004
Content-Type: text/plain; charset=ISO-8859-1

Yes, I feel similarly about established code bases and that's a big reason
why I suggested an alternate syntax.  There are other benefits though.

A side effect of having a 2nd, break-free switch syntax that I didn't
mention is that it would now be possible to allow break to refer
conveniently to the outer scope.  For example, if you put a switch inside a
for loop, an auto-breaking switch could allow a break in the cases' code to
exit the *loop* (whereas continue moves to the next loop iteration).  This
would be very useful; I see this combination quite often, and awkward code
is needed to deal with exiting a loop that just happens to contain a switch.

I don't mind "new switch" (it still reuses keywords nicely) though I
personally find that "switch auto break" more obviously states what it
does.  Also...given that a line like "new xyz(value);" is valid C++ (even
if it's weird to ignore the return value like that), could a "new switch
(value)" line be difficult to parse?

Kevin G.



On Friday, November 15, 2013 8:30:11 PM UTC-6, Andrew Tomazos wrote:
>
> On Saturday, November 16, 2013 2:56:35 AM UTC+1, Billy O'Neal wrote:
>>
>> If you want compilers to emit a warning, they've always been able to do
>> that. You don't want to all the sudden make huge Huge HUGE amounts of code
>> ill formed on a whim like this. If people want warnings, many
>> implementations are quire happy to give them warnings.
>>
>
> Yeah, you're right.  We can't even realistically emit a warning actually.
>  There is a huge amount of code that uses implicit fallthrough
> intentionally, and no-one is going to go through and update it all.  We
> need to solve accidental fallthrough the same way we did with unscoped to
> scoped enumerations.  Introduce a new syntax with the new behaviour.  I
> propose "new switch".  That is add to selection-statement:
>
>     selection-statement:
>         if ( condition ) statement
>         if ( condition ) statement else statement
>         switch ( condition ) statement
>         new switch ( condition ) statement    <--- HERE
>
> and within a new switch implicit faillthrough is ill-formed (diagnostic
> required).
>
> Then add to:
>
>     jump-statement:
>         break;
>         continue;
>         return expression_opt;
>         return braced-init-list ;
>         goto identifier ;
>         goto case constant-expression;   <--- HERE
>         goto default;                    <--- AND HERE
>
> goto case transfers control to that case, and goto default to the default
> case.
>
> I'm confused about the usefulness of the goto case label statement. If you
>> want to jump to a completely unrelated part of the switch, then use plain
>> goto. What you're doing is evil, and you should have to use an evil
>> construct like plain goto to solve it.
>>
>
> a "case x:" doesn't actually introduce a label, it's a constant
> expression. and cannot be used as the target of a goto, so we need a new
> syntax "goto label expr".  Using it is exactly as evil as using a
> fallthrough or a goto, and given the statement starts with the keyword
> goto, this is pretty clear.
>
> We then teach everyone to always use "new switch" from now on instead of
> "switch".
>
>

--

---
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_1063_32432187.1384582449004
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Yes, I feel similarly about established code bases an=
d that's a big reason why I suggested an alternate syntax. &nbsp;There are =
other benefits though.</div><div><br></div><div>A side effect of having a 2=
nd, <font face=3D"courier new, monospace">break</font>-free <font face=3D"c=
ourier new, monospace">switch</font> syntax that I didn't mention is that i=
t would now be possible to allow <font face=3D"courier new, monospace">brea=
k</font> to refer conveniently to the outer scope. &nbsp;For example, if yo=
u put a <font face=3D"courier new, monospace">switch</font> inside a <font =
face=3D"courier new, monospace">for</font> loop, an auto-breaking <font fac=
e=3D"courier new, monospace">switch</font> could allow a&nbsp;<font face=3D=
"courier new, monospace">break</font>&nbsp;in the cases' code to exit the <=
i>loop</i>&nbsp;(whereas&nbsp;<font face=3D"courier new, monospace">continu=
e</font>&nbsp;moves to the next loop iteration). &nbsp;This would be very u=
seful; I see this combination quite often, and awkward code is needed to de=
al with exiting a loop that just happens to contain a <font face=3D"courier=
 new, monospace">switch</font>.</div><div><br></div><div>I don't mind "<fon=
t face=3D"courier new, monospace">new switch</font>" (it still reuses keywo=
rds nicely) though I personally find that "<font face=3D"courier new, monos=
pace">switch auto break</font>" more obviously states what it does. &nbsp;A=
lso...given that a line like "<font face=3D"courier new, monospace">new xyz=
(value);</font>" is valid C++ (even if it's weird to ignore the return valu=
e like that), could a "<font face=3D"courier new, monospace">new switch (va=
lue)</font>" line be difficult to parse?</div><div><br></div><div>Kevin G.<=
/div><div><br></div><br><br>On Friday, November 15, 2013 8:30:11 PM UTC-6, =
Andrew Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Saturday, November 16, 2013 2:56:35 AM UTC+1, Billy O'Neal wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>If you want=
 compilers to emit a warning, they've always been able to do that. You don'=
t want to all the sudden make huge Huge HUGE amounts of code ill formed on =
a whim like this. If people want warnings, many implementations are quire h=
appy to give them warnings.</div></div></blockquote><div><br></div><div>Yea=
h, you're right. &nbsp;We can't even realistically emit a warning actually.=
 &nbsp;There is a huge amount of code that uses implicit fallthrough intent=
ionally, and no-one is going to go through and update it all. &nbsp;We need=
 to solve accidental fallthrough the same way we did with unscoped to scope=
d enumerations. &nbsp;Introduce a new syntax with the new behaviour. &nbsp;=
I propose "new switch". &nbsp;That is add to selection-statement:</div><div=
><font face=3D"courier new, monospace"><br></font></div><div><div><font fac=
e=3D"courier new, monospace">&nbsp; &nbsp; selection-statement:</font></div=
><div><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; if =
( condition ) statement</font></div><div><font face=3D"courier new, monospa=
ce">&nbsp; &nbsp; &nbsp; &nbsp; if ( condition ) statement else statement</=
font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; =
&nbsp; switch ( condition ) statement</font></div><div><font face=3D"courie=
r new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; new switch ( condition ) stat=
ement &nbsp; &nbsp;&lt;--- HERE</font></div><div><font face=3D"courier new,=
 monospace"><br></font></div><div><font face=3D"arial, sans-serif">and with=
in a new switch implicit faillthrough is ill-formed (diagnostic required).<=
/font></div><div>&nbsp;<br></div></div><div>Then add to:</div><div><br></di=
v><div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; jump-statem=
ent:</font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; &=
nbsp; &nbsp; break;</font></div><div><font face=3D"courier new, monospace">=
&nbsp; &nbsp; &nbsp; &nbsp; continue;</font></div><div><font face=3D"courie=
r new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; return expression_opt;</font>=
</div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp=
; return braced-init-list ;</font></div><div><font face=3D"courier new, mon=
ospace">&nbsp; &nbsp; &nbsp; &nbsp; goto identifier ;</font></div></div><di=
v><div><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; go=
to case constant-expression; &nbsp; &lt;--- HERE</font></div></div><div><di=
v><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; goto de=
fault; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
;&lt;--- AND HERE</font></div></div><div><font face=3D"courier new, monospa=
ce"><br></font></div><div><font face=3D"courier new, monospace">goto case t=
ransfers control to that case, and goto default to the default case.</font>=
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div></div><div>I'm confused about the usefulness of the goto case label=
 statement. If you want to jump to a completely unrelated part of the switc=
h, then use plain goto. What you're doing is evil, and you should have to u=
se an evil construct like plain goto to solve it.</div></div></blockquote><=
div>&nbsp;</div><div>a "case x:" doesn't actually introduce a label, it's a=
 constant expression. and cannot be used as the target of a goto, so we nee=
d a new syntax "goto label expr". &nbsp;Using it is exactly as evil as usin=
g a fallthrough or a goto, and given the statement starts with the keyword =
goto, this is pretty clear.</div><div><br></div><div>We then teach everyone=
 to always use "new switch" from now on instead of "switch".</div><div><br>=
</div></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1063_32432187.1384582449004--

.

--001a11c2c1261339bf04eb4cdcb7
Content-Type: text/plain; charset=ISO-8859-1

2013/11/16 <kevingrant.engineer@gmail.com>

> Yes, I feel similarly about established code bases and that's a big reason
> why I suggested an alternate syntax.  There are other benefits though.
>
> A side effect of having a 2nd, break-free switch syntax that I didn't
> mention is that it would now be possible to allow break to refer
> conveniently to the outer scope.  For example, if you put a switch inside
> a for loop, an auto-breaking switch could allow a break in the cases'
> code to exit the *loop* (whereas continue moves to the next loop
> iteration).  This would be very useful; I see this combination quite often,
> and awkward code is needed to deal with exiting a loop that just happens to
> contain a switch.
>
> I don't mind "new switch" (it still reuses keywords nicely) though I
> personally find that "switch auto break" more obviously states what it
> does.  Also...given that a line like "new xyz(value);" is valid C++ (even
> if it's weird to ignore the return value like that), could a "new switch
> (value)" line be difficult to parse?
>
> There shouldn't be any parsing problem, since switch is always a keyword
and can never be confused with an identifier.

Kevin G.
>
> Being able to break a loop from a switch is indeed interesting. However, I
don't like that you need a goto to have to cases that do exactly the same,
and if an empty case automatically falls through, then there is no way to
have a case that does absolutely nothing. Maybe a case with a single ;
should do exactly that?

If on the other hand we go with the new switch proposal, where fallthroughs
must be made explicit, isn't it more clear to use continue instead of the
rather awkward [[fallthrough]]?


>
>
> On Friday, November 15, 2013 8:30:11 PM UTC-6, Andrew Tomazos wrote:
>>
>> On Saturday, November 16, 2013 2:56:35 AM UTC+1, Billy O'Neal wrote:
>>>
>>> If you want compilers to emit a warning, they've always been able to do
>>> that. You don't want to all the sudden make huge Huge HUGE amounts of code
>>> ill formed on a whim like this. If people want warnings, many
>>> implementations are quire happy to give them warnings.
>>>
>>
>> Yeah, you're right.  We can't even realistically emit a warning actually.
>>  There is a huge amount of code that uses implicit fallthrough
>> intentionally, and no-one is going to go through and update it all.  We
>> need to solve accidental fallthrough the same way we did with unscoped to
>> scoped enumerations.  Introduce a new syntax with the new behaviour.  I
>> propose "new switch".  That is add to selection-statement:
>>
>>     selection-statement:
>>         if ( condition ) statement
>>         if ( condition ) statement else statement
>>         switch ( condition ) statement
>>         new switch ( condition ) statement    <--- HERE
>>
>> and within a new switch implicit faillthrough is ill-formed (diagnostic
>> required).
>>
>> Then add to:
>>
>>     jump-statement:
>>         break;
>>         continue;
>>         return expression_opt;
>>         return braced-init-list ;
>>         goto identifier ;
>>         goto case constant-expression;   <--- HERE
>>         goto default;                    <--- AND HERE
>>
>> goto case transfers control to that case, and goto default to the default
>> case.
>>
>> I'm confused about the usefulness of the goto case label statement. If
>>> you want to jump to a completely unrelated part of the switch, then use
>>> plain goto. What you're doing is evil, and you should have to use an evil
>>> construct like plain goto to solve it.
>>>
>>
>> a "case x:" doesn't actually introduce a label, it's a constant
>> expression. and cannot be used as the target of a goto, so we need a new
>> syntax "goto label expr".  Using it is exactly as evil as using a
>> fallthrough or a goto, and given the statement starts with the keyword
>> goto, this is pretty clear.
>>
>> We then teach everyone to always use "new switch" from now on instead of
>> "switch".
>>
>>  --
>
> ---
> 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/.

--001a11c2c1261339bf04eb4cdcb7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2013/11/16  <span dir=3D"ltr">&lt;<a href=3D"mailto:kevingrant.engi=
neer@gmail.com" target=3D"_blank">kevingrant.engineer@gmail.com</a>&gt;</sp=
an><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>Yes, I feel similarly about established code bases an=
d that&#39;s a big reason why I suggested an alternate syntax. =A0There are=
 other benefits though.</div><div><br></div><div>A side effect of having a =
2nd, <font face=3D"courier new, monospace">break</font>-free <font face=3D"=
courier new, monospace">switch</font> syntax that I didn&#39;t mention is t=
hat it would now be possible to allow <font face=3D"courier new, monospace"=
>break</font> to refer conveniently to the outer scope. =A0For example, if =
you put a <font face=3D"courier new, monospace">switch</font> inside a <fon=
t face=3D"courier new, monospace">for</font> loop, an auto-breaking <font f=
ace=3D"courier new, monospace">switch</font> could allow a=A0<font face=3D"=
courier new, monospace">break</font>=A0in the cases&#39; code to exit the <=
i>loop</i>=A0(whereas=A0<font face=3D"courier new, monospace">continue</fon=
t>=A0moves to the next loop iteration). =A0This would be very useful; I see=
 this combination quite often, and awkward code is needed to deal with exit=
ing a loop that just happens to contain a <font face=3D"courier new, monosp=
ace">switch</font>.</div>
<div><br></div><div>I don&#39;t mind &quot;<font face=3D"courier new, monos=
pace">new switch</font>&quot; (it still reuses keywords nicely) though I pe=
rsonally find that &quot;<font face=3D"courier new, monospace">switch auto =
break</font>&quot; more obviously states what it does. =A0Also...given that=
 a line like &quot;<font face=3D"courier new, monospace">new xyz(value);</f=
ont>&quot; is valid C++ (even if it&#39;s weird to ignore the return value =
like that), could a &quot;<font face=3D"courier new, monospace">new switch =
(value)</font>&quot; line be difficult to parse?</div>
<div><br></div></div></blockquote><div>There shouldn&#39;t be any parsing p=
roblem, since switch is always a keyword and can never be confused with an =
identifier.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>Kevin G.</div><div><div class=3D"h5"><div><br></div><=
/div></div></div></blockquote><div>Being able to break a loop from a switch=
 is indeed interesting. However, I don&#39;t like that you need a goto to h=
ave to cases that do exactly the same, and if an empty case automatically f=
alls through, then there is no way to have a case that does absolutely noth=
ing. Maybe a case with a single ; should do exactly that?</div>
<div><br></div><div>If on the other hand we go with the new switch proposal=
, where fallthroughs must be made explicit, isn&#39;t it more clear to use =
continue instead of the rather awkward [[fallthrough]]?</div><div>=A0</div>
<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"><div><div class=3D"h5"><div=
></div><br><br>On Friday, November 15, 2013 8:30:11 PM UTC-6, Andrew Tomazo=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">On Saturday, November 16, 2013 2:56:35 AM UTC+1, Billy O&#=
39;Neal wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
>If you want compilers to emit a warning, they&#39;ve always been able to d=
o that. You don&#39;t want to all the sudden make huge Huge HUGE amounts of=
 code ill formed on a whim like this. If people want warnings, many impleme=
ntations are quire happy to give them warnings.</div>
</div></blockquote><div><br></div><div>Yeah, you&#39;re right. =A0We can&#3=
9;t even realistically emit a warning actually. =A0There is a huge amount o=
f code that uses implicit fallthrough intentionally, and no-one is going to=
 go through and update it all. =A0We need to solve accidental fallthrough t=
he same way we did with unscoped to scoped enumerations. =A0Introduce a new=
 syntax with the new behaviour. =A0I propose &quot;new switch&quot;. =A0Tha=
t is add to selection-statement:</div>
<div><font face=3D"courier new, monospace"><br></font></div><div><div><font=
 face=3D"courier new, monospace">=A0 =A0 selection-statement:</font></div><=
div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 if ( condition ) =
statement</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 if ( condition )=
 statement else statement</font></div><div><font face=3D"courier new, monos=
pace">=A0 =A0 =A0 =A0 switch ( condition ) statement</font></div><div><font=
 face=3D"courier new, monospace">=A0 =A0 =A0 =A0 new switch ( condition ) s=
tatement =A0 =A0&lt;--- HERE</font></div>
<div><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"arial, sans-serif">and within a new switch implicit faillthrough is ill=
-formed (diagnostic required).</font></div><div>=A0<br></div></div><div>The=
n add to:</div>
<div><br></div><div><div><font face=3D"courier new, monospace">=A0 =A0 jump=
-statement:</font></div><div><font face=3D"courier new, monospace">=A0 =A0 =
=A0 =A0 break;</font></div><div><font face=3D"courier new, monospace">=A0 =
=A0 =A0 =A0 continue;</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 return expressio=
n_opt;</font></div><div><font face=3D"courier new, monospace">=A0 =A0 =A0 =
=A0 return braced-init-list ;</font></div><div><font face=3D"courier new, m=
onospace">=A0 =A0 =A0 =A0 goto identifier ;</font></div>
</div><div><div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 goto =
case constant-expression; =A0 &lt;--- HERE</font></div></div><div><div><fon=
t face=3D"courier new, monospace">=A0 =A0 =A0 =A0 goto default; =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0&lt;--- AND HERE</font></div>
</div><div><font face=3D"courier new, monospace"><br></font></div><div><fon=
t face=3D"courier new, monospace">goto case transfers control to that case,=
 and goto default to the default case.</font></div><div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div></div><div>I&#39;m confused about the usefulness of t=
he goto case label statement. If you want to jump to a completely unrelated=
 part of the switch, then use plain goto. What you&#39;re doing is evil, an=
d you should have to use an evil construct like plain goto to solve it.</di=
v>
</div></blockquote><div>=A0</div><div>a &quot;case x:&quot; doesn&#39;t act=
ually introduce a label, it&#39;s a constant expression. and cannot be used=
 as the target of a goto, so we need a new syntax &quot;goto label expr&quo=
t;. =A0Using it is exactly as evil as using a fallthrough or a goto, and gi=
ven the statement starts with the keyword goto, this is pretty clear.</div>
<div><br></div><div>We then teach everyone to always use &quot;new switch&q=
uot; from now on instead of &quot;switch&quot;.</div><div><br></div></div><=
/blockquote></div></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@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></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2c1261339bf04eb4cdcb7--

.

------=_Part_1620_24711376.1384657488690
Content-Type: text/plain; charset=ISO-8859-1

On Saturday, November 16, 2013 10:20:49 AM UTC-5, Xavi Gratal wrote:

> Being able to break a loop from a switch is indeed interesting. However, I
> don't like that you need a goto to have to cases that do exactly the same,
> and if an empty case automatically falls through, then there is no way to
> have a case that does absolutely nothing. Maybe a case with a single ;
> should do exactly that?
>

You could also just put the empty cases at the end of the switch.


> If on the other hand we go with the new switch proposal, where
> fallthroughs must be made explicit, isn't it more clear to use continue
> instead of the rather awkward [[fallthrough]]?
>

Then you'd lose the ability to move on to the next iteration of the outer
loop.

--

---
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_1620_24711376.1384657488690
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span style=3D"font-size: 13px;">On Saturday, November 16,=
 2013 10:20:49 AM UTC-5, Xavi Gratal wrote:</span><br><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>Be=
ing able to break a loop from a switch is indeed interesting. However, I do=
n't like that you need a goto to have to cases that do exactly the same, an=
d if an empty case automatically falls through, then there is no way to hav=
e a case that does absolutely nothing. Maybe a case with a single ; should =
do exactly that?</div></div></div></blockquote><div><br></div><div>You coul=
d also just put the empty cases at the end of the switch.</div><div>&nbsp;<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div cla=
ss=3D"gmail_quote">
<div><span style=3D"font-size: 13px;">If on the other hand we go with the n=
ew switch proposal, where fallthroughs must be made explicit, isn't it more=
 clear to use continue instead of the rather awkward [[fallthrough]]?</span=
></div></div></div></blockquote><div><span style=3D"font-size: 13px;"><br><=
/span></div><div><span style=3D"font-size: 13px;">Then you'd lose the abili=
ty to move on to the next iteration of the outer loop.</span></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1620_24711376.1384657488690--

.

--001a11c2bd8ef425d404eb56c2bb
Content-Type: text/plain; charset=ISO-8859-1

2013/11/17 Greg Marr <gregmmarr@gmail.com>

> On Saturday, November 16, 2013 10:20:49 AM UTC-5, Xavi Gratal wrote:
>
>> Being able to break a loop from a switch is indeed interesting. However,
>> I don't like that you need a goto to have to cases that do exactly the
>> same, and if an empty case automatically falls through, then there is no
>> way to have a case that does absolutely nothing. Maybe a case with a single
>> ; should do exactly that?
>>
>
> You could also just put the empty cases at the end of the switch.
>
>
>> If on the other hand we go with the new switch proposal, where
>> fallthroughs must be made explicit, isn't it more clear to use continue
>> instead of the rather awkward [[fallthrough]]?
>>
>
> Then you'd lose the ability to move on to the next iteration of the outer
> loop.
>

I know, that was only for the 'new switch' proposal where breaks are still
necessary and fallthroughs must be annotated.
For the 'switch auto break' proposal, which allows breaking the outer loop,
goto seems like a better option.

>  --
>
> ---
> 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/.

--001a11c2bd8ef425d404eb56c2bb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2013/11/17 Greg Marr <span dir=3D"ltr">&lt;<a href=3D"mailto:gregmm=
arr@gmail.com" target=3D"_blank">gregmmarr@gmail.com</a>&gt;</span><br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im"><span style=3D"font-size:13px">On Saturd=
ay, November 16, 2013 10:20:49 AM UTC-5, Xavi Gratal wrote:</span><br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_quote"><div>Being able to break a loop=
 from a switch is indeed interesting. However, I don&#39;t like that you ne=
ed a goto to have to cases that do exactly the same, and if an empty case a=
utomatically falls through, then there is no way to have a case that does a=
bsolutely nothing. Maybe a case with a single ; should do exactly that?</di=
v>
</div></div></blockquote><div><br></div></div><div>You could also just put =
the empty cases at the end of the switch.</div><div class=3D"im"><div>=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_quote">
<div><span style=3D"font-size:13px">If on the other hand we go with the new=
 switch proposal, where fallthroughs must be made explicit, isn&#39;t it mo=
re clear to use continue instead of the rather awkward [[fallthrough]]?</sp=
an></div>
</div></div></blockquote><div><span style=3D"font-size:13px"><br></span></d=
iv></div><div><span style=3D"font-size:13px">Then you&#39;d lose the abilit=
y to move on to the next iteration of the outer loop.</span></div></div></b=
lockquote>
<div><br></div><div>I know, that was only for the &#39;new switch&#39; prop=
osal where breaks are still necessary and fallthroughs must be annotated.=
=A0</div><div>For the &#39;switch auto break&#39; proposal, which allows br=
eaking the outer loop, goto seems like a better option.</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@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></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2bd8ef425d404eb56c2bb--

.

------=_Part_1749_18558555.1384688599269
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

In this thread I have seen mentions of four different problems with switch=
=20
that I think we all would like solved:

1. Accidental fall through.

2. Ability to use break to get out of surrounding loop.

3. Get rid of the annoying lack of separate declaration scope for each case=
..

4. The problem when two or more cases want to continue into the same=20
succeding case, but not through each other's code.

To solve #1 it has been suggested to annotate the switch statement itself=
=20
"new" or "auto break" to avoid affecting old code. The alternative would be=
=20
to let each case expression be "old" or "new" style and let users mix. This=
=20
would be messy if people actually chose to mix cases but it could be quite=
=20
clean if only new style cases are used. I suggest that this could be=20
indicated by writing case <value> { ... code ... }, that is to skip the=20
colon. This type of case does not fall through, interprets break as for the=
=20
outer loop and (naturally) introduces a variable scope. It does nothing to=
=20
solve issue 4, but a separate goto case <value> as suggested earlier could=
=20
handle that part of the problem. Old style cases should probably be allowed=
=20
to fall through into new style cases. This reduces the use of goto case=20
constructs to problem 4 only.

Example:

while (true) {
    switch (mode) {
    case STD:          // Old style fall through
         x =3D 1;
    case EXTRA=20
       {
          MyClass obj;    // Declare object in local scope
          DoFunction();   // New style case which auto-breaks
       }

    case ABNORMAL {
         x =3D 2;
         goto case EXTRA;   // Jump into EXTRA without setting x to 1.
       }

    case FOO:
        break;       // Break switch

    case FUM {
        break;       // Break loop
     }
 }


I think that a big advantage with this approach would be that you don't=20
have to write extra keywords at the switch to get a "new" style. Having to=
=20
add keywords, especially 'new' will seem rather strange 20 years from now.

The worst drawback may be the different meanings of the break statements in=
=20
the two last cases. I have had one idea before that would allow breaking=20
out of the loop without redefining the use of break in a switch: Allow more=
=20
than one of the break and continue keywords if you want to affect more than=
=20
one nested control statement. In the example above you could could break=20
the loop by writing "break break;". For nested loops this could also be=20
written "break continue;" etc. in any combination.



Den s=F6ndagen den 17:e november 2013 kl. 04:09:37 UTC+1 skrev Xavi Gratal:
>
>
>
>
> 2013/11/17 Greg Marr <greg...@gmail.com <javascript:>>
>
>> On Saturday, November 16, 2013 10:20:49 AM UTC-5, Xavi Gratal wrote:
>>
>>> Being able to break a loop from a switch is indeed interesting. However=
,=20
>>> I don't like that you need a goto to have to cases that do exactly the=
=20
>>> same, and if an empty case automatically falls through, then there is n=
o=20
>>> way to have a case that does absolutely nothing. Maybe a case with a si=
ngle=20
>>> ; should do exactly that?
>>>
>>
>> You could also just put the empty cases at the end of the switch.
>> =20
>>
>>>  If on the other hand we go with the new switch proposal, where=20
>>> fallthroughs must be made explicit, isn't it more clear to use continue=
=20
>>> instead of the rather awkward [[fallthrough]]?
>>>
>>
>> Then you'd lose the ability to move on to the next iteration of the oute=
r=20
>> loop.
>>
>
> I know, that was only for the 'new switch' proposal where breaks are stil=
l=20
> necessary and fallthroughs must be annotated.=20
> For the 'switch auto break' proposal, which allows breaking the outer=20
> loop, goto seems like a better option.
>
>>  --=20
>> =20
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=20

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

------=_Part_1749_18558555.1384688599269
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In this thread I have seen mentions of four different prob=
lems with switch that I think we all would like solved:<div><br></div><div>=
1. Accidental fall through.</div><div><br></div><div>2. Ability to use brea=
k to get out of surrounding loop.</div><div><br></div><div>3. Get rid of th=
e annoying lack of separate declaration scope for each case.</div><div><br>=
</div><div>4. The problem when two or more cases want to continue into the =
same succeding case, but not through each other's code.</div><div><br></div=
><div>To solve #1 it has been suggested to annotate the switch statement it=
self "new" or "auto break" to avoid affecting old code. The alternative wou=
ld be to let each case expression be "old" or "new" style and let users mix=
.. This would be messy if people actually chose to mix cases but it could be=
 quite clean if only new style cases are used. I suggest that this could be=
 indicated by writing case &lt;value&gt; { ... code ... }, that is to skip =
the colon. This type of case does not fall through, interprets break as for=
 the outer loop and (naturally) introduces a variable scope. It does nothin=
g to solve issue 4, but a separate goto case &lt;value&gt; as suggested ear=
lier could handle that part of the problem. Old style cases should probably=
 be allowed to fall through into new style cases. This reduces the use of g=
oto case constructs to problem 4 only.</div><div><br></div><div>Example:</d=
iv><div><br></div><div>while (true) {</div><div>&nbsp; &nbsp; switch (mode)=
 {</div><div>&nbsp; &nbsp; case STD: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// O=
ld style fall through</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;x =3D 1;<=
/div><div>&nbsp; &nbsp; case EXTRA&nbsp;</div><div>&nbsp; &nbsp; &nbsp; &nb=
sp;{</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; MyClass obj; &nbsp; &nbsp=
;// Declare object in local scope</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nb=
sp; DoFunction(); &nbsp; // New style case which auto-breaks</div><div>&nbs=
p; &nbsp; &nbsp; &nbsp;}</div><div><br></div><div>&nbsp; &nbsp; case ABNORM=
AL {</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;x =3D 2;</div><div>&nbsp; =
&nbsp; &nbsp; &nbsp; &nbsp;goto case EXTRA; &nbsp; // Jump into EXTRA witho=
ut setting x to 1.</div><div>&nbsp; &nbsp; &nbsp; &nbsp;}</div><div><br></d=
iv><div>&nbsp; &nbsp; case FOO:</div><div>&nbsp; &nbsp; &nbsp; &nbsp; break=
; &nbsp; &nbsp; &nbsp; // Break switch</div><div><br></div><div>&nbsp; &nbs=
p; case FUM {</div><div>&nbsp; &nbsp; &nbsp; &nbsp; break; &nbsp; &nbsp; &n=
bsp; // Break loop</div><div>&nbsp; &nbsp; &nbsp;}</div><div>&nbsp;}</div><=
div><br></div><div><br></div><div>I think that a big advantage with this ap=
proach would be that you don't have to write extra keywords at the switch t=
o get a "new" style. Having to add keywords, especially 'new' will seem rat=
her strange 20 years from now.</div><div><br></div><div>The worst drawback =
may be the different meanings of the break statements in the two last cases=
.. I have had one idea before that would allow breaking out of the loop with=
out redefining the use of break in a switch: Allow more than one of the bre=
ak and continue keywords if you want to affect more than one nested control=
 statement. In the example above you could could break the loop by writing =
"break break;". For nested loops this could also be written "break continue=
;" etc. in any combination.<br><br><br><br>Den s=F6ndagen den 17:e november=
 2013 kl. 04:09:37 UTC+1 skrev Xavi Gratal:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div dir=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">2=
013/11/17 Greg Marr <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"QLW-b3cG1wIJ">greg...@gmail.com</a>&gt;</=
span><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><span style=3D"font-size:13px">On Saturday, November =
16, 2013 10:20:49 AM UTC-5, Xavi Gratal wrote:</span><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_quote"><div>Being able to break a loop=
 from a switch is indeed interesting. However, I don't like that you need a=
 goto to have to cases that do exactly the same, and if an empty case autom=
atically falls through, then there is no way to have a case that does absol=
utely nothing. Maybe a case with a single ; should do exactly that?</div>
</div></div></blockquote><div><br></div></div><div>You could also just put =
the empty cases at the end of the switch.</div><div><div>&nbsp;</div><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_quote">
<div><span style=3D"font-size:13px">If on the other hand we go with the new=
 switch proposal, where fallthroughs must be made explicit, isn't it more c=
lear to use continue instead of the rather awkward [[fallthrough]]?</span><=
/div>
</div></div></blockquote><div><span style=3D"font-size:13px"><br></span></d=
iv></div><div><span style=3D"font-size:13px">Then you'd lose the ability to=
 move on to the next iteration of the outer loop.</span></div></div></block=
quote>
<div><br></div><div>I know, that was only for the 'new switch' proposal whe=
re breaks are still necessary and fallthroughs must be annotated.&nbsp;</di=
v><div>For the 'switch auto break' proposal, which allows breaking the oute=
r loop, goto seems like a better option.</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div>

<p></p>

-- <br>
&nbsp;<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 e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
QLW-b3cG1wIJ">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"QLW-b3cG1wIJ">std-pr...@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/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
</blockquote></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1749_18558555.1384688599269--

.

On 17 November 2013 13:43, Bengt Gustafsson
<bengt.gustafsson@beamways.com> wrote:
> I think that a big advantage with this approach would be that you don't have
> to write extra keywords at the switch to get a "new" style. Having to add
> keywords, especially 'new' will seem rather strange 20 years from now.


I see that as a big disadvantage, and I find it strange now and X
years from now.

If you want a switch-on-steroids, don't call it switch. It's a
different facility, so
find a different name and don't deliberately confuse it with the existing beast.

--

---
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_152_11721307.1384694222900
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

How about allowing a comma separated list of values after case to signify=
=20
that the following block should apply to multiple cases? I would find that=
=20
the clearest and least verbose solution to what is arguably the most=20
important use of fall-through in practice.


On Sunday, 17 November 2013 12:43:19 UTC+1, Bengt Gustafsson wrote:
>
> In this thread I have seen mentions of four different problems with switc=
h=20
> that I think we all would like solved:
>
> 1. Accidental fall through.
>
> 2. Ability to use break to get out of surrounding loop.
>
> 3. Get rid of the annoying lack of separate declaration scope for each=20
> case.
>
> 4. The problem when two or more cases want to continue into the same=20
> succeding case, but not through each other's code.
>
> To solve #1 it has been suggested to annotate the switch statement itself=
=20
> "new" or "auto break" to avoid affecting old code. The alternative would =
be=20
> to let each case expression be "old" or "new" style and let users mix. Th=
is=20
> would be messy if people actually chose to mix cases but it could be quit=
e=20
> clean if only new style cases are used. I suggest that this could be=20
> indicated by writing case <value> { ... code ... }, that is to skip the=
=20
> colon. This type of case does not fall through, interprets break as for t=
he=20
> outer loop and (naturally) introduces a variable scope. It does nothing t=
o=20
> solve issue 4, but a separate goto case <value> as suggested earlier coul=
d=20
> handle that part of the problem. Old style cases should probably be allow=
ed=20
> to fall through into new style cases. This reduces the use of goto case=
=20
> constructs to problem 4 only.
>
> Example:
>
> while (true) {
>     switch (mode) {
>     case STD:          // Old style fall through
>          x =3D 1;
>     case EXTRA=20
>        {
>           MyClass obj;    // Declare object in local scope
>           DoFunction();   // New style case which auto-breaks
>        }
>
>     case ABNORMAL {
>          x =3D 2;
>          goto case EXTRA;   // Jump into EXTRA without setting x to 1.
>        }
>
>     case FOO:
>         break;       // Break switch
>
>     case FUM {
>         break;       // Break loop
>      }
>  }
>
>
> I think that a big advantage with this approach would be that you don't=
=20
> have to write extra keywords at the switch to get a "new" style. Having t=
o=20
> add keywords, especially 'new' will seem rather strange 20 years from now=
..
>
> The worst drawback may be the different meanings of the break statements=
=20
> in the two last cases. I have had one idea before that would allow breaki=
ng=20
> out of the loop without redefining the use of break in a switch: Allow mo=
re=20
> than one of the break and continue keywords if you want to affect more th=
an=20
> one nested control statement. In the example above you could could break=
=20
> the loop by writing "break break;". For nested loops this could also be=
=20
> written "break continue;" etc. in any combination.
>
>
>
> Den s=F6ndagen den 17:e november 2013 kl. 04:09:37 UTC+1 skrev Xavi Grata=
l:
>>
>>
>>
>>
>> 2013/11/17 Greg Marr <greg...@gmail.com>
>>
>>> On Saturday, November 16, 2013 10:20:49 AM UTC-5, Xavi Gratal wrote:
>>>
>>>> Being able to break a loop from a switch is indeed interesting.=20
>>>> However, I don't like that you need a goto to have to cases that do ex=
actly=20
>>>> the same, and if an empty case automatically falls through, then there=
 is=20
>>>> no way to have a case that does absolutely nothing. Maybe a case with =
a=20
>>>> single ; should do exactly that?
>>>>
>>>
>>> You could also just put the empty cases at the end of the switch.
>>> =20
>>>
>>>>  If on the other hand we go with the new switch proposal, where=20
>>>> fallthroughs must be made explicit, isn't it more clear to use continu=
e=20
>>>> instead of the rather awkward [[fallthrough]]?
>>>>
>>>
>>> Then you'd lose the ability to move on to the next iteration of the=20
>>> outer loop.
>>>
>>
>> I know, that was only for the 'new switch' proposal where breaks are=20
>> still necessary and fallthroughs must be annotated.=20
>> For the 'switch auto break' proposal, which allows breaking the outer=20
>> loop, goto seems like a better option.
>>
>>>  --=20
>>> =20
>>> ---=20
>>> You received this message because you are subscribed to the Google=20
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> Visit this group at=20
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>

--=20

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

------=_Part_152_11721307.1384694222900
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">How about allowing a comma separated list of values after =
<span style=3D"font-family: courier new,monospace;">case<span style=3D"font=
-family: arial,sans-serif;"> to signify that the following block should app=
ly to multiple cases? I would find that the</span></span><span style=3D"fon=
t-family: courier new,monospace;"><span style=3D"font-family: arial,sans-se=
rif;"><span style=3D"font-family: courier new,monospace;"><span style=3D"fo=
nt-family: arial,sans-serif;"> clearest and</span></span> least verbose sol=
ution to what is arguably the most important use of fall-through in practic=
e</span></span>.<br><br><br>On Sunday, 17 November 2013 12:43:19 UTC+1, Ben=
gt Gustafsson  wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">In this thread I have seen mentions of four different problems wit=
h switch that I think we all would like solved:<div><br></div><div>1. Accid=
ental fall through.</div><div><br></div><div>2. Ability to use break to get=
 out of surrounding loop.</div><div><br></div><div>3. Get rid of the annoyi=
ng lack of separate declaration scope for each case.</div><div><br></div><d=
iv>4. The problem when two or more cases want to continue into the same suc=
ceding case, but not through each other's code.</div><div><br></div><div>To=
 solve #1 it has been suggested to annotate the switch statement itself "ne=
w" or "auto break" to avoid affecting old code. The alternative would be to=
 let each case expression be "old" or "new" style and let users mix. This w=
ould be messy if people actually chose to mix cases but it could be quite c=
lean if only new style cases are used. I suggest that this could be indicat=
ed by writing case &lt;value&gt; { ... code ... }, that is to skip the colo=
n. This type of case does not fall through, interprets break as for the out=
er loop and (naturally) introduces a variable scope. It does nothing to sol=
ve issue 4, but a separate goto case &lt;value&gt; as suggested earlier cou=
ld handle that part of the problem. Old style cases should probably be allo=
wed to fall through into new style cases. This reduces the use of goto case=
 constructs to problem 4 only.</div><div><br></div><div>Example:</div><div>=
<br></div><div>while (true) {</div><div>&nbsp; &nbsp; switch (mode) {</div>=
<div>&nbsp; &nbsp; case STD: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Old style=
 fall through</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;x =3D 1;</div><di=
v>&nbsp; &nbsp; case EXTRA&nbsp;</div><div>&nbsp; &nbsp; &nbsp; &nbsp;{</di=
v><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; MyClass obj; &nbsp; &nbsp;// Decl=
are object in local scope</div><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; DoFu=
nction(); &nbsp; // New style case which auto-breaks</div><div>&nbsp; &nbsp=
; &nbsp; &nbsp;}</div><div><br></div><div>&nbsp; &nbsp; case ABNORMAL {</di=
v><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;x =3D 2;</div><div>&nbsp; &nbsp; &=
nbsp; &nbsp; &nbsp;goto case EXTRA; &nbsp; // Jump into EXTRA without setti=
ng x to 1.</div><div>&nbsp; &nbsp; &nbsp; &nbsp;}</div><div><br></div><div>=
&nbsp; &nbsp; case FOO:</div><div>&nbsp; &nbsp; &nbsp; &nbsp; break; &nbsp;=
 &nbsp; &nbsp; // Break switch</div><div><br></div><div>&nbsp; &nbsp; case =
FUM {</div><div>&nbsp; &nbsp; &nbsp; &nbsp; break; &nbsp; &nbsp; &nbsp; // =
Break loop</div><div>&nbsp; &nbsp; &nbsp;}</div><div>&nbsp;}</div><div><br>=
</div><div><br></div><div>I think that a big advantage with this approach w=
ould be that you don't have to write extra keywords at the switch to get a =
"new" style. Having to add keywords, especially 'new' will seem rather stra=
nge 20 years from now.</div><div><br></div><div>The worst drawback may be t=
he different meanings of the break statements in the two last cases. I have=
 had one idea before that would allow breaking out of the loop without rede=
fining the use of break in a switch: Allow more than one of the break and c=
ontinue keywords if you want to affect more than one nested control stateme=
nt. In the example above you could could break the loop by writing "break b=
reak;". For nested loops this could also be written "break continue;" etc. =
in any combination.<br><br><br><br>Den s=F6ndagen den 17:e november 2013 kl=
.. 04:09:37 UTC+1 skrev Xavi Gratal:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><br><div><br><br><div class=3D"gmail_quote">2013/11/17 Gr=
eg Marr <span dir=3D"ltr">&lt;<a>greg...@gmail.com</a>&gt;</span><br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex">
<div dir=3D"ltr"><div><span style=3D"font-size:13px">On Saturday, November =
16, 2013 10:20:49 AM UTC-5, Xavi Gratal wrote:</span><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_quote"><div>Being able to break a loop=
 from a switch is indeed interesting. However, I don't like that you need a=
 goto to have to cases that do exactly the same, and if an empty case autom=
atically falls through, then there is no way to have a case that does absol=
utely nothing. Maybe a case with a single ; should do exactly that?</div>
</div></div></blockquote><div><br></div></div><div>You could also just put =
the empty cases at the end of the switch.</div><div><div>&nbsp;</div><block=
quote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left=
:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_quote">
<div><span style=3D"font-size:13px">If on the other hand we go with the new=
 switch proposal, where fallthroughs must be made explicit, isn't it more c=
lear to use continue instead of the rather awkward [[fallthrough]]?</span><=
/div>
</div></div></blockquote><div><span style=3D"font-size:13px"><br></span></d=
iv></div><div><span style=3D"font-size:13px">Then you'd lose the ability to=
 move on to the next iteration of the outer loop.</span></div></div></block=
quote>
<div><br></div><div>I know, that was only for the 'new switch' proposal whe=
re breaks are still necessary and fallthroughs must be annotated.&nbsp;</di=
v><div>For the 'switch auto break' proposal, which allows breaking the oute=
r loop, goto seems like a better option.</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div>

<p></p>

-- <br>
&nbsp;<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 e=
mail to <a>std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@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/<wbr>isocpp.or=
g/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
</blockquote></div></div></blockquote></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_152_11721307.1384694222900--

.

On 17 November 2013 15:17, Christian Kaeser
<christiankaeser87@googlemail.com> wrote:
> How about allowing a comma separated list of values after case to signify
> that the following block should apply to multiple cases? I would find that
> the clearest and least verbose solution to what is arguably the most
> important use of fall-through in practice.


That I can actually stomach, since it's not changing the control flow
of the cases themselves.

--

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

.

On domingo, 17 de novembro de 2013 03:43:19, Bengt Gustafsson wrote:
>  I suggest that this could be
> indicated by writing case <value> { ... code ... }, that is to skip the
> colon.

I'm sorry, I think this is going to lead to confusion. A colon is, in many
fonts, barely readable. It's very easy to miss it or to add it when not
needed:

switch (x) {
    case 1: {
        foo();
    }
    case 2 {
        bar();
    }
}

Was the colon intended in the first case label? If it was, was the fall-through
intentional or did we forget a break?

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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/.

.