Why doesn't "switch" statement have "break" as default?

[Betty]

[Duff's device]

http://www.lysator.liu.se/c/duffs-device.html

ISTM that this bit:

``Actually, I have another revolting way to use switches to implement
interrupt driven state machines but it's too horrid to go into.

...is reminiscent of Fermat's Last Theorem ;-)

You mean his final theorem? ;-)

 

[Betty]

If I intentionally allow fall-through, I usually document it so another
developer (or myself 6 months later) doesn't look at the code and assume
it's a mistake:

switch (whatever)
{
case 0:
// don't break; allow fall-through
case 1:
break;
}

You don't need the comment because languages that
have // to start a comment are also "self documenting" ;-)

 

[Dale King]

In most of the case,there is a "break" after every "case" in switch
statement, poor coders have to write "break" explicitly again and
again,and the worse is that sometimes someone forget to do that.So why
don't the designers make it a default state? if sometimes someone
prefer his switch statement without a break,he can achieve it by
duplicating code for once.

I have entered some RFE's to Sun to try to move Java in this direction
it is a multistep process to get there without losing backwards
compatibility too quickly.

My plan is:

- Introduce a syntax for EXPLICIT drop through to the next case. This
has to be using syntax that is not currently valid. The leading
contenders are continue case; or continue switch;
- Introduce syntax for more complicated cases including ranges, lists,
and relational expressions. See RFE 4269827 which I submitted.
- Start issuing warnings for code that has implicit fallthrough. Such
code should be made explicit or converted to use lists or ranges. JDK1.5
actually introduced an optional warning for this using the
-Xlint:fallthrough option. However they have not done the prior steps to
add an explicit fallthrough for the cases where you really want
fallthrough.
- Eventually the warning can be turned into an error and then implicit
fallthrough is eliminated.

 

[Esmond Pitt]

I have entered some RFE's to Sun to try to move Java in this direction
it is a multistep process to get there without losing backwards
compatibility too quickly.

Dale, I support the range and relational ideas, much of them turn up in
Pascal & Ada, and the relational ones are in COBOL of all places, but
let's be practical about fallthrough. Sun are never going to do
anything that is backward-incompatible, and as a product manager for 25
years I can only agree and if they do I will be screaming blue murder.

 

[Patricia Shanahan]

Dale, I support the range and relational ideas, much of them turn up in
Pascal & Ada, and the relational ones are in COBOL of all places, but
let's be practical about fallthrough. Sun are never going to do
anything that is backward-incompatible, and as a product manager for 25
years I can only agree and if they do I will be screaming blue murder.

However, is there some way of creating a new syntax that has
the desired behavior? I know it's nasty, but it may be
better than either sticking with the current situation or
breaking compatability:

SwitchBreakStatement:
switch break ( Expression ) SwitchBlock

to imply a break after every case, with the existing syntax:

SwitchStatement:
switch ( Expression ) SwitchBlock

still allowing fall through.

Of course, given SwitchBreakStatement with range and
relational cases, I can imagine programming shops deciding
to prohibit SwitchStatement as a matter of internal standards.

Patricia

 

[Glen Pepicelli]

My question would be why would you add ranges only to one very specific
part of the language? It seems what you really what are new range
operators:

if ( x in 1..4 ) { doSomething; }

above you have an 'in' operator and a '..' anounymous range construction
operator.

glen.

 

[Thomas G. Marshall]

Patricia Shanahan coughed up:

However, is there some way of creating a new syntax that has
the desired behavior? I know it's nasty, but it may be
better than either sticking with the current situation or
breaking compatability:

SwitchBreakStatement:
switch break ( Expression ) SwitchBlock

to imply a break after every case, with the existing syntax:

SwitchStatement:
switch ( Expression ) SwitchBlock

still allowing fall through.

This is [maybe?] worse. It would be far to easy to overlook the break
indicator at the top. Pondering...

Of course, given SwitchBreakStatement with range and
relational cases, I can imagine programming shops deciding
to prohibit SwitchStatement as a matter of internal standards.

Patricia

I would prefer that the compiler lint option warning for fall through change
to a real honest to goodness error, with an option to allow it. So that the
default is to break existing compatibility, but that getting it to compile
is always achievable.



--
Puzzle: You are given a deck of cards all face down
except for 10 cards mixed in which are face up.
If you are in a pitch black room, how do you divide
the deck into two piles (may be uneven) that each
contain the same number of face-up cards?
Answer (rot13): Sebz naljurer va gur qrpx, qrny bhg
gra pneqf naq syvc gurz bire.

 

[Betty]

I would rather have "goto casename".
Then we could get in the most important
feature in modern languages today.

 

[Mike Schilling]

I would rather have "goto casename".
Then we could get in the most important
feature in modern languages today.

You are aware that C# has exactly this?

 

[Mike Schilling]

I would certainly agree if they made the change instantaneously, but as I
said it is a multiple step process to get there. Essentially, the plan is
to deprecate language syntax just like API's can be deprecated. Would you
scream blue murder is Sun eventually removed some API's that have been
deprecated for a long time?

If it broke a working application for which I didn't have the source code?
Yes.

 

[Chris Uppal]

If it broke a working application for which I didn't have the source code?
Yes.

You may have been talking about APIs in general, rather than the switch/case
syntax in particular. I don't even slightly support the idea of "fixing"
Java's switch/case semantics (one ot the crowning glories of C, IMO) but I see
no reason why introducing Dale's abominable (I /M/ O) modifications should have
any effect at all on the generated bytecode, so binary compatibility should not
be an issue.

-- chris

 

[John McGrath]

This is why:

switch (type)
{
case COMMAND_RC5:
case COMMAND_RC5_STRING:
case COMMAND_RC6_MODE_0:
buf = new byte[4];
buf[0] = info;
contentIndex = 1;
break;
case COMMAND_RC5_EXTENDED:
case COMMAND_CDI:
case COMMAND_RC6_MODE_2A:
buf = new byte[5];
buf[0] = info;
contentIndex = 1;
break; :
:
}

If that were it, then a much better approach would have been to use a
syntax similar to the Pascal case statement. In other words, allow
multiple values in a switch block, and have an automatic break at the
end of the block.

switch (type)
{
case COMMAND_RC5, COMMAND_RC5_STRING, COMMAND_RC6_MODE_0:
buf = new byte[4];
buf[0] = info;
contentIndex = 1;
case COMMAND_RC5_EXTENDED, COMMAND_CDI, COMMAND_RC6_MODE_2A:
buf = new byte[5];
buf[0] = info;
contentIndex = 1;
:
:
}

 

[Lucy]

If it broke a working application for which I didn't have the source code?
Yes.

Is it because you (OP) are lazy? There are tools that you can run
that will tell you of potential trouble due to this. Takes only
a few seconds to run.

 

[Mike Schilling]

You may have been talking about APIs in general, rather than the
switch/case
syntax in particular.

Yes. Sorry if that wasn't clear.

I don't even slightly support the idea of "fixing"
Java's switch/case semantics (one ot the crowning glories of C, IMO) but I
see
no reason why introducing Dale's abominable (I /M/ O) modifications should
have
any effect at all on the generated bytecode, so binary compatibility
should not
be an issue.

Agreed.

 

[Thomas G. Marshall]

Lucy coughed up:

Is it because you (OP) are lazy? There are tools that you can run
that will tell you of potential trouble due to this. Takes only
a few seconds to run.

To whom are you referring? Who is the original poster that you are talking
about? Certainly not /the/ OP for the thread, because you only quoted Mike
Schilling and Dale King....

 

[Dale King]

You may have been talking about APIs in general, rather than the switch/case
syntax in particular. I don't even slightly support the idea of "fixing"
Java's switch/case semantics (one ot the crowning glories of C, IMO) but I see
no reason why introducing Dale's abominable (I /M/ O) modifications should have
any effect at all on the generated bytecode, so binary compatibility should not
be an issue.

I take no offense at your opinon of my suggestions, but I'm curious what
you find so abominable about the suggestions. Perhaps I'm not sure
exactly which ones you find abominable. There were basically two types
of suggestions:

- handling fall-through explicit vs. implicit
- adding lists, ranges, etc. to cases

I could understand having personal issue with the first, but if you have
trouble with the second I would like to understand why. As I point out
in the comments section of the RFE they can actually have some
performance beneifts.

 

[Chris Uppal]

[Sorry about the late reply]

I take no offense at your opinon of my suggestions,

Good. It wasn't my intent to give offense, I'm glad it didn't.

but I'm curious what
you find so abominable about the suggestions. Perhaps I'm not sure
exactly which ones you find abominable. There were basically two types
of suggestions:

- handling fall-through explicit vs. implicit
- adding lists, ranges, etc. to cases

More the first than the second, but neither really captures what I don't like.
Here's my shot at explaining.

The 'C' switch statement is in no way syntactic sugar for a cascade of if-else
statements. If it's syntactic sugar at all, then it's sugar for an assigned
GOTO. The semantics of switch are a surfacing of a vitally (IMO) important
underlying implementation technique (jump table), and as such it seems to me
not only suitable, but even inevitable, that the 'case' values act as labels
(in the GOTO sense). I wouldn't want to dilute that.

BTW, I do realise that the compiler and/or JIT is allowed to implement any
given switch as an if-then cascade or a hash table lookup (or similar) if it
deems that to be better -- I'm talking about the semantics that the programmer
sees, not the /actual/ implementation technique (unless the compiler goes
overboard in not honouring my wishes as expressed in the code).


As to the proposal to add lists and ranges, a couple of comments, not entirely
tied to the above:

I don't see the point of having comma-separated lists of values. That seems to
me to be change for change's sake (with concomitant impact on all tools that
make use of Java in source form -- such as Eclipse). It seems to be exchanging
one form of readability for another. If both forms are allowed, then the
visual complexity of the source increases (since there are two different ways
of expressing /exactly/ the same thing). If only one or the other were allowed
then I'd marginally prefer the one we already have, since it works well for
long identifiers.

I'd -- by a small margin -- support ranges. That, too, is adding complexity,
but I'm prepared to believe that it would be able to pay its way. I'm less
sure that it would /also/ be able to justify the costs of a change to the
language -- that's to say, if ranges had been there from the beginning, then I
doubt whether I'd see then as a mistake, but I'm not eager to see /more/
language changes at this stage. BTW, one specific technical problem with
adding ranges is that the JVM puts hard limits on how many switch values are
allowed, and those limits would translate into apparently arbitrary (and very
easily exceeded) limits on the Java source code.

I'd still have reservations, too, in that I think that ranges -- unless very
carefully presented as /only/ syntactic sugar -- would dilute the jump-table
aspect which I want to preserve. To see that, consider what happens when
ranges overlap. Should that be simply forbidden ? I would say yes, but
another reader might want to allow overlaps, but make the first match be the
one that was selected. To me, that suggestion can only arise if someone has
already lost the sense of a switch as being a jump table.

If what you want is really a multi-way 'if', then I'd rather see it presented
as such -- ie. as a new syntactic structure designed in such a way that its
semantics were those of an if-then cascade but which the compiler understood
well enough (in well-defined ways) to be able to apply optimisations like
hashing where appropriate. Of course that would be adding another linguistic
construct, which I've already said that I don't want to see, but -- on
balance -- I think I'd prefer that to hacking around with the 'C' family's
crowning glory ;-)

-- chris