------=_Part_219_29835758.1391789767267
Content-Type: text/plain; charset=UTF-8

Thanks for your feedback.  Based on previous threads I have submitted a
proposed wording in the last mailing as N3879:

    http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3879.pdf

I didn't have time to document all the background and rationale
unfortunately, but wanted to at least get concrete wording done.  (If
someone reading this is going to Issequah and remembers, can you please
mention to EWG that my intention is to present this at Rapperswil - but if
you want to chat about it at Issequah as well without me that is fine too.)

As a quick delta for those that followed previous discussions: I have
merged everything and backed it off to only include what is already tested
by Java and C#.  Ultimately, I felt this was the most convincing argument -
that these semantics have and continue to be used by millions of
programmers - so that existing practice makes it low risk - and nullifies
the argument that this "new stuff" will just have its own "new problems".

On Friday, February 7, 2014 1:49:47 PM UTC+1, masse....@gmail.com wrote:

> - I'm a bit perturbed by the idea of adding a new switch statement. I find
> it quite unclear for newcomers. Also It could be difficult to know when we
> are in the middle of some code if we are inside a switch or insde an
> explicit switch statement. (Typically, we'll have to scroll to the
> enclosing switch statement to know that).
>

We can't change the semantics of the old switch statement, so making it
possible to "opt-in" to the new semantics with an explicit-specifier (like
explicit constructors or override member functions or different cast
flavors or braced-init-lists etc etc), is better than doing nothing.  We
trade off a little complexity (not much as can be seen by the wording) for
offering a new better alternative.  Having said that, there isn't so much
different between an explicit switch and a non-explicit switch.  Each "case
block" is its own substatement with a block scope, and you can't flow off
the end of it.  Those are the only differences, calling it a new switch
statement is an overstatement.  It is just an alternative flavor of the
existing statement.

- the"goto case *label"* seems to be a nice solution to me. I makes thing
> clear on what the code does, and also could avoid errors when reorganizing
> the order of the labels inside a switch statement. Personnally, I'm in
> favor of this solution instead of the addition of a [[fall]] attribute for
> example.
>

Yes, I agree.  goto case is more general and explicitly binds the target
case by value.  This is clearly superior to a fallthrough statement, even
for the consecutive cases, as it is robust to change.  When you think about
it, the switch statement should be an unordered set of separate case
handler blocks.  Syntactically consecutive cases shouldn't have any sort of
special semantic relationship, so in an explicit switch statement they are
decoupled (unless explicitly joined with a goto case statement).  This is
the same decoupling as you would expect - and the same decoupling as the
two substatements of an if-else statement.


> - AFAIK, the addition of the "goto case *label" *could be made in the
> existing switch statement. It does not require a new explicit switch
> statement and won't break existing code.
>

A goto case statement binds to its smallest enclosing switch statement
(both non-explicit and explicit ones).  So yes, you can use the statement
in both.  The proposal doesn't break existing code.


> - For existing code, the compilers could be made so that they will emit a
> warning if there is an implicit fallthrouh in the code.  Going further, we
> could imagine that some of them will add a flag to make implicit fallthrouh
> resulting in an error instead of a warning. Anyway, that's outside the
> scope of the standard. The only things here is that implicit fallthrouh
> should still compile by default.
>

Implicit fallthrough is used intentionally as a feature in 3% of existing
cases.  That's an unbelievably large amount of code, so no, you can't emit
a warning or an error or have a global option.  We have to leave the
existing code and semantics alone.  The only thing we can do is add a way
for programmers to opt-in to the new semantics on a switch-by-switch basis.
 That is what the proposed explicit-specifier is.


> - for local variables declarations, the current statement could be changed
> so that each variable declaration inside a case statement (or the default
> statement) is local to the case/default statment instead of being local to
> the whole switch statement. Note that such a changes could potentially
> break existing code if a variable is declared inside a case and used inside
> another case. (Having an idea on how much code will be affected by such a
> changes could be interesting).
>
- I the above solution can't be done because it will break too much code,
> then the solution of adding extra braces could be keept. In the end, that's
> not something really problematic once you know how it works.
>

It's true that generally speaking in practice jump-past-initialization is
warned against, so there isn't as much code that uses it as there is
implicit fallthrough.  For that reason, we consider it in practice
ill-formed from a design POV.  So all the explicit specifier does is allow
you to declare local variables without surrounding the case block in
"redundant" braces.  Formally however, introducing a new scope for each
case block is a new semantic, so we can't change it in non-explicit
switches.  We therefore only make the change in the new explicit switches.

In summary, essentially what you propose is to change the existing switch
statement to have the explicit switch semantics.  We can't do that because
it will break existing code - so we take the next best option and make
available an explicit-specifier that allows the programmer to opt-in to the
changes on a switch-by-switch basis in new code.

--

---
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_219_29835758.1391789767267
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Thanks for your feedback. &nbsp;Based on previou=
s threads I have submitted a proposed wording in the last mailing as N3879:=
<br></div></div><br>&nbsp; &nbsp; http://open-std.org/jtc1/sc22/wg21/docs/p=
apers/2014/n3879.pdf<div><br></div><div>I didn't have time to document all =
the background and rationale unfortunately, but wanted to at least get conc=
rete wording done. &nbsp;(If someone reading this is going to Issequah and =
remembers, can you please mention to EWG that my intention is to present th=
is at Rapperswil - but if you want to chat about it at Issequah as well wit=
hout me that is fine too.)</div><div><br></div><div>As a quick delta for th=
ose that followed previous discussions: I have merged everything and backed=
 it off to only include what is already tested by Java and C#. &nbsp;Ultima=
tely, I felt this was the most convincing argument - that these semantics h=
ave and continue to be used by millions of programmers - so that existing p=
ractice makes it low risk - and nullifies the argument that this "new stuff=
" will just have its own "new problems".</div><div><br></div><div><div><div=
>On Friday, February 7, 2014 1:49:47 PM UTC+1, masse....@gmail.com wrote:<b=
r></div><div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); bord=
er-left-style: solid; padding-left: 1ex;"></blockquote></div></div></div><d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bo=
rder-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-st=
yle: solid; padding-left: 1ex;"><div dir=3D"ltr">- I'm a bit perturbed by t=
he idea of adding a new switch statement. I find it quite unclear for newco=
mers. Also It could be difficult to know when we are in the middle of some =
code if we are inside a switch or insde an explicit switch statement. (Typi=
cally, we'll have to scroll to the enclosing switch statement to know that)=
..<br></div></blockquote><div><br></div><div>We can't change the semantics o=
f the old switch statement, so making it possible to "opt-in" to the new se=
mantics with an explicit-specifier (like explicit constructors or override =
member functions or different cast flavors or braced-init-lists etc etc), i=
s better than doing nothing. &nbsp;We trade off a little complexity (not mu=
ch as can be seen by the wording) for offering a new better alternative. &n=
bsp;Having said that, there isn't so much different between an explicit swi=
tch and a non-explicit switch. &nbsp;Each "case block" is its own substatem=
ent with a block scope, and you can't flow off the end of it. &nbsp;Those a=
re the only differences, calling it a new switch statement is an overstatem=
ent. &nbsp;It is just an alternative flavor of the existing statement.</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); b=
order-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr">- the"goto ca=
se&nbsp;<i>label"</i>&nbsp;seems to be a nice solution to me. I makes thing=
 clear on what the code does, and also could avoid errors when reorganizing=
 the order of the labels inside a switch statement. Personnally, I'm in fav=
or of this solution instead of the addition of a [[fall]] attribute for exa=
mple.<br></div></blockquote><div><br></div><div>Yes, I agree. &nbsp;goto ca=
se is more general and explicitly binds the target case by value. &nbsp;Thi=
s is clearly superior to a fallthrough statement, even for the consecutive =
cases, as it is robust to change. &nbsp;When you think about it, the switch=
 statement should be an unordered set of separate case handler blocks. &nbs=
p;Syntactically consecutive cases shouldn't have any sort of special semant=
ic relationship, so in an explicit switch statement they are decoupled (unl=
ess explicitly joined with a goto case statement). &nbsp;This is the same d=
ecoupling as you would expect - and the same decoupling as the two substate=
ments of an if-else statement.</div><div>&nbsp;</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; bor=
der-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left:=
 1ex;"><div dir=3D"ltr">- AFAIK, the addition of the "goto case&nbsp;<i>lab=
el"&nbsp;</i>could<i>&nbsp;</i>be made in the existing switch statement. It=
 does not require a new explicit switch statement and won't break existing =
code.<br></div></blockquote><div><br></div><div>A goto case statement binds=
 to its smallest enclosing switch statement (both non-explicit and explicit=
 ones). &nbsp;So yes, you can use the statement in both. &nbsp;The proposal=
 doesn't break existing code.</div><div>&nbsp;<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px=
; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-=
left: 1ex;"><div dir=3D"ltr">- For existing code, the compilers could be ma=
de so that they will emit a warning if there is an implicit fallthrouh in t=
he code. &nbsp;Going further, we could imagine that some of them will add a=
 flag to make implicit fallthrouh resulting in an error instead of a warnin=
g. Anyway, that's outside the scope of the standard. The only things here i=
s that implicit fallthrouh should still compile by default.</div></blockquo=
te><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bo=
rder-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-st=
yle: solid; padding-left: 1ex;"><div dir=3D"ltr"></div></blockquote><div><b=
r></div><div>Implicit fallthrough is used intentionally as a feature in 3% =
of existing cases. &nbsp;That's an unbelievably large amount of code, so no=
, you can't emit a warning or an error or have a global option. &nbsp;We ha=
ve to leave the existing code and semantics alone. &nbsp;The only thing we =
can do is add a way for programmers to opt-in to the new semantics on a swi=
tch-by-switch basis. &nbsp;That is what the proposed explicit-specifier is.=
</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, =
204); border-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr">- for =
local variables declarations, the current statement could be changed so tha=
t each variable declaration inside a case statement (or the default stateme=
nt) is local to the case/default statment instead of being local to the who=
le switch statement. Note that such a changes could potentially break exist=
ing code if a variable is declared inside a case and used inside another ca=
se. (Having an idea on how much code will be affected by such a changes cou=
ld be interesting).<br></div></blockquote><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-co=
lor: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"><div=
 dir=3D"ltr">- I the above solution can't be done because it will break too=
 much code, then the solution of adding extra braces could be keept. In the=
 end, that's not something really problematic once you know how it works.</=
div></blockquote><div>&nbsp;</div><div>It's true that generally speaking in=
 practice jump-past-initialization is warned against, so there isn't as muc=
h code that uses it as there is implicit fallthrough. &nbsp;For that reason=
, we consider it in practice ill-formed from a design POV. &nbsp;So all the=
 explicit specifier does is allow you to declare local variables without su=
rrounding the case block in "redundant" braces. &nbsp;Formally however, int=
roducing a new scope for each case block is a new semantic, so we can't cha=
nge it in non-explicit switches. &nbsp;We therefore only make the change in=
 the new explicit switches.<br></div></div><div><br></div><div>In summary, =
essentially what you propose is to change the existing switch statement to =
have the explicit switch semantics. &nbsp;We can't do that because it will =
break existing code - so we take the next best option and make available an=
 explicit-specifier that allows the programmer to opt-in to the changes on =
a switch-by-switch basis in new code.</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_219_29835758.1391789767267--

.

On 2014-02-07 11:16, Andrew Tomazos wrote:
>> - For existing code, the compilers could be made so that they will emit a
>> warning if there is an implicit fallthrouh in the code.  Going further, we
>> could imagine that some of them will add a flag to make implicit fallthrouh
>> resulting in an error instead of a warning. Anyway, that's outside the
>> scope of the standard. The only things here is that implicit fallthrouh
>> should still compile by default.
>
> Implicit fallthrough is used intentionally as a feature in 3% of existing
> cases.  That's an unbelievably large amount of code, so no, you can't emit
> a warning or an error or have a global option.

If I am either not in that 3%, or using compiler features to annotate
when fallthrough should be allowed, shouldn't I be allowed to tell the
compiler to disallow implicit fallthrough on my code base? (At least
clang thinks so...)

> The only thing we can do is add a way for programmers to opt-in to
> the  new semantics on a switch-by-switch basis.

A compiler option to disallow implicit fallthrough in existing switch
statements *is* opt-in.

I don't think there has been any request to have this enabled *by
default*. Rather, to standardize the method of annotating intentional
fallthrough so that code bases that want to prevent accidental
fallthrough can request that the compiler do so without having to resort
to e.g. conditional defines in the source code.


My own feedback:

> The implicit fallthrough semantic between two consecutive case blocks
> can be expressed in an explicit switch using a goto case statement
> instead.

You might want to add 'non-empty' here; when I first read it, I thought
you meant you were going to disallow:

   case a:
   case b:
     ...

....but as you then use this in examples, I assume that is not the case.

--
Matthew

--

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

.

------=_Part_943_53996.1391797159243
Content-Type: text/plain; charset=UTF-8

On Friday, February 7, 2014 6:10:08 PM UTC+1, Matthew Woehlke wrote:
>
> > Implicit fallthrough is used intentionally as a feature in 3% of
> existing
> > cases.  That's an unbelievably large amount of code, so no, you can't
> emit
> > a warning or an error or have a global option.
>
> If I am either not in that 3%, or using compiler features to annotate
> when fallthrough should be allowed, shouldn't I be allowed to tell the
> compiler to disallow implicit fallthrough on my code base? (At least
> clang thinks so...)
>

In existing standard C++ code implicit fallthrough in switches is used in
3% of case blocks (not codebases) without a fallthrough
statement/annotation to intentionally express jumping to the following
case, and has been for 40 years.  Setting up your tools such that they
would not compile this existing code just isn't going to work.  You might
want to integrate some of it into your build, and you don't want to go
through and modify existing code.  For this reason it is pretty safe to
predict that the clang option will go unused/ignored.  Just like this GCC
feature request from 2002:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

So no, a compiler flag that breaks existing code is a non-solution.  N3879
is superior as it is a pure addition, and doesn't break existing code.

> The implicit fallthrough semantic between two consecutive case blocks
> > can be expressed in an explicit switch using a goto case statement
> > instead.
>
> You might want to add 'non-empty' here; when I first read it, I thought
> you meant you were going to disallow:
>
>    case a:
>    case b:
>      ...
>
> ...but as you then use this in examples, I assume that is not the case.
>

Formally, as per N3879 (and C#) we define a case statement as a positive
sequence of case labels followed by a positive sequence of statements.  The
"body" of an explicit switch is a brace-enclosed sequence of case
statements (and case statements can only appear in such a context).  Each
case statement is a substatement, defines a block scope, and all but the
last one must be explicitly terminated.  For the finer details of the spec
I encourage you to read the proposal, it is quite short.

--

---
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_943_53996.1391797159243
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, February 7, 2014 6:10:08 PM UTC+1, Matthew Woeh=
lke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Implicit fallth=
rough is used intentionally as a feature in 3% of existing
<br>&gt; cases. &nbsp;That's an unbelievably large amount of code, so no, y=
ou can't emit
<br>&gt; a warning or an error or have a global option.
<br>
<br>If I am either not in that 3%, or using compiler features to annotate=
=20
<br>when fallthrough should be allowed, shouldn't I be allowed to tell the=
=20
<br>compiler to disallow implicit fallthrough on my code base? (At least=20
<br>clang thinks so...)<br></blockquote><div><br></div><div>In existing sta=
ndard C++ code implicit fallthrough in switches is used in 3% of case block=
s (not codebases) without a fallthrough statement/annotation to intentional=
ly express jumping to the following case, and has been for 40 years. &nbsp;=
Setting up your tools such that they would not compile this existing code j=
ust isn't going to work. &nbsp;You might want to integrate some of it into =
your build, and you don't want to go through and modify existing code. &nbs=
p;For this reason it is pretty safe to predict that the clang option will g=
o unused/ignored. &nbsp;Just like this GCC feature request from 2002:</div>=
<div><br></div><div>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D7652<br><=
/div><div><br></div><div>So no, a compiler flag that breaks existing code i=
s a non-solution. &nbsp;N3879 is superior as it is a pure addition, and doe=
sn't break existing code.</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">&gt; The implicit fallthrough semantic between two consecut=
ive case blocks
<br>&gt; can be expressed in an explicit switch using a goto case statement
<br>&gt; instead.
<br>
<br>You might want to add 'non-empty' here; when I first read it, I thought=
=20
<br>you meant you were going to disallow:
<br>
<br>&nbsp; &nbsp;case a:
<br>&nbsp; &nbsp;case b:
<br>&nbsp; &nbsp; &nbsp;...
<br>
<br>...but as you then use this in examples, I assume that is not the case.
<br></blockquote><div><br></div><div>Formally, as per N3879 (and C#) we def=
ine a case statement as a positive sequence of case labels followed by a po=
sitive sequence of statements. &nbsp;The "body" of an explicit switch is a =
brace-enclosed sequence of case statements (and case statements can only ap=
pear in such a context). &nbsp;Each case statement is a substatement, defin=
es a block scope, and all but the last one must be explicitly terminated. &=
nbsp;For the finer details of the spec I encourage you to read the proposal=
, it is quite short.</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_943_53996.1391797159243--

.

On 2014-02-07 13:19, Andrew Tomazos wrote:
> On Friday, February 7, 2014 6:10:08 PM UTC+1, Matthew Woehlke wrote:
>> If I am either not in that 3%, or using compiler features to annotate
>> when fallthrough should be allowed, shouldn't I be allowed to tell the
>> compiler to disallow implicit fallthrough on my code base? (At least
>> clang thinks so...)
>
> it is pretty safe to predict that the clang option will go
> unused/ignored.

In old/legacy code, perhaps. In modern code, no.

The only reason I am not using this is because I am not using clang :-).
If I *was* using clang, or if gcc had this feature, I *would* be using
it. (And I *am* using annotated fallthrough...)

There are also bug reports related to this feature, demonstrating that
it is in fact used...

--
Matthew

--

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

.

On Fri, Feb 7, 2014 at 10:19 AM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> On Friday, February 7, 2014 6:10:08 PM UTC+1, Matthew Woehlke wrote:
>>
>> > Implicit fallthrough is used intentionally as a feature in 3% of
>> > existing
>> > cases.  That's an unbelievably large amount of code, so no, you can't
>> > emit
>> > a warning or an error or have a global option.
>>
>> If I am either not in that 3%, or using compiler features to annotate
>> when fallthrough should be allowed, shouldn't I be allowed to tell the
>> compiler to disallow implicit fallthrough on my code base? (At least
>> clang thinks so...)
>
>
> In existing standard C++ code implicit fallthrough in switches is used in 3%
> of case blocks (not codebases) without a fallthrough statement/annotation to
> intentionally express jumping to the following case, and has been for 40
> years.  Setting up your tools such that they would not compile this existing
> code just isn't going to work.  You might want to integrate some of it into
> your build, and you don't want to go through and modify existing code.  For
> this reason it is pretty safe to predict that the clang option will go
> unused/ignored.

The clang option is being used in a very large codebase I work with.
It's turned off explicitly for some libraries that haven't been
cleaned up yet, but it's on by default everywhere else. Don't be so
pessimistic.

--

---
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_791_27168861.1391804257450
Content-Type: text/plain; charset=UTF-8

Good work Tomazos! I hope this finds its way into the standard.

Den fredagen den 7:e februari 2014 kl. 21:06:43 UTC+1 skrev Jeffrey Yasskin:
>
> On Fri, Feb 7, 2014 at 10:19 AM, Andrew Tomazos <andrew...@gmail.com<javascript:>>
> wrote:
> > On Friday, February 7, 2014 6:10:08 PM UTC+1, Matthew Woehlke wrote:
> >>
> >> > Implicit fallthrough is used intentionally as a feature in 3% of
> >> > existing
> >> > cases.  That's an unbelievably large amount of code, so no, you can't
> >> > emit
> >> > a warning or an error or have a global option.
> >>
> >> If I am either not in that 3%, or using compiler features to annotate
> >> when fallthrough should be allowed, shouldn't I be allowed to tell the
> >> compiler to disallow implicit fallthrough on my code base? (At least
> >> clang thinks so...)
> >
> >
> > In existing standard C++ code implicit fallthrough in switches is used
> in 3%
> > of case blocks (not codebases) without a fallthrough
> statement/annotation to
> > intentionally express jumping to the following case, and has been for 40
> > years.  Setting up your tools such that they would not compile this
> existing
> > code just isn't going to work.  You might want to integrate some of it
> into
> > your build, and you don't want to go through and modify existing code.
>  For
> > this reason it is pretty safe to predict that the clang option will go
> > unused/ignored.
>
> The clang option is being used in a very large codebase I work with.
> It's turned off explicitly for some libraries that haven't been
> cleaned up yet, but it's on by default everywhere else. Don't be so
> pessimistic.
>

--

---
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_791_27168861.1391804257450
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Good work Tomazos! I hope this finds its way into the stan=
dard.<br><br>Den fredagen den 7:e februari 2014 kl. 21:06:43 UTC+1 skrev Je=
ffrey Yasskin:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Fri, Feb 7, 2=
014 at 10:19 AM, Andrew Tomazos &lt;<a href=3D"javascript:" target=3D"_blan=
k" gdf-obfuscated-mailto=3D"tyr0yeZS58wJ" onmousedown=3D"this.href=3D'javas=
cript:';return true;" onclick=3D"this.href=3D'javascript:';return true;">an=
drew...@gmail.com</a>&gt; wrote:
<br>&gt; On Friday, February 7, 2014 6:10:08 PM UTC+1, Matthew Woehlke wrot=
e:
<br>&gt;&gt;
<br>&gt;&gt; &gt; Implicit fallthrough is used intentionally as a feature i=
n 3% of
<br>&gt;&gt; &gt; existing
<br>&gt;&gt; &gt; cases. &nbsp;That's an unbelievably large amount of code,=
 so no, you can't
<br>&gt;&gt; &gt; emit
<br>&gt;&gt; &gt; a warning or an error or have a global option.
<br>&gt;&gt;
<br>&gt;&gt; If I am either not in that 3%, or using compiler features to a=
nnotate
<br>&gt;&gt; when fallthrough should be allowed, shouldn't I be allowed to =
tell the
<br>&gt;&gt; compiler to disallow implicit fallthrough on my code base? (At=
 least
<br>&gt;&gt; clang thinks so...)
<br>&gt;
<br>&gt;
<br>&gt; In existing standard C++ code implicit fallthrough in switches is =
used in 3%
<br>&gt; of case blocks (not codebases) without a fallthrough statement/ann=
otation to
<br>&gt; intentionally express jumping to the following case, and has been =
for 40
<br>&gt; years. &nbsp;Setting up your tools such that they would not compil=
e this existing
<br>&gt; code just isn't going to work. &nbsp;You might want to integrate s=
ome of it into
<br>&gt; your build, and you don't want to go through and modify existing c=
ode. &nbsp;For
<br>&gt; this reason it is pretty safe to predict that the clang option wil=
l go
<br>&gt; unused/ignored.
<br>
<br>The clang option is being used in a very large codebase I work with.
<br>It's turned off explicitly for some libraries that haven't been
<br>cleaned up yet, but it's on by default everywhere else. Don't be so
<br>pessimistic.
<br></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_791_27168861.1391804257450--

.

------=_Part_1285_12455279.1391817492363
Content-Type: text/plain; charset=UTF-8

On Friday, February 7, 2014 9:06:43 PM UTC+1, Jeffrey Yasskin wrote:
>
> > In existing standard C++ code implicit fallthrough in switches is used
> in 3%
> > of case blocks (not codebases) without a fallthrough
> statement/annotation to
> > intentionally express jumping to the following case, and has been for 40
> > years.  Setting up your tools such that they would not compile this
> existing
> > code just isn't going to work.  You might want to integrate some of it
> into
> > your build, and you don't want to go through and modify existing code.
>  For
> > this reason it is pretty safe to predict that the clang option will go
> > unused/ignored.
>
> The clang option is being used in a very large codebase I work with.
> It's turned off explicitly for some libraries that haven't been
> cleaned up yet, but it's on by default everywhere else. Don't be so
> pessimistic.
>

If you turn on -Wimplicit-fallthrough per-TU, then you get the problem of
including a header file from some library code that contains a switch in an
inline function definition (in a class specifier or otherwise):

libfoo.h:

   inline void f() { switch (x) { /* uses fallthrough */ } };

newbar.cpp

   #include "libfoo.h"

   ...

Now you have to modify libfoo if you want to compile newbar with
-Wimplicit-fallthrough.

Breaking existing code is simply a bad plan, even if it is with a
non-default compiler option.  That's why I'm pessimistic about
-Wimplicit-fallthrough adoption.

But anyway - N3879 is compatible with both -Wimplicit-fallthrough and
[[clang::fallthrough]].  You can have all three things together, and they
can share code in the implementation.

Also, if you like compiler options and "cleaning up" old code, you could
also add one that makes all switches explicit (without having to add the
explicit keyword) - but I have the same doubts about the adoption of such
an option as I do with -Wimplicit-fallthrough, or any compiler switch that
breaks existing code.

--

---
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_1285_12455279.1391817492363
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, February 7, 2014 9:06:43 PM UTC+1, Jeffrey Yass=
kin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; In existing sta=
ndard C++ code implicit fallthrough in switches is used in 3%
<br>&gt; of case blocks (not codebases) without a fallthrough statement/ann=
otation to
<br>&gt; intentionally express jumping to the following case, and has been =
for 40
<br>&gt; years. &nbsp;Setting up your tools such that they would not compil=
e this existing
<br>&gt; code just isn't going to work. &nbsp;You might want to integrate s=
ome of it into
<br>&gt; your build, and you don't want to go through and modify existing c=
ode. &nbsp;For
<br>&gt; this reason it is pretty safe to predict that the clang option wil=
l go
<br>&gt; unused/ignored.
<br>
<br>The clang option is being used in a very large codebase I work with.
<br>It's turned off explicitly for some libraries that haven't been
<br>cleaned up yet, but it's on by default everywhere else. Don't be so
<br>pessimistic.<br></blockquote><div><br></div><div>If you turn on -Wimpli=
cit-fallthrough per-TU, then you get the problem of including a header file=
 from some library code that contains a switch in an inline function defini=
tion (in a class specifier or otherwise):</div><div><br></div><div>libfoo.h=
:</div><div><br></div><div>&nbsp; &nbsp;inline void f() { switch (x) { /* u=
ses fallthrough */ } };</div><div><br></div><div>newbar.cpp</div><div><br><=
/div><div>&nbsp; &nbsp;#include "libfoo.h"</div><div><br></div><div>&nbsp; =
&nbsp;...</div><div><br></div><div>Now you have to modify libfoo if you wan=
t to compile newbar with -Wimplicit-fallthrough.</div><div><br></div><div>B=
reaking existing code is simply a bad plan, even if it is with a non-defaul=
t compiler option. &nbsp;That's why I'm pessimistic about -Wimplicit-fallth=
rough adoption.</div><div><br></div><div>But anyway - N3879 is compatible w=
ith both -Wimplicit-fallthrough and [[clang::fallthrough]]. &nbsp;You can h=
ave all three things together, and they can share code in the implementatio=
n.</div><div><br></div><div>Also, if you like compiler options and "cleanin=
g up" old code, you could also add one that makes all switches explicit (wi=
thout having to add the explicit keyword) - but I have the same doubts abou=
t the adoption of such an option as I do with -Wimplicit-fallthrough, or an=
y compiler switch that breaks existing code.</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_1285_12455279.1391817492363--

.

On Fri, Feb 7, 2014 at 3:58 PM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> On Friday, February 7, 2014 9:06:43 PM UTC+1, Jeffrey Yasskin wrote:
>>
>> > In existing standard C++ code implicit fallthrough in switches is used
>> > in 3%
>> > of case blocks (not codebases) without a fallthrough
>> > statement/annotation to
>> > intentionally express jumping to the following case, and has been for 40
>> > years.  Setting up your tools such that they would not compile this
>> > existing
>> > code just isn't going to work.  You might want to integrate some of it
>> > into
>> > your build, and you don't want to go through and modify existing code.
>> > For
>> > this reason it is pretty safe to predict that the clang option will go
>> > unused/ignored.
>>
>> The clang option is being used in a very large codebase I work with.
>> It's turned off explicitly for some libraries that haven't been
>> cleaned up yet, but it's on by default everywhere else. Don't be so
>> pessimistic.
>
>
> If you turn on -Wimplicit-fallthrough per-TU, then you get the problem of
> including a header file from some library code that contains a switch in an
> inline function definition (in a class specifier or otherwise):
>
> libfoo.h:
>
>    inline void f() { switch (x) { /* uses fallthrough */ } };
>
> newbar.cpp
>
>    #include "libfoo.h"
>
>    ...
>
> Now you have to modify libfoo if you want to compile newbar with
> -Wimplicit-fallthrough.
>
> Breaking existing code is simply a bad plan, even if it is with a
> non-default compiler option.  That's why I'm pessimistic about
> -Wimplicit-fallthrough adoption.

I'm aware of the theoretical problems. In practice, they didn't
prevent us from turning on the 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_1250_18626622.1391818504408
Content-Type: text/plain; charset=UTF-8

On Saturday, February 8, 2014 1:00:18 AM UTC+1, Jeffrey Yasskin wrote:
>
> I'm aware of the theoretical problems. In practice, they didn't
> prevent us from turning on the switch.
>

I'll compromise by agreeing that anecdotal evidence and theoretical
problems provide equivalently weak foundations for an argument.

--

---
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_1250_18626622.1391818504408
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, February 8, 2014 1:00:18 AM UTC+1, Jeffrey Ya=
sskin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I'm aware of the t=
heoretical problems. In practice, they didn't
<br>prevent us from turning on the switch.
<br></blockquote><div><br></div><div>I'll compromise by agreeing that anecd=
otal evidence and theoretical problems provide equivalently weak foundation=
s for an argument.</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_1250_18626622.1391818504408--

.

On 2014-02-07 18:58, Andrew Tomazos wrote:
> If you turn on -Wimplicit-fallthrough per-TU, then you get the problem of
> including a header file from some library code that contains a switch in an
> inline function definition (in a class specifier or otherwise):

There is no issue here. Either said header belongs to your library, and
thus -Wimplicit-fallthrough is correct to warn, or it does not, and you
do not get a warning because your correctly set up build system uses
-isystem to mark it as a system header, for which warnings are suppressed.

(Per-TU? If you're really not managing it at a project level, which 99%
of the time you would be, then you can darned well manage it with
pragmas and have even fined grained control than TU. For that matter if
you really need to work around weird issues like this, you can again use
pragmas.)

-Wimplicit-fallthrough useful. Please stop trying to convince us otherwise.

The only time you're really going to get in trouble here is if implicit
fallthrough is used in an external macro that you need to use. (Which is
unlikely, but alas is why combining -Wzero-as-null-pointer-constant and
Qt[4] fails miserably, with Q_OBJECT being the worst offender...)

> Also, if you like compiler options and "cleaning up" old code, you could
> also add one that makes all switches explicit (without having to add the
> explicit keyword)

While I *might* use such an option if it existed, I don't see it ever
existing, as - unlike -Wimplicit-fallthrough, which merely diagnoses
legal but suspicious code - it would change the meaning of 'switch'. (At
least it would have to be a -f option and not a -W option.)

--
Matthew

--

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

.

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

On Fri, Feb 7, 2014 at 4:23 PM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:

> On 2014-02-07 18:58, Andrew Tomazos wrote:
>
>> If you turn on -Wimplicit-fallthrough per-TU, then you get the problem of
>> including a header file from some library code that contains a switch in
>> an
>> inline function definition (in a class specifier or otherwise):
>>
>
> There is no issue here. Either said header belongs to your library, and
> thus -Wimplicit-fallthrough is correct to warn, or it does not, and you do
> not get a warning because your correctly set up build system uses -isystem
> to mark it as a system header, for which warnings are suppressed.
>
> (Per-TU? If you're really not managing it at a project level, which 99% of
> the time you would be, then you can darned well manage it with pragmas and
> have even fined grained control than TU. For that matter if you really need
> to work around weird issues like this, you can again use pragmas.)
>
> -Wimplicit-fallthrough useful. Please stop trying to convince us otherwise.
>
> The only time you're really going to get in trouble here is if implicit
> fallthrough is used in an external macro that you need to use. (Which is
> unlikely, but alas is why combining -Wzero-as-null-pointer-constant and
> Qt[4] fails miserably, with Q_OBJECT being the worst offender...)


If you see this being a problem in practice, please file a bug -- it'd be
easy for us to teach -Wimplicit-fallthrough to suppress diagnostics in the
expansion of a macro that was defined in a system header, and likewise for
any other warning. (FWIW, this is a significant advantage of compiler
diagnostics over language features for detecting bugs -- we can much more
easily tune the diagnostics to have the right balance between false
positives and false negatives).

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Feb 7, 2014 at 4:23 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_triad@users=
..sourceforge.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 2014-02-07 18:58, Andre=
w Tomazos wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
If you turn on -Wimplicit-fallthrough per-TU, then you get the problem of<b=
r>
including a header file from some library code that contains a switch in an=
<br>
inline function definition (in a class specifier or otherwise):<br>
</blockquote>
<br></div>
There is no issue here. Either said header belongs to your library, and thu=
s -Wimplicit-fallthrough is correct to warn, or it does not, and you do not=
 get a warning because your correctly set up build system uses -isystem to =
mark it as a system header, for which warnings are suppressed.<br>

<br>
(Per-TU? If you&#39;re really not managing it at a project level, which 99%=
 of the time you would be, then you can darned well manage it with pragmas =
and have even fined grained control than TU. For that matter if you really =
need to work around weird issues like this, you can again use pragmas.)<br>

<br>
-Wimplicit-fallthrough useful. Please stop trying to convince us otherwise.=
<br>
<br>
The only time you&#39;re really going to get in trouble here is if implicit=
 fallthrough is used in an external macro that you need to use. (Which is u=
nlikely, but alas is why combining -Wzero-as-null-pointer-<u></u>constant a=
nd Qt[4] fails miserably, with Q_OBJECT being the worst offender...)</block=
quote>
<div><br></div><div>If you see this being a problem in practice, please fil=
e a bug -- it&#39;d be easy for us to teach -Wimplicit-fallthrough to suppr=
ess diagnostics in the expansion of a macro that was defined in a system he=
ader, and likewise for any other warning. (FWIW, this is a significant adva=
ntage of compiler diagnostics over language features for detecting bugs -- =
we can much more easily tune the diagnostics to have the right balance betw=
een false positives and false negatives).</div>
</div></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 />

--047d7ba96cf4c568f704f1da69e9--

.

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

On Saturday, February 8, 2014 1:44:46 AM UTC+1, Richard Smith wrote:
>
> we can much more easily tune the diagnostics to have the right balance=20
> between false positives and false negatives
>

In the context of implicit fallthrough, it isn't clear which direction=20
positive and negative is, so let us instead use the terms:

    true reachability
    false reachability
    true unreachability
    false unreachability

with their obvious meanings.

In N3879 I took a simple approach and just defined this reachability=20
analysis as follows:

The implementation shall analyze each but the last case-statement of every=
=20
> explicit switch statement
> during translation with some predicate P. P must have the following=20
> properties: If it is possible for control
> to =EF=AC=82ow o=EF=AC=80 the end of a case-statement C, P(C) must be tru=
e. If the =EF=AC=81nal=20
> statement within a case-statement
> C is a jump-statement or a throw expression statement, P(C) must be false=
..=20
> For each case-statement C
> with neither property, P(C) is unspeci=EF=AC=81ed. If P(C) is true for an=
 analyzed=20
> case-statement, the program is
> ill-formed. [ Note: As a quality of implementation issue, P should be=20
> false in as many of the unspeci=EF=AC=81ed
> cases as reasonably possible. =E2=80=94 end note ]


I'd like to ask if you know whether or not the -Wimplicit-fallthrough code=
=20
in clang currently obeys this P requirement?  That is, will it *always*=20
warn if it is possible to fall off the end of a case?

If there is interest, I also think we can do better specification-wise than=
=20
this.  Consider in comparison section 14.21 Unreachable Statements in the=
=20
Java Language Specification:

    http://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.21

I think we could create a similar reachability definition for C++, perhaps=
=20
in Clause 1 of the standard.  Then we could reference this reachability=20
definition in value-returning functions and in explicit switch cases.

In the context of reachability, I think the right balance is at least never=
=20
to have false unreachability.  This is because the cost of false=20
unreachability (logic bug / undefined behaviour) is clearly much higher=20
than false reachability (compile-time diagnostic - add "throw=20
assert_unreachable" or similar suppression).

For the remaining split between true reachability and false reachability=20
cases, for portability of standard C++ code between implementations - I=20
think it would be better to have all implementations give the same result=
=20
(like in Java).  (This is not currently the case with either=20
-Wimplicit-fallthrough or N3879.)  This is clearly something for the UB=20
group.  Thoughts welcome.

--=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_1232_27406873.1391823147615
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, February 8, 2014 1:44:46 AM UTC+1, Richard Sm=
ith 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><div class=3D"gmail_quote"><div>we can much more easily tune the diagnost=
ics to have the right balance between false positives and false negatives</=
div></div></div></div></blockquote><div><br></div><div>In the context of im=
plicit fallthrough, it isn't clear which direction positive and negative is=
, so let us instead use the terms:</div><div><br></div><div>&nbsp; &nbsp; t=
rue reachability</div><div>&nbsp; &nbsp; false reachability</div><div>&nbsp=
; &nbsp; true unreachability</div><div>&nbsp; &nbsp; false unreachability</=
div><div><br></div><div>with their obvious meanings.</div><div><br></div><d=
iv>In N3879 I took a simple approach and just defined this reachability ana=
lysis as follows:</div><div><br></div><div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-c=
olor: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">The=
 implementation shall analyze each but the last case-statement of every exp=
licit switch statement<br>during translation with some predicate P. P must =
have the following properties: If it is possible for control<br>to =EF=AC=
=82ow o=EF=AC=80 the end of a case-statement C, P(C) must be true. If the =
=EF=AC=81nal statement within a case-statement<br>C is a jump-statement or =
a throw expression statement, P(C) must be false. For each case-statement C=
<br>with neither property, P(C) is unspeci=EF=AC=81ed. If P(C) is true for =
an analyzed case-statement, the program is<br>ill-formed. [ Note: As a qual=
ity of implementation issue, P should be false in as many of the unspeci=EF=
=AC=81ed<br>cases as reasonably possible. =E2=80=94 end note ]</blockquote>=
</div><div><br></div><div>I'd like to ask if you know whether or not the -W=
implicit-fallthrough code in clang currently obeys this P requirement? &nbs=
p;That is, will it *always* warn if it is possible to fall off the end of a=
 case?<br></div><div><br></div><div>If there is interest, I also think we c=
an do better specification-wise than this. &nbsp;Consider in comparison sec=
tion 14.21 Unreachable Statements in the Java Language Specification:</div>=
<div><br></div><div>&nbsp; &nbsp; http://docs.oracle.com/javase/specs/jls/s=
e7/html/jls-14.html#jls-14.21<br></div><div><br></div><div>I think we could=
 create a similar reachability definition for C++, perhaps in Clause 1 of t=
he standard. &nbsp;Then we could reference this reachability definition in =
value-returning functions and in explicit switch cases.</div><div><br></div=
><div>In the context of reachability, I think the right balance is at least=
 never to have false unreachability. &nbsp;This is because the cost of fals=
e unreachability (logic bug / undefined behaviour) is clearly much higher t=
han false reachability (compile-time diagnostic - add "throw assert_unreach=
able" or similar suppression).</div><div><br></div><div>For the remaining s=
plit between true reachability and false reachability cases, for portabilit=
y of standard C++ code between implementations - I think it would be better=
 to have all implementations give the same result (like in Java). &nbsp;(Th=
is is not currently the case with either -Wimplicit-fallthrough or N3879.) =
&nbsp;This is clearly something for the UB group. &nbsp;Thoughts welcome.</=
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_1232_27406873.1391823147615--

.

------=_Part_1870_25806551.1391889267704
Content-Type: text/plain; charset=UTF-8

On Saturday, February 8, 2014 1:23:54 AM UTC+1, Matthew Woehlke wrote:
>
> > Also, if you like compiler options and "cleaning up" old code, you could
> > also add one that makes all switches explicit (without having to add the
> > explicit keyword)
>
> While I *might* use such an option if it existed, I don't see it ever
> existing, as - unlike -Wimplicit-fallthrough, which merely diagnoses
> legal but suspicious code - it would change the meaning of 'switch'. (At
> least it would have to be a -f option and not a -W option.)
>

Well, actually, the option already exists, it is written
`-Dswitch="explicit switch"`

To turn it on mid TU you can use:

    #define switch explicit switch

To turn it off you can use

    #undef 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_1870_25806551.1391889267704
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, February 8, 2014 1:23:54 AM UTC+1, Matthew Wo=
ehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Also, if you =
like compiler options and "cleaning up" old code, you could
<br>&gt; also add one that makes all switches explicit (without having to a=
dd the
<br>&gt; explicit keyword)
<br>
<br>While I *might* use such an option if it existed, I don't see it ever=
=20
<br>existing, as - unlike -Wimplicit-fallthrough, which merely diagnoses=20
<br>legal but suspicious code - it would change the meaning of 'switch'. (A=
t=20
<br>least it would have to be a -f option and not a -W option.)
<br></blockquote><div>&nbsp;</div><div>Well, actually, the option already e=
xists, it is written `-Dswitch=3D"explicit switch"`</div><div><br></div><di=
v>To turn it on mid TU you can use:</div><div><br></div><div>&nbsp; &nbsp; =
#define switch explicit switch</div><div><br></div><div>To turn it off you =
can use</div><div><br></div><div>&nbsp; &nbsp; #undef switch</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_1870_25806551.1391889267704--

.

------=_Part_1847_5158503.1391889569464
Content-Type: text/plain; charset=UTF-8



On Saturday, February 8, 2014 8:54:27 PM UTC+1, Andrew Tomazos wrote:
>
> On Saturday, February 8, 2014 1:23:54 AM UTC+1, Matthew Woehlke wrote:
>>
>> > Also, if you like compiler options and "cleaning up" old code, you
>> could
>> > also add one that makes all switches explicit (without having to add
>> the
>> > explicit keyword)
>>
>> While I *might* use such an option if it existed, I don't see it ever
>> existing, as - unlike -Wimplicit-fallthrough, which merely diagnoses
>> legal but suspicious code - it would change the meaning of 'switch'. (At
>> least it would have to be a -f option and not a -W option.)
>>
>
> Well, actually, the option already exists, it is written
> `-Dswitch="explicit switch"`
>
> To turn it on mid TU you can use:
>
>     #define switch explicit switch
>
> To turn it off you can use
>
>     #undef switch
>

....and while technically it does change the meaning of switch.  In practice
jump-past-initialization is diagnosed, so it only gives meaning to
otherwise effectively ill-formed code - so in practice it's safe to turn on.

--

---
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_1847_5158503.1391889569464
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Saturday, February 8, 2014 8:54:27 PM UTC+1, An=
drew Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr">On Saturday, February 8, 2014 1:23:54 AM UTC+1, Matthew Woehlke wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">&gt; Also, if you like compiler op=
tions and "cleaning up" old code, you could
<br>&gt; also add one that makes all switches explicit (without having to a=
dd the
<br>&gt; explicit keyword)
<br>
<br>While I *might* use such an option if it existed, I don't see it ever=
=20
<br>existing, as - unlike -Wimplicit-fallthrough, which merely diagnoses=20
<br>legal but suspicious code - it would change the meaning of 'switch'. (A=
t=20
<br>least it would have to be a -f option and not a -W option.)
<br></blockquote><div>&nbsp;</div><div>Well, actually, the option already e=
xists, it is written `-Dswitch=3D"explicit switch"`</div><div><br></div><di=
v>To turn it on mid TU you can use:</div><div><br></div><div>&nbsp; &nbsp; =
#define switch explicit switch</div><div><br></div><div>To turn it off you =
can use</div><div><br></div><div>&nbsp; &nbsp; #undef switch</div></div></b=
lockquote><div><br></div><div>...and while technically it does change the m=
eaning of switch. &nbsp;In practice jump-past-initialization is diagnosed, =
so it only gives meaning to otherwise effectively ill-formed code - so in p=
ractice it's safe to turn on.<br></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_1847_5158503.1391889569464--

.

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

On Fri, Feb 7, 2014 at 5:32 PM, Andrew Tomazos <andrewtomazos@gmail.com>wro=
te:

> On Saturday, February 8, 2014 1:44:46 AM UTC+1, Richard Smith wrote:
>>
>> we can much more easily tune the diagnostics to have the right balance
>> between false positives and false negatives
>>
>
> In the context of implicit fallthrough, it isn't clear which direction
> positive and negative is,
>

A "false positive" is a warning where there's no bug.
A "false negative" is a bug where there's no warning.

so let us instead use the terms:
>
>     true reachability
>     false reachability
>     true unreachability
>     false unreachability
>
> with their obvious meanings.
>
> In N3879 I took a simple approach and just defined this reachability
> analysis as follows:
>
> The implementation shall analyze each but the last case-statement of ever=
y
>> explicit switch statement
>> during translation with some predicate P. P must have the following
>> properties: If it is possible for control
>> to =EF=AC=82ow o=EF=AC=80 the end of a case-statement C, P(C) must be tr=
ue. If the =EF=AC=81nal
>> statement within a case-statement
>> C is a jump-statement or a throw expression statement, P(C) must be
>> false. For each case-statement C
>> with neither property, P(C) is unspeci=EF=AC=81ed. If P(C) is true for a=
n
>> analyzed case-statement, the program is
>> ill-formed. [ Note: As a quality of implementation issue, P should be
>> false in as many of the unspeci=EF=AC=81ed
>> cases as reasonably possible. =E2=80=94 end note ]
>
>
> I'd like to ask if you know whether or not the -Wimplicit-fallthrough cod=
e
> in clang currently obeys this P requirement?  That is, will it *always*
> warn if it is possible to fall off the end of a case?
>

No, it will not. That has false positives that you would classify as "true
reachability". For instance:

enum E { a, b, c };
int f(E x, E y) {
  switch (x) {
  case a:
    switch (y) {
    case a: return 1;
    case b: return 4;
    case c: return 9;
    }

  case b:
  case c:
    return 0;
  }
}

Here, we don't warn that the case where x =3D=3D a and y =3D=3D 3 would fal=
l
through, because we assume that the user intended 'y' to only have values
of E that are named by the enumerators. (Likewise, we don't warn that we
can reach the end of 'f' without returning a value, even though we will do
so if x =3D=3D 3.)

If there is interest, I also think we can do better specification-wise than
> this.  Consider in comparison section 14.21 Unreachable Statements in the
> Java Language Specification:
>
>     http://docs.oracle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.2=
1
>
> I think we could create a similar reachability definition for C++, perhap=
s
> in Clause 1 of the standard.  Then we could reference this reachability
> definition in value-returning functions and in explicit switch cases.
>
> In the context of reachability, I think the right balance is at least
> never to have false unreachability.  This is because the cost of false
> unreachability (logic bug / undefined behaviour) is clearly much higher
> than false reachability (compile-time diagnostic - add "throw
> assert_unreachable" or similar suppression).
>
> For the remaining split between true reachability and false reachability
> cases, for portability of standard C++ code between implementations - I
> think it would be better to have all implementations give the same result
> (like in Java).  (This is not currently the case with either
> -Wimplicit-fallthrough or N3879.)  This is clearly something for the UB
> group.  Thoughts welcome.
>
>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Feb 7, 2014 at 5:32 PM, Andrew Tomazos <span dir=3D"ltr">&lt;<a href=3D=
"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@gmail.com<=
/a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"">On Saturday=
, February 8, 2014 1:44:46 AM UTC+1, Richard Smith wrote:<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><div class=3D"gmail_quote"><div>we can much more easi=
ly tune the diagnostics to have the right balance between false positives a=
nd false negatives</div></div></div></div></blockquote><div><br></div></div=
>
<div>In the context of implicit fallthrough, it isn&#39;t clear which direc=
tion positive and negative is,</div></div></blockquote><div><br></div><div>=
A &quot;false positive&quot; is a warning where there&#39;s no bug.</div>
<div>A &quot;false negative&quot; is a bug where there&#39;s no warning.</d=
iv><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>so l=
et us instead use the terms:</div>
<div><br></div><div>=C2=A0 =C2=A0 true reachability</div><div>=C2=A0 =C2=A0=
 false reachability</div><div>=C2=A0 =C2=A0 true unreachability</div><div>=
=C2=A0 =C2=A0 false unreachability</div><div><br></div><div>with their obvi=
ous meanings.</div><div><br></div><div>
In N3879 I took a simple approach and just defined this reachability analys=
is as follows:</div><div><br></div><div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex">
The implementation shall analyze each but the last case-statement of every =
explicit switch statement<br>during translation with some predicate P. P mu=
st have the following properties: If it is possible for control<br>to =EF=
=AC=82ow o=EF=AC=80 the end of a case-statement C, P(C) must be true. If th=
e =EF=AC=81nal statement within a case-statement<br>
C is a jump-statement or a throw expression statement, P(C) must be false. =
For each case-statement C<br>with neither property, P(C) is unspeci=EF=AC=
=81ed. If P(C) is true for an analyzed case-statement, the program is<br>il=
l-formed. [ Note: As a quality of implementation issue, P should be false i=
n as many of the unspeci=EF=AC=81ed<br>
cases as reasonably possible. =E2=80=94 end note ]</blockquote></div><div><=
br></div><div>I&#39;d like to ask if you know whether or not the -Wimplicit=
-fallthrough code in clang currently obeys this P requirement? =C2=A0That i=
s, will it *always* warn if it is possible to fall off the end of a case?</=
div>
</div></blockquote><div><br></div><div>No, it will not. That has false posi=
tives that you would classify as &quot;true reachability&quot;. For instanc=
e:</div><div><br></div><div>enum E { a, b, c };</div><div>int f(E x, E y) {=
</div>
<div>=C2=A0 switch (x) {</div><div>=C2=A0 case a:</div><div>=C2=A0 =C2=A0 s=
witch (y) {</div><div>=C2=A0 =C2=A0 case a: return 1;</div><div>=C2=A0 =C2=
=A0 case b: return 4;</div><div>=C2=A0 =C2=A0 case c: return 9;</div><div>=
=C2=A0 =C2=A0 }</div><div><br></div><div>=C2=A0 case b:</div><div>
=C2=A0 case c:</div><div>=C2=A0 =C2=A0 return 0;</div><div>=C2=A0 }</div><d=
iv>}</div><div><br></div><div>Here, we don&#39;t warn that the case where x=
 =3D=3D a and y =3D=3D 3 would fall through, because we assume that the use=
r intended &#39;y&#39; to only have values of E that are named by the enume=
rators. (Likewise, we don&#39;t warn that we can reach the end of &#39;f&#3=
9; without returning a value, even though we will do so if x =3D=3D 3.)</di=
v>
<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>If ther=
e is interest, I also think we can do better specification-wise than this. =
=C2=A0Consider in comparison section 14.21 Unreachable Statements in the Ja=
va Language Specification:</div>
<div><br></div><div>=C2=A0 =C2=A0 <a href=3D"http://docs.oracle.com/javase/=
specs/jls/se7/html/jls-14.html#jls-14.21" target=3D"_blank">http://docs.ora=
cle.com/javase/specs/jls/se7/html/jls-14.html#jls-14.21</a><br></div><div><=
br></div><div>
I think we could create a similar reachability definition for C++, perhaps =
in Clause 1 of the standard. =C2=A0Then we could reference this reachabilit=
y definition in value-returning functions and in explicit switch cases.</di=
v>
<div><br></div><div>In the context of reachability, I think the right balan=
ce is at least never to have false unreachability. =C2=A0This is because th=
e cost of false unreachability (logic bug / undefined behaviour) is clearly=
 much higher than false reachability (compile-time diagnostic - add &quot;t=
hrow assert_unreachable&quot; or similar suppression).</div>
<div><br></div><div>For the remaining split between true reachability and f=
alse reachability cases, for portability of standard C++ code between imple=
mentations - I think it would be better to have all implementations give th=
e same result (like in Java). =C2=A0(This is not currently the case with ei=
ther -Wimplicit-fallthrough or N3879.) =C2=A0This is clearly something for =
the UB group. =C2=A0Thoughts welcome.</div>
<div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
=C2=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 />

--bcaec50160c10d1b1104f2cb926d--

.

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

On Thu, Feb 20, 2014 at 1:27 AM, Richard Smith <richard@metafoo.co.uk>wrote=
:

> The implementation shall analyze each but the last case-statement of ever=
y
>>> explicit switch statement
>>> during translation with some predicate P. P must have the following
>>> properties: If it is possible for control
>>> to =EF=AC=82ow o=EF=AC=80 the end of a case-statement C, P(C) must be t=
rue. If the =EF=AC=81nal
>>> statement within a case-statement
>>> C is a jump-statement or a throw expression statement, P(C) must be
>>> false. For each case-statement C
>>> with neither property, P(C) is unspeci=EF=AC=81ed. If P(C) is true for =
an
>>> analyzed case-statement, the program is
>>> ill-formed. [ Note: As a quality of implementation issue, P should be
>>> false in as many of the unspeci=EF=AC=81ed
>>> cases as reasonably possible. =E2=80=94 end note ]
>>
>>
>> I'd like to ask if you know whether or not the -Wimplicit-fallthrough
>> code in clang currently obeys this P requirement?  That is, will it
>> *always* warn if it is possible to fall off the end of a case?
>>
>
> No, it will not. That has false positives that you would classify as "tru=
e
> reachability". For instance:
>
> enum E { a, b, c };
> int f(E x, E y) {
>   switch (x) {
>   case a:
>     switch (y) {
>     case a: return 1;
>     case b: return 4;
>     case c: return 9;
>     }
>
>   case b:
>   case c:
>     return 0;
>   }
> }
>
> Here, we don't warn that the case where x =3D=3D a and y =3D=3D 3 would f=
all
> through, because we assume that the user intended 'y' to only have values
> of E that are named by the enumerators. (Likewise, we don't warn that we
> can reach the end of 'f' without returning a value, even though we will d=
o
> so if x =3D=3D 3.)
>

This is a tricky one.  Let's take a look at what C# does:

    public class Test
    {
        enum E { a, b, c };

        int f(E x, E y)
        {
            switch (x)
            {
            case E.a:
                switch (y)
                {
                    case E.a: return 1;
                    case E.b: return 4;
                    case E.c: return 9;
                };

                // ERROR: control cannot fall through from one case label
to another

            case E.b:
            case E.c:
                return 0;
            }

            // ERROR: not all code paths return a value
        }
    }

I think we should follow C# on this one.  x =3D=3D E(3) is a perfectly vali=
d
and well-defined value of type E in both C++ and C# (and is used in
practice in the case of enum bitfields) - therefore, both points are
reachable.  So both -Wimplicit-fallthrough and -Wreturn-type should fire,
and an equivalent explicit switch statement should be ill-formed.

The programmer can explicitly introduce a jump, throw or other
non-returning statement at those two points avoid the error.

I think the tradeoff is justified because the cost of a "false positive" (a
little extra typing) is negligible compared to the cost of a "false
negative" (runtime logic error / undefined behaviour), even though I agree
it is significantly more likely to be a false positive than a false
negative.

Do you know if this case (enumeration type value !=3D any enumerator) is th=
e
only example of "false unreachability" in the current clang
-Wimplicit-fallthrough implementation?  Or are there others?

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Feb 20, 2014 at 1:27 AM, Richard Smith <span dir=3D"ltr">&lt;<a href=3D=
"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>&=
gt;</span> 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-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">
<div class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The implementation shall analyze each but the last case-statement of every =
explicit switch statement<br>during translation with some predicate P. P mu=
st have the following properties: If it is possible for control<br>to =EF=
=AC=82ow o=EF=AC=80 the end of a case-statement C, P(C) must be true. If th=
e =EF=AC=81nal statement within a case-statement<br>

C is a jump-statement or a throw expression statement, P(C) must be false. =
For each case-statement C<br>with neither property, P(C) is unspeci=EF=AC=
=81ed. If P(C) is true for an analyzed case-statement, the program is<br>il=
l-formed. [ Note: As a quality of implementation issue, P should be false i=
n as many of the unspeci=EF=AC=81ed<br>

cases as reasonably possible. =E2=80=94 end note ]</blockquote></div><div><=
br></div><div>I&#39;d like to ask if you know whether or not the -Wimplicit=
-fallthrough code in clang currently obeys this P requirement? =C2=A0That i=
s, will it *always* warn if it is possible to fall off the end of a case?</=
div>

</div></blockquote><div><br></div></div><div>No, it will not. That has fals=
e positives that you would classify as &quot;true reachability&quot;. For i=
nstance:</div><div><br></div><div>enum E { a, b, c };</div><div>int f(E x, =
E y) {</div>

<div>=C2=A0 switch (x) {</div><div>=C2=A0 case a:</div><div>=C2=A0 =C2=A0 s=
witch (y) {</div><div>=C2=A0 =C2=A0 case a: return 1;</div><div>=C2=A0 =C2=
=A0 case b: return 4;</div><div>=C2=A0 =C2=A0 case c: return 9;</div><div>=
=C2=A0 =C2=A0 }</div><div><br></div><div>=C2=A0 case b:</div><div>

=C2=A0 case c:</div><div>=C2=A0 =C2=A0 return 0;</div><div>=C2=A0 }</div><d=
iv>}</div><div><br></div><div>Here, we don&#39;t warn that the case where x=
 =3D=3D a and y =3D=3D 3 would fall through, because we assume that the use=
r intended &#39;y&#39; to only have values of E that are named by the enume=
rators. (Likewise, we don&#39;t warn that we can reach the end of &#39;f&#3=
9; without returning a value, even though we will do so if x =3D=3D 3.)</di=
v>
</div></div></div></blockquote><div><br></div><div>This is a tricky one. =
=C2=A0Let&#39;s take a look at what C# does:</div><div><br></div><div><div>=
<font face=3D"courier new, monospace">=C2=A0 =C2=A0 public class Test<br></=
font></div><div>
<font face=3D"courier new, monospace">=C2=A0 =C2=A0 {</font></div><div><fon=
t face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 enum E { a, b=
, c };</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0=
 =C2=A0 =C2=A0=C2=A0</font></div><div><font face=3D"courier new, monospace"=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 int f(E x, E y)</font></div>
<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 {</f=
ont></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 switch (x)</font></div><div><font face=3D"courier new,=
 monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {</font></div><div><f=
ont face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 case E.a:</font></div>
<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 switch (y)</font></div><div><font face=3D"courier =
new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {</=
font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case E.a: return 1;</font>=
</div>
<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case E.b: return 4;</font></div><div=
><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case E.c: return 9;</font></div><div><fo=
nt face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 };</font></div>
<div><font face=3D"courier new, monospace"><br></font></div><div><div><font=
 face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 // ERROR: control cannot fall through from one case label to =
another</font></div><div><font face=3D"courier new, monospace"><br>
</font></div></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case E.b:</font></div><div><font face=3D"couri=
er new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case E.c:</fon=
t></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return 0;</font></div>
<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 }</font></div><div><font face=3D"courier new, monospace"><br></f=
ont></div><div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 // ERROR: not all code paths return a value</font>=
</div>
</div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 }</font></div><div><div><span style=3D"font-family:&#39;courier new&#39=
;,monospace">=C2=A0 =C2=A0 }</span><br></div></div><div><br></div></div><di=
v><div>I think we should follow C# on this one. =C2=A0x =3D=3D E(3) is a pe=
rfectly valid and well-defined value of type E in both C++ and C# (and is u=
sed in practice in the case of enum bitfields) - therefore, both points are=
 reachable. =C2=A0So both -Wimplicit-fallthrough and -Wreturn-type should f=
ire, and an equivalent explicit switch statement should be ill-formed.</div=
>
<div><br></div></div><div>The programmer can explicitly introduce a jump, t=
hrow or other non-returning statement at those two points avoid the error.<=
/div><div><br></div><div>I think the tradeoff is justified because the cost=
 of a &quot;false positive&quot; (a little extra typing) is negligible comp=
ared to the cost of a &quot;false negative&quot; (runtime logic error / und=
efined behaviour), even though I agree it is significantly more likely to b=
e a false positive than a false negative.</div>
<div><br></div><div>Do you know if this case (enumeration type value !=3D a=
ny enumerator) is the only example of &quot;false unreachability&quot; in t=
he current clang -Wimplicit-fallthrough implementation? =C2=A0Or are there =
others?</div>
<div><br></div></div></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 />

--f46d041c5bd8ee6c8804f2dcc1c8--

.

On 2014-02-20 15:57, Andrew Tomazos wrote:
> On Thu, Feb 20, 2014 at 1:27 AM, Richard Smith <richard@metafoo.co.uk>wro=
te:
>
>> The implementation shall analyze each but the last case-statement of eve=
ry
>>>> explicit switch statement
>>>> during translation with some predicate P. P must have the following
>>>> properties: If it is possible for control
>>>> to =EF=AC=82ow o=EF=AC=80 the end of a case-statement C, P(C) must be =
true. If the =EF=AC=81nal
>>>> statement within a case-statement
>>>> C is a jump-statement or a throw expression statement, P(C) must be
>>>> false. For each case-statement C
>>>> with neither property, P(C) is unspeci=EF=AC=81ed. If P(C) is true for=
 an
>>>> analyzed case-statement, the program is
>>>> ill-formed. [ Note: As a quality of implementation issue, P should be
>>>> false in as many of the unspeci=EF=AC=81ed
>>>> cases as reasonably possible. =E2=80=94 end note ]
>>>
>>>
>>> I'd like to ask if you know whether or not the -Wimplicit-fallthrough
>>> code in clang currently obeys this P requirement?  That is, will it
>>> *always* warn if it is possible to fall off the end of a case?
>>>
>>
>> No, it will not. That has false positives that you would classify as "tr=
ue
>> reachability". For instance:
>>
>> enum E { a, b, c };
>> int f(E x, E y) {
>>    switch (x) {
>>    case a:
>>      switch (y) {
>>      case a: return 1;
>>      case b: return 4;
>>      case c: return 9;
>>      }
>>
>>    case b:
>>    case c:
>>      return 0;
>>    }
>> }
>>
>> Here, we don't warn that the case where x =3D=3D a and y =3D=3D 3 would =
fall
>> through, because we assume that the user intended 'y' to only have value=
s
>> of E that are named by the enumerators. (Likewise, we don't warn that we
>> can reach the end of 'f' without returning a value, even though we will =
do
>> so if x =3D=3D 3.)
>>
>
> This is a tricky one.  Let's take a look at what C# does:
>
>      public class Test
>      {
>          enum E { a, b, c };
>
>          int f(E x, E y)
>          {
>              switch (x)
>              {
>              case E.a:
>                  switch (y)
>                  {
>                      case E.a: return 1;
>                      case E.b: return 4;
>                      case E.c: return 9;
>                  };
>
>                  // ERROR: control cannot fall through from one case labe=
l
> to another
>
>              case E.b:
>              case E.c:
>                  return 0;
>              }
>
>              // ERROR: not all code paths return a value
>          }
>      }
>
> I think we should follow C# on this one [...] both
> -Wimplicit-fallthrough and -Wreturn-type should fire, and an
> equivalent explicit switch statement should be ill-formed.

On the one hand, the above code is not Robust=C2=B9, and thus it is=20
appropriate to diagnose it thusly.

On the other hand, some developers will make the argument that adding a=20
'default:' label can suppress desired compiler warnings that a possible=20
case is not handled.

An ideal solution would be to add something like an 'exceptional' label=20
(maybe just an attribute on a 'default:'), which compilers would=20
optimize as if it is unreachable (and more importantly, not consider=20
when warning if all possible values are handled) and similarly suppress=20
any warning about unreachable code, but could be used to write handlers=20
in order to avoid unexpected behavior when a switch falls through.

(=C2=B9 http://en.wikipedia.org/wiki/Robustness_principle)

--=20
Matthew

--=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_48_30215933.1392934502990
Content-Type: text/plain; charset=UTF-8

On Thursday, February 20, 2014 10:17:31 PM UTC+1, Matthew Woehlke wrote:
>
> An ideal solution would be to add something like an 'exceptional' label
> (maybe just an attribute on a 'default:'), which compilers would
> optimize as if it is unreachable (and more importantly, not consider
> when warning if all possible values are handled) and similarly suppress
> any warning about unreachable code, but could be used to write handlers
> in order to avoid unexpected behavior when a switch falls through.
>

The issue of false reachability in a reachability specification is not
isolated to enumerations or switch statements.

Consider:

    #include <cstdlib>

    int f(int x)
    {
        int y = std::max(x,10);

        while (y++ < 20)
        {
            if (y % 7 == 0)
                return x + y;
        }
    }

Here the end of the function is unreachable, but it is unreasonable to
expect the call flow analysis to work this out - so it will almost
certainly be deemed falsely reachable by an implementation.

As mentioned the programmer can just insert one of the non-returning
statements (jumps, throws), but as an additional option what I am currently
thinking about is there should be a standard library function
`std::unreachable()` which has a special property that it is considered
non-returning by the core language reachability specification.  The
function if executed exhibits undefined behavior.  This allows
implementations, for optimizing code density, to emit no code for it, or in
debug mode it can fail fast with a runtime diagnostic and then abort.  It
is for use in non-throwing functions or when code density is at a premium.
 In places where exceptions are ok you can just throw a std::logic_error or
similar with no special blessing from the reachability specification.

So my example might become:

    #include <cstdlib>

    int f(int x)
    {
        int y = std::max(x,10);

        while (y++ < 20)
        {
            if (y % 7 == 0)
                return x + y;
        }

        std::unreachable();
    }

And Richards might become:

    enum E { a, b, c };

    int f(E x, E y)
    {
        explicit switch (x)
        {
        case a:
            explicit switch (y)
            {
            case a: return 1;
            case b: return 4;
            case c: return 9;
            }

            std::unreachable();

        case b:
        case c:
            return 0;
        }

        std::unreachable();
    }

--

---
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_48_30215933.1392934502990
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 20, 2014 10:17:31 PM UTC+1, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">An ideal solutio=
n would be to add something like an 'exceptional' label=20
<br>(maybe just an attribute on a 'default:'), which compilers would=20
<br>optimize as if it is unreachable (and more importantly, not consider=20
<br>when warning if all possible values are handled) and similarly suppress=
=20
<br>any warning about unreachable code, but could be used to write handlers=
=20
<br>in order to avoid unexpected behavior when a switch falls through.
<br></blockquote><div><br></div><div>The issue of false reachability in a r=
eachability specification is not isolated to enumerations or switch stateme=
nts.</div><div><br></div><div>Consider:</div><div><br></div><div><div><font=
 face=3D"courier new, monospace">&nbsp; &nbsp; #include &lt;cstdlib&gt;</fo=
nt></div><div><font face=3D"courier new, monospace"><br></font></div><div><=
font face=3D"courier new, monospace">&nbsp; &nbsp; int f(int x)</font></div=
><div><font face=3D"courier new, monospace">&nbsp; &nbsp; {</font></div><di=
v><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; int y =
=3D std::max(x,10);</font></div><div><font face=3D"courier new, monospace">=
<br></font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; &=
nbsp; &nbsp; while (y++ &lt; 20)</font></div><div><font face=3D"courier new=
, monospace">&nbsp; &nbsp; &nbsp; &nbsp; {</font></div><div><font face=3D"c=
ourier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; if (y % 7 =
=3D=3D 0)</font></div><div><font face=3D"courier new, monospace">&nbsp; &nb=
sp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return x + y;</font></div><di=
v><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; }</font=
></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; }</font></d=
iv></div><div><br></div><div>Here the end of the function is unreachable, b=
ut it is unreasonable to expect the call flow analysis to work this out - s=
o it will almost certainly be deemed falsely reachable by an implementation=
..</div><div><br></div><div>As mentioned the programmer can just insert one =
of the non-returning statements (jumps, throws), but as an additional optio=
n what I am currently thinking about is there should be a standard library =
function `std::unreachable()` which has a special property that it is consi=
dered non-returning by the core language reachability specification. &nbsp;=
The function if executed exhibits undefined behavior. &nbsp;This allows imp=
lementations, for optimizing code density, to emit no code for it, or in de=
bug mode it can fail fast with a runtime diagnostic and then abort. &nbsp;I=
t is for use in non-throwing functions or when code density is at a premium=
.. &nbsp;In places where exceptions are ok you can just throw a std::logic_e=
rror or similar with no special blessing from the reachability specificatio=
n.</div><div><br></div><div>So my example might become:</div><div><br></div=
><div><div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; #includ=
e &lt;cstdlib&gt;</font></div><div><font face=3D"courier new, monospace"><b=
r></font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; int=
 f(int x)</font></div><div><font face=3D"courier new, monospace">&nbsp; &nb=
sp; {</font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; =
&nbsp; &nbsp; int y =3D std::max(x,10);</font></div><div><font face=3D"cour=
ier new, monospace"><br></font></div><div><font face=3D"courier new, monosp=
ace">&nbsp; &nbsp; &nbsp; &nbsp; while (y++ &lt; 20)</font></div><div><font=
 face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; {</font></div>=
<div><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; &nbs=
p; &nbsp; if (y % 7 =3D=3D 0)</font></div><div><font face=3D"courier new, m=
onospace">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; return x =
+ y;</font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; &=
nbsp; &nbsp; }</font></div><div><font face=3D"courier new, monospace"><br><=
/font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp;=
 &nbsp; std::unreachable();</font></div><div><font face=3D"courier new, mon=
ospace">&nbsp; &nbsp; }</font></div></div></div><div><font face=3D"courier =
new, monospace"><br></font></div><div><font face=3D"courier new, monospace"=
>And Richards might become:</font></div><div><font face=3D"courier new, mon=
ospace"><br></font></div><div><div style=3D"color: rgb(80, 0, 80);"><font f=
ace=3D"courier new, monospace">&nbsp; &nbsp; enum E { a, b, c };</font></di=
v><div style=3D"color: rgb(80, 0, 80);"><font face=3D"courier new, monospac=
e"><br></font></div><div style=3D"color: rgb(80, 0, 80);"><font face=3D"cou=
rier new, monospace">&nbsp; &nbsp; int f(E x, E y)</font></div><div style=
=3D"color: rgb(80, 0, 80);"><font face=3D"courier new, monospace">&nbsp; &n=
bsp; {</font></div><div style=3D"color: rgb(80, 0, 80);"><font face=3D"cour=
ier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; explicit switch (x)</font><=
/div><div style=3D"color: rgb(80, 0, 80);"><font face=3D"courier new, monos=
pace">&nbsp; &nbsp; &nbsp; &nbsp; {</font></div><div style=3D"color: rgb(80=
, 0, 80);"><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp=
; case a:</font></div><div style=3D"color: rgb(80, 0, 80);"><font face=3D"c=
ourier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; explicit s=
witch (y)</font></div><div style=3D"color: rgb(80, 0, 80);"><font face=3D"c=
ourier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; {</font></=
div><div style=3D"color: rgb(80, 0, 80);"><font face=3D"courier new, monosp=
ace">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; case a: return 1;</font></di=
v><div style=3D"color: rgb(80, 0, 80);"><font face=3D"courier new, monospac=
e">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; case b: return 4;</font></div>=
<div style=3D"color: rgb(80, 0, 80);"><font face=3D"courier new, monospace"=
>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; case c: return 9;</font></div><d=
iv style=3D"color: rgb(80, 0, 80);"><font face=3D"courier new, monospace">&=
nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }</font></div><div style=3D"color:=
 rgb(80, 0, 80);"><font face=3D"courier new, monospace">&nbsp;</font></div>=
<div style=3D"color: rgb(80, 0, 80);"><font face=3D"courier new, monospace"=
>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; std::unreachable();</font></div>=
<div style=3D"color: rgb(80, 0, 80);"><font face=3D"courier new, monospace"=
><br></font></div><div style=3D"color: rgb(80, 0, 80);"><font face=3D"couri=
er new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; case b:</font></div><div sty=
le=3D"color: rgb(80, 0, 80);"><font face=3D"courier new, monospace">&nbsp; =
&nbsp; &nbsp; &nbsp; case c:</font></div><div style=3D"color: rgb(80, 0, 80=
);"><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp=
; &nbsp; return 0;</font></div><div style=3D"color: rgb(80, 0, 80);"><font =
face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; }</font></div><=
div style=3D"color: rgb(80, 0, 80);"><font face=3D"courier new, monospace">=
<br></font></div><div style=3D"color: rgb(80, 0, 80);"><div><font face=3D"c=
ourier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; std::unreachable();</fon=
t></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; }<br></fon=
t></div></div></div><div><font face=3D"courier new, monospace"><br></font><=
/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_48_30215933.1392934502990--

.

------=_Part_431_4502816.1392962939442
Content-Type: text/plain; charset=UTF-8

I personally think the most-needed changes in the proposal are the
importation of Java's "break label" and "continue label" statements.  These
constructions are easy to understand, probably easy to implement, and won't
cause problems with existing code.  On a labeled for/do/while/switch, label
goto, break and continue would all be valid and would have different
meanings (with the exception of "continue" on a "switch").  goto = restart
loop, break = exit loop, continue = next iteration of loop.

For labeled goto, I'm not sure whether when the label targets a loop or
switch would justify allowing its use in a C++14 constexpr function, since
I don't know why it was prohibited.  Labeled loop goto/break/continue avoid
most of the problems of the typical use of goto.

I think it's worth considering submitting labeled break and continue as a
separate C++ - or C - proposal because it is seems like it is much simpler
than the proposal here, more important and useful, and more likely to be
approved.  Just my opinion, but I wouldn't really know.

I'm a complete layman when it comes to formal C++, so I apologize if I
messed something up by writing on this ...mailing list?  Newsgroup?

Melissa

--

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

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

<div dir=3D"ltr">I personally think the most-needed changes in the proposal=
 are the importation of Java's "break label" and "continue label" statement=
s.&nbsp; These constructions are easy to understand, probably easy to imple=
ment, and won't cause problems with existing code.&nbsp; On a labeled for/d=
o/while/switch, label goto, break and continue would all be valid and would=
 have different meanings (with the exception of "continue" on a "switch").&=
nbsp; goto =3D restart loop, break =3D exit loop, continue =3D next iterati=
on of loop.<br><br>For labeled goto, I'm not sure whether when the label ta=
rgets a loop or switch would justify allowing its use in a C++14 constexpr =
function, since I don't know why it was prohibited.&nbsp; Labeled loop goto=
/break/continue avoid most of the problems of the typical use of goto.<br><=
br>I think it's worth considering submitting labeled break and continue as =
a separate C++ - or C - proposal because it is seems like it is much simple=
r than the proposal here, more important and useful, and more likely to be =
approved.&nbsp; Just my opinion, but I wouldn't really know.<br><br>I'm a c=
omplete layman when it comes to formal C++, so I apologize if I messed some=
thing up by writing on this ...mailing list?&nbsp; Newsgroup?<br><br>Meliss=
a<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 />

------=_Part_431_4502816.1392962939442--

.

------=_Part_498_5421466.1393950336657
Content-Type: text/plain; charset=UTF-8

On Friday, February 21, 2014 7:08:59 AM UTC+1, myri...@gmail.com wrote:
>
> I personally think the most-needed changes in the proposal are the
> importation of Java's "break label" and "continue label" statements.
>

If you want these features you should write a proposal for them (but first
check that it hasn't already been proposed and rejected).

But they are completely unrelated to the fallthrough issue that is the
subject of the proposal being discussed 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_498_5421466.1393950336657
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, February 21, 2014 7:08:59 AM UTC+1, myri...@gma=
il.com 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">=
I personally think the most-needed changes in the proposal are the importat=
ion of Java's "break label" and "continue label" statements.<br></div></blo=
ckquote><div><br></div><div>If you want these features you should write a p=
roposal for them (but first check that it hasn't already been proposed and =
rejected).</div><div><br></div><div>But they are completely unrelated to th=
e fallthrough issue that is the subject of the proposal being discussed her=
e.</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_498_5421466.1393950336657--

.

------=_Part_667_21843642.1393956983765
Content-Type: text/plain; charset=UTF-8

On Tuesday, March 4, 2014 5:25:36 PM UTC+1, corn...@google.com wrote:
>
> On Friday, February 21, 2014 7:08:59 AM UTC+1, myri...@gmail.com wrote:
>>
>> I personally think the most-needed changes in the proposal are the
>> importation of Java's "break label" and "continue label" statements.
>>
>
> If you want these features you should write a proposal for them (but first
> check that it hasn't already been proposed and rejected).
>
> But they are completely unrelated to the fallthrough issue that is the
> subject of the proposal being discussed here.
>

? Have you read N3879?  It isn't clear whether you are unaware that those
jump statements are part of the proposal, or whether you are complaining
that the scope of N3879 is too wide.  If the latter, it was felt that as
they are all new jump statements (along with goto case expr and goto
default) with justification from other languages (Java and C#), so I
decided to propose them as one piece of work.

--

---
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_667_21843642.1393956983765
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, March 4, 2014 5:25:36 PM UTC+1, corn...@google=
..com 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">On=
 Friday, February 21, 2014 7:08:59 AM UTC+1, <a>myri...@gmail.com</a> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I personally thin=
k the most-needed changes in the proposal are the importation of Java's "br=
eak label" and "continue label" statements.<br></div></blockquote><div><br>=
</div><div>If you want these features you should write a proposal for them =
(but first check that it hasn't already been proposed and rejected).</div><=
div><br></div><div>But they are completely unrelated to the fallthrough iss=
ue that is the subject of the proposal being discussed here.</div></div></b=
lockquote><div><br></div><div>? Have you read N3879? &nbsp;It isn't clear w=
hether you are unaware that those jump statements are part of the proposal,=
 or whether you are complaining that the scope of N3879 is too wide. &nbsp;=
If the latter, it was felt that as they are all new jump statements (along =
with goto case expr and goto default) with justification from other languag=
es (Java and C#), so I decided to propose them as one piece of work.</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_667_21843642.1393956983765--

.

------=_Part_444_12782816.1394026122718
Content-Type: text/plain; charset=UTF-8



On Tuesday, March 4, 2014 7:16:23 PM UTC+1, Andrew Tomazos wrote:
>
> On Tuesday, March 4, 2014 5:25:36 PM UTC+1, corn...@google.com wrote:
>>
>> On Friday, February 21, 2014 7:08:59 AM UTC+1, myri...@gmail.com wrote:
>>>
>>> I personally think the most-needed changes in the proposal are the
>>> importation of Java's "break label" and "continue label" statements.
>>>
>>
>> If you want these features you should write a proposal for them (but
>> first check that it hasn't already been proposed and rejected).
>>
>> But they are completely unrelated to the fallthrough issue that is the
>> subject of the proposal being discussed here.
>>
>
> ? Have you read N3879?  It isn't clear whether you are unaware that those
> jump statements are part of the proposal, or whether you are complaining
> that the scope of N3879 is too wide.  If the latter, it was felt that as
> they are all new jump statements (along with goto case expr and goto
> default) with justification from other languages (Java and C#), so I
> decided to propose them as one piece of work.
>
>
OK, apparently I'm an idiot. Haven't read the proposal and thought it was
about explicit switch only. Furthermore, I read "most-needed changes in the
proposal" as "*to* the proposal".

Never mind me, then.

Sebastian

--

---
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_444_12782816.1394026122718
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, March 4, 2014 7:16:23 PM UTC+1, Andrew=
 Tomazos 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=
">On Tuesday, March 4, 2014 5:25:36 PM UTC+1, <a>corn...@google.com</a> wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, Febr=
uary 21, 2014 7:08:59 AM UTC+1, <a>myri...@gmail.com</a> 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">I personally think the most-ne=
eded changes in the proposal are the importation of Java's "break label" an=
d "continue label" statements.<br></div></blockquote><div><br></div><div>If=
 you want these features you should write a proposal for them (but first ch=
eck that it hasn't already been proposed and rejected).</div><div><br></div=
><div>But they are completely unrelated to the fallthrough issue that is th=
e subject of the proposal being discussed here.</div></div></blockquote><di=
v><br></div><div>? Have you read N3879? &nbsp;It isn't clear whether you ar=
e unaware that those jump statements are part of the proposal, or whether y=
ou are complaining that the scope of N3879 is too wide. &nbsp;If the latter=
, it was felt that as they are all new jump statements (along with goto cas=
e expr and goto default) with justification from other languages (Java and =
C#), so I decided to propose them as one piece of work.</div><div><br></div=
></div></blockquote><div><br></div><div>OK, apparently I'm an idiot. Haven'=
t read the proposal and thought it was about explicit switch only. Furtherm=
ore, I read "most-needed changes in the proposal" as "*to* the proposal".<b=
r></div><div><br></div><div>Never mind me, then.</div><div><br></div><div>S=
ebastian</div></div>

<p></p>

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

------=_Part_444_12782816.1394026122718--

.