www.digitalmars.com         C & C++   DMDScript  

D - Switch statement (again)

reply C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
Just because I like metaphorically beating dead horses...

How about the following alterating to the switch statement

int a = /* blah */;
switch( a )
{
        case 0:
                /* do something */
                /* fall through */
        case 1:
                /* do something else */
                /* implicit break; */
        case 10
        {
                /* do something */
                /* implicit break; */
        }
        case 11 {}      /* do nothing (implicit break) */
        default:
                /* do something */
}

The idea is that the cases have two formats, one that follows the normal C 
syntax and a new format utilising an implicit break.
The traditional format looks (and works) like a label where the new format 
looks (and works) like a block.
This will allow normal C programmes to work in their original format 
(though this format may be deprecated) and newer D programmes to use the 
implicit break semantics.
Parsing the new format should be simple.
The only problem I can see is that ...
        case 1: { }
and     case 1{}
are different - maybe the former case (case1:{}) should not be supported?

C 2002/8/27
Aug 27 2002
next sibling parent reply Suporte Internet <suporte spica.mps.com.br> writes:
C.R.Chafer <blackmarlin nospam.asean-mail.com> wrote:
 How about the following alterating to the switch statement
 
 int a = /* blah */;
 switch( a )
 {
        case 0:
                /* do something */
                /* fall through */
        case 1:
                /* do something else */
                /* implicit break; */
        case 10
        {
                /* do something */
                /* implicit break; */
        }
        case 11 {}      /* do nothing (implicit break) */
        default:
                /* do something */
 }
Good idea ! And use the break for loop statements as Pavel have sugested: for (;;){ i = getValue(); case (i) { 1 : codeBeforeNextIteration(); 2 { nextIteration(); } 3 : 4 : 5 { anotherIteration(); } 6 : break; // out of for loop } }
 The only problem I can see is that ...
        case 1: { }
 and     case 1{}
 are different - maybe the former case (case1:{}) should not be supported?
Aug 27 2002
parent C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
Suporte Internet wrote:

 Good idea !
Thanks :-)
 And use the break for loop statements as Pavel have sugested:
 
 for (;;){
 i = getValue();
 case (i) {
 1 : codeBeforeNextIteration();
 2 {
 nextIteration();
 }
 3 : 4 : 5 {
 anotherIteration();
 }
 6 : break; // out of for loop
 }
 }
I think using labeled breaks for such a piece of code would be preferable. lbl: for(;;) switch( a ) { case( 100 ) { break lbl; } default { ++a } } And I still like the (much) earlier idea (though I can not remember who proposed it) of having continue work on switch statements as well as break - which would be very useful for implementing state machines. C 2002/8/27
Aug 27 2002
prev sibling next sibling parent reply "Richard Krehbiel" <rich kastle.com> writes:
"C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message
news:akfqu3$23s7$1 digitaldaemon.com...
 Just because I like metaphorically beating dead horses...

 How about the following alterating to the switch statement

 int a = /* blah */;
 switch( a )
 {
         case 0:
                 /* do something */
                 /* fall through */
         case 1:
                 /* do something else */
                 /* implicit break; */
         case 10
         {
                 /* do something */
                 /* implicit break; */
         }
         case 11 {}      /* do nothing (implicit break) */
         default:
                 /* do something */
 }

 The idea is that the cases have two formats, one that follows the normal C
 syntax and a new format utilising an implicit break.
 The traditional format looks (and works) like a label where the new format
 looks (and works) like a block.
Look at subtle difference between case 1 { } and case 1: { } The second case too similar to the first, fully acceptable to the compiler, and implies a fallthrough behavior. This is a typo begging to happen. My personal belief is: 1. Case enumerations ("case 1, 2, 3:") and ranges ("case 1..5:") should be supported; and 2. Fallthrough behavior should be eliminated; all cases have an implicit break. In the last tiny few percent of cases where a deliberate fallthrough is needed, you can use a plain old goto. (...and I'm soooooo not concerned with training the legions of C, C++, and Java programmers. Basic programmers have been doing it this way for a long time, and if they can do it, so can we.) -- Richard Krehbiel, Arlington, VA, USA rich kastle.com (work) or krehbiel3 comcast.net (personal)
Aug 27 2002
next sibling parent reply C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
Richard Krehbiel wrote:

 Look at subtle difference between
 
 case 1 { }
   and
 case 1: { }
 
 The second case too similar to the first, fully acceptable to the
 compiler,
 and implies a fallthrough behavior.  This is a typo begging to happen.
That is why I recommend the compiler checks for this and disallows it (in my opinion { ... } statements are useless and should be disallowed anyway - however they are there for C compatibility. Thinking further maybe requireing brackets around the no fall though case would solve this problem (and fit in even better with the D syntax ).. for example.. switch( a ) { case 1 : /* std C */ case( 2 ) { /* no fall though D case */ } default { /* statements */ } } Of course mixing fall though and none fall though cases would not be recommended. The compiler may even specifically disallow it (forcing the programmer to use gotos to implement fall through) or report that C style fall through case statements are deprecated (but still supported). If these options were selected then I suspect such expected typos would become very rare. And surely though having fallthough is just asking for similar mistakes to such a typo (id est forgetting the break;) which would be far more difficult for the compiler to spot.
 My personal belief is:
 
 1. Case enumerations ("case 1, 2, 3:") and ranges ("case 1..5:") should be
 supported; and
I think this is already supported - which is why I failed to mention it.
 2. Fallthrough behavior should be eliminated; all cases have an implicit
 break.
Yes, but the reason fall thoughs are maintained is for C compatibility - and this is the main argument for keeping C compatible syntax (also see operator precidence, etcetra). There is no reason not to deprecate them though.
 In the last tiny few percent of cases where a deliberate fallthrough is
 needed, you can use a plain old goto.
 
 (...and I'm soooooo not concerned with training the legions of C, C++, and
 Java programmers.  Basic programmers have been doing it this way for a
 long time, and if they can do it, so can we.)
I see no recommendations for making D like BASIC :-) C 2002/8/27 Off topic: My ideal switch statement is the one used by OOMIC (well I did design it) but OOMIC and D syntax is very different in some areas and as a result I would not recommend an exact match.
Aug 27 2002
next sibling parent reply Mac Reiter <Mac_member pathlink.com> writes:
That is why I recommend the compiler checks for this and disallows it (in 
my opinion { ... } statements are useless and should be disallowed anyway - 
however they are there for C compatibility.
Slightly off topic, but in C/C++, the case: { int i; for (i=0; i<a.length; ++i) {/*something*/} } break; form is handy, because it gives you a scope where you can create "little" variables that are only used and only useful for that particular case. Without the extra scope, you have to put all these variables somewhere above the switch. While style guidelines vary, and some are deadset against the "declare it just before you use it" approach, others require it. While I don't particularly care if we keep C syntax (having worked with switch-like statements in several languages), I would hate to see an otherwise valid syntax ruled illegal, thus disabling one of the more prevalent style guidelines. I also hate the idea of "case{}" being different from "case:{}", even *if* one of them is illegal. Being a bit of an explicitness nut, it wouldn't particularly bother me to say that every case *must* end with either 'break' or 'fallthrough' (or 'continue', but then we confuse the loop issue even more). Since I also hate not being able to break out of a loop from inside a switch, it might be better to make a new keyword altogether, like 'endcase'. Of course, if you have endcase, maybe fallthrough should be nextcase... Anyway, whatever the syntax, the idea is to simply not have a default behavior at the end of the case. No matter what you want to do, you have to explicitly state it, so you can't possibly make an error by omission. switch(state) { case START: // something state = FIRST; nextcase; case FIRST: // first state handling endcase; case SECOND: // second state handling default: // ERROR: failed to state how to terminate "case SECOND:" } If you use 'break' instead of 'endcase', the copy/paste C code issue goes away. For the 99% of code that breaks after every case, nothing changes. For the remaining code, a clear error message is printed, requiring that the programmer specify what to do at the end of the case. Personally, I'd rather stop using C syntax (break keyword, that is), so that break and continue can continue to break out of loops. Search-and-replace on a selected piece of code is supported in nearly all editors, so it wouldn't be that hard to switch 'break' to 'endcase' on any imported C code. I also like the BASIC ranges and selection system, as someone (sorry...) mentioned in a previous post. It is not enough, by itself, but combined with the fallthrough system it can be very concise and elegant. Having done a lot of Visual Basic programming at one point in my career, I learned to appreciate the ranges and hate the lack of fallthrough. Without fallthrough, you end up using a superset of the range in the case, and then either doing another switch or an 'if' statement to filter out particular cases that would have been in the portion of code in front of the fallthrough. Having warped my head around C fallthrough, it doesn't matter tremendously to me either way, although I would be happier if this source of ongoing typo bugs would go away... Mac
Aug 27 2002
next sibling parent C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
Mac Reiter wrote:

That is why I recommend the compiler checks for this and disallows it (in
my opinion { ... } statements are useless and should be disallowed anyway
- however they are there for C compatibility.
Slightly off topic, but in C/C++, the case: { int i; for (i=0; i<a.length; ++i) {/*something*/} } break;
Yes, though I know about this form I never use it - that is why I think it useless, together with the fact that an intellegent compiler should be able to optimise away the need for this.
 form is handy, because it gives you a scope where you can create "little"
 variables that are only used and only useful for that particular case. 
 Without the extra scope, you have to put all these variables somewhere
 above the switch. While style guidelines vary, and some are deadset
 against the "declare it just
 before you use it" approach, others require it.  While I don't
 particularly care if we keep C syntax (having worked with switch-like
 statements in several languages), I would hate to see an otherwise valid
 syntax ruled illegal, thus disabling one of the more prevalent style
 guidelines.
I personally like the Ada syntax if we are going for established languages.
 I also hate the idea of "case{}" being different from "case:{}", even *if*
 one of them is illegal.
Yes, after some though I tend to agree. The suggestion case( val ){ .. } case_statement : "case" "(" case_literal ")" "{" statements "}" | "case" case_literal ":" statements ;
 Being a bit of an explicitness nut, it wouldn't particularly bother me to
 say that every case *must* end with either 'break' or 'fallthrough' (or
 'continue',
Seems a good idea.
 but then we confuse the loop issue even more).  Since I also hate not
 being able to break out of a loop from inside a switch, it might be better
 to make a new
 keyword altogether, like 'endcase'.  Of course, if you have endcase, maybe
 fallthrough should be nextcase...
If we go down this path how about "continue case;" or "continue switch;" This has the following advantages (1) LR(1) [I think LL(1) to] parseable syntax (2) no new keywords (3) fairly obvious meaning (4) compatible with C (with minor porting effort) And then use your rule "if there is no break and no fallthough specifier then report error". Though this would cause a few problems when porting C code they should be easy to track down and fix (and may even highlight some bugs in the code).
 Anyway, whatever the syntax, the idea is to
 simply not have a default behavior at the end of the case.  No matter what
 you want to do, you have to explicitly state it, so you can't possibly
 make an error by omission.
 
 switch(state)
 {
 case START:
 // something
 state = FIRST;
 nextcase;
 case FIRST:
 // first state handling
 endcase;
 case SECOND:
 // second state handling
 default: // ERROR: failed to state how to terminate "case SECOND:"
 }
 
 If you use 'break' instead of 'endcase', the copy/paste C code issue goes
 away.
As we can use "break toLabel;" I see no reason to not use break.
 For the 99% of code that breaks after every case, nothing changes.  For
 the remaining code, a clear error message is printed, requiring that the
 programmer specify what to do at the end of the case.
[OT: More like 70-80% looking at my code - but that is not a problem - however when combined with ranges and selections (ie. "case 1,2,5..7:") I almost never need fall throughs]
 Personally, I'd rather stop using C syntax (break keyword, that is), so
 that
 break and continue can continue to break out of loops.  Search-and-replace
 on a selected piece of code is supported in nearly all editors, so it
 wouldn't be that hard to switch 'break' to 'endcase' on any imported C
 code.
I would rather extend continue to work with switches - I think we should call it quits and just keep doing whatever D is doing now (or have a vote on it).
 I also like the BASIC ranges and selection system, as someone (sorry...)
 mentioned in a previous post.  It is not enough, by itself, but combined
 with
 the fallthrough system it can be very concise and elegant.  Having done a
 lot of Visual Basic programming at one point in my career, I learned to
 appreciate the
 ranges and hate the lack of fallthrough.  Without fallthrough, you end up
 using a superset of the range in the case, and then either doing another
 switch or an 'if' statement to filter out particular cases that would have
 been in the portion of code in front of the fallthrough.
Agreed, though goto can emulate fall through (at the expense of purety).
 Having warped my head around C fallthrough, it doesn't matter tremendously
 to me either way, although I would be happier if this source of ongoing
 typo bugs would go away...
 
 Mac
Me neither - I just remember having to explain this to a group of first year students, and as a result simple rules and a consistant language really helps matters .. an aspect where C falls short. C 2002/8/27
Aug 28 2002
prev sibling parent Pavel Minayev <evilone omen.ru> writes:
On Tue, 27 Aug 2002 19:59:23 +0000 (UTC) Mac Reiter <Mac_member pathlink.com> 
wrote:

 Being a bit of an explicitness nut, it wouldn't particularly bother me to say
 that every case *must* end with either 'break' or 'fallthrough' (or 
'continue',
 but then we confuse the loop issue even more).  Since I also hate not being 
able said, "if it wants a break there, why the $ &% it doesn't put it by itself?!". I wholeheartedly agree. Just make non-fallthru behavior default.
Aug 27 2002
prev sibling parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
"C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message
news:akggiv$2so7$1 digitaldaemon.com...
 That is why I recommend the compiler checks for this and disallows it (in
 my opinion { ... } statements are useless and should be disallowed
anyway -
 however they are there for C compatibility.
The brackets (in C++) are there to allow one to declare local variables inside the case. Yes, this does get used in practice. Sean
Aug 27 2002
prev sibling parent reply Joel Lucsy <jjlucsy ameritech.net> writes:
"Richard Krehbiel" <rich kastle.com> wrote in
news:akg8a1$2j04$1 digitaldaemon.com: 

 My personal belief is:
 
 1. Case enumerations ("case 1, 2, 3:") and ranges ("case 1..5:")
 should be supported; and
 2. Fallthrough behavior should be eliminated; all cases have an
 implicit break.
 
 In the last tiny few percent of cases where a deliberate fallthrough
 is needed, you can use a plain old goto.
How about this in addition to: switch (something) { case 0: /*dosomething and fallthru to case 1*/ nobreak case 1: /*dosomething else*/ case 2: /*dosomething entirely else, case 1 won't get here*/ }
Aug 27 2002
parent "anderson" <anderson firestar.com.au> writes:
"Joel Lucsy" <jjlucsy ameritech.net> wrote in message
news:Xns9277E3774C7F3jjlucsy 63.105.9.61...
 "Richard Krehbiel" <rich kastle.com> wrote in
 news:akg8a1$2j04$1 digitaldaemon.com:

 My personal belief is:

 1. Case enumerations ("case 1, 2, 3:") and ranges ("case 1..5:")
 should be supported; and
 2. Fallthrough behavior should be eliminated; all cases have an
 implicit break.

 In the last tiny few percent of cases where a deliberate fallthrough
 is needed, you can use a plain old goto.
How about this in addition to: switch (something) { case 0: /*dosomething and fallthru to case 1*/ nobreak case 1: /*dosomething else*/ case 2: /*dosomething entirely else, case 1 won't get here*/ }
I'm sorry I don't see much of an advantage here. Mite as well add a brake in this case. It's not much better.
Aug 29 2002
prev sibling next sibling parent reply "anderson" <anderson firestar.com.au> writes:
I apologise if this idea has already been mentioned. I'd like some form of
non-case fall though parhaps like this:

switch (i)
{
    case (1, 2, 3) //Auto non fall though
    case 6: //Normal
    default: //Normal
}

Neat, and it stands out.

Futher more the name could be changed, if there's still problems with the
above.

switch (i)
{
    select (1, 2, 3) //Auto non fall though
    case 6: //Normal
    default: //Normal
}
Aug 29 2002
parent reply C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
anderson wrote:

 switch (i)
 {
     select (1, 2, 3) //Auto non fall though
     case 6: //Normal
     default: //Normal
 }
That seems a good idea. However "select" may be better replaced by "when" as in Ada (less typeing). If a new keyword is used then the brackets would not really be needed, though it would make little difference, to me, wether they were included or not. mandatory example... switch(i) { when(1,2,3) { /* auto break - recommended */ } case 6: /* standard C */ default: /* standard C */ } or switch(i) { when 1,2,3: /* auto break - recommended */ case 6: /* standard C */ default: /* standard C */ } C 2002/8/29
Aug 29 2002
next sibling parent reply Mark Evans <Mark_member pathlink.com> writes:
Fallthrough is a sometimes-important feature for expert C programmers.  I have
used it on rare occasions.  A new keyword "fallthrough" would be good.  Better,
"goto case N" permitting arbitrary jumps to any other part of the case
statement.

The real problem with C switch statements is the const requirement on the tests.
C switch statements will not compile unless all tests resolve to integer
comparisons at compile time.  This is silly because the alternative (if/else
if/else) technique works fine, and there is no reason switch should not cover
the same ground.  It is just a C legacy problem.  Maybe D can fix it.

I recently desired to construct a switch based on a std::string objects.  The
ideal compiler should be smart enough to create const std::string objects from
the constant strings, and also to apply std::string::operator==() for the case
tests.  Perhaps D could pull of what C++ never did.

Mark


std::string    variable;
switch (variable)
{
case "a_certain_string_1":
// do stuff
break;
case "a_certain_string_2":
// do other stuff
break;
default:
break;
}
Aug 29 2002
parent Pavel Minayev <evilone omen.ru> writes:
Mark Evans <Mark_member pathlink.com> wrote in
news:akm8e0$1dj3$1 digitaldaemon.com: 

 I recently desired to construct a switch based on a std::string
 objects.  The ideal compiler should be smart enough to create const
 std::string objects from the constant strings, and also to apply
 std::string::operator==() for the case tests.  Perhaps D could pull of
 what C++ never did. 
D also requires cases to be constant, but as a special case it allows to use char[] and wchar[] in switch: switch (args[1]) { case "-h": case "-?": ... case "-x": ... }
Aug 29 2002
prev sibling parent "anderson" <anderson firestar.com.au> writes:
Yes, less typing is good. I don't like mandatory bracketing {} though. I
think things get more complex when you provide to many ways of doing them.
If your going to use when, then () aren't needed I suppose. I think we need
to agree on one standard form.

Users of D would then be encourage to use "when". "case" would be used in
the rare occasions (like gotos are).

"C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message
news:akl2n5$39d$1 digitaldaemon.com...
 anderson wrote:

 switch (i)
 {
     select (1, 2, 3) //Auto non fall though
     case 6: //Normal
     default: //Normal
 }
That seems a good idea. However "select" may be better replaced by "when" as in Ada (less typeing). If a new keyword is used then the brackets would not really be needed, though it would make little difference, to me, wether they were included
or
 not.

 mandatory example...

 switch(i) {
         when(1,2,3) {   /* auto break - recommended */ }
         case 6:         /* standard C */
         default:                /* standard C */
 }

 or

 switch(i) {
         when 1,2,3:     /* auto break - recommended */
         case 6:         /* standard C */
         default:                /* standard C */
 }

 C 2002/8/29
Aug 30 2002
prev sibling parent reply C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
Just to sum up where we are so far...
(my comments are in square brackets []) (please refer to ajoined
thread for original contributers of various ideas)

(0)     something needs to be done about errors caused by
        default fall though behaviour in switch statements
(1)     switch statement should be compatible with C switch statement
(1a)    case should always be fall through [backward compatibility]
(1b)    fallthough statement just adds extra typeing resulting in little
        gain for experienced users. [seems people do not like this idea]
(1c)    case <x> {} is easily mixed up with case <x>: {} and therefore
        that syntax is no good. [idea withdrawn]
(2)     a new keyword ['when' seems good - here after refered to as
        when? to signify the actual keyword has not been decided]
        should be added which exibits default break behaviour
(2a)    'case' should be not recommended (but present where
        fallthough is needed - and for porting C apps) similar to goto.
(2b)    when? should be recommended.
(2c)    when? format syntax should be easy to add to the current
        compiler with out to much effort [though having not seen the
        compiler internals this is only a guess].
(3)     enhanced case & when? statements
(3a)    support for other constant types (D supports strings currently)
(3b)    multiple options (case 1,5,9:)
(3c)    ranged options (case 1..6:)
(3d)    variable options (case myVar:)  [I would not recommend
        this as I see a switch statement as a hint to the compiler that
        a lookup table may be a good optimisation in this situation -
        variable options prevent such a table being constructed and
        the 'else if' construct is often suitable for this case]

Not discussed / or discussed in other threads.
(4)     automatic 'default: assert;' where default is ommited
        [seems a good idea - I think D already does this].
(5)     break; and continue; should continue to operate in same way
        as in C - as break aLabel; and continue aLabel; can be used
        when different behaviour is required - an should probably be
        recommended as they are far clearer.
(5a)    aLbl: switch(..){ .. continue aLbl; .. } could be useful for
        implementing state machines.
(5b)    continue; and break; behaviour slightly confusing in switch
        statements.

Comments please (especially from Walter - who has as yet not contributed to 
this thread).

C 2002/8/30
Aug 30 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
Something you guys have missed is that if you leave the existing behavior
for case:, you will also end up leaving the existing behavior for default:.
Adding a new when keyword won't fix everything.

I don't know which posts you've been reading but it seems that an awful lot
of the contributors don't want C compatibility.  C interoperability is nice.
But if I wanted to program in C, I'd program in C.

I suppose goto case would be better than fallthrough.

Sean

"C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message
news:akntei$4up$1 digitaldaemon.com...
 Just to sum up where we are so far...
 (my comments are in square brackets []) (please refer to ajoined
 thread for original contributers of various ideas)

 (0)     something needs to be done about errors caused by
         default fall though behaviour in switch statements
 (1)     switch statement should be compatible with C switch statement
 (1a)    case should always be fall through [backward compatibility]
 (1b)    fallthough statement just adds extra typeing resulting in little
         gain for experienced users. [seems people do not like this idea]
 (1c)    case <x> {} is easily mixed up with case <x>: {} and therefore
         that syntax is no good. [idea withdrawn]
 (2)     a new keyword ['when' seems good - here after refered to as
         when? to signify the actual keyword has not been decided]
         should be added which exibits default break behaviour
 (2a)    'case' should be not recommended (but present where
         fallthough is needed - and for porting C apps) similar to goto.
 (2b)    when? should be recommended.
 (2c)    when? format syntax should be easy to add to the current
         compiler with out to much effort [though having not seen the
         compiler internals this is only a guess].
 (3)     enhanced case & when? statements
 (3a)    support for other constant types (D supports strings currently)
 (3b)    multiple options (case 1,5,9:)
 (3c)    ranged options (case 1..6:)
 (3d)    variable options (case myVar:)  [I would not recommend
         this as I see a switch statement as a hint to the compiler that
         a lookup table may be a good optimisation in this situation -
         variable options prevent such a table being constructed and
         the 'else if' construct is often suitable for this case]

 Not discussed / or discussed in other threads.
 (4)     automatic 'default: assert;' where default is ommited
         [seems a good idea - I think D already does this].
 (5)     break; and continue; should continue to operate in same way
         as in C - as break aLabel; and continue aLabel; can be used
         when different behaviour is required - an should probably be
         recommended as they are far clearer.
 (5a)    aLbl: switch(..){ .. continue aLbl; .. } could be useful for
         implementing state machines.
 (5b)    continue; and break; behaviour slightly confusing in switch
         statements.

 Comments please (especially from Walter - who has as yet not contributed
to
 this thread).

 C 2002/8/30
Aug 30 2002
parent reply "anderson" <anderson firestar.com.au> writes:
Default should be recomended to be last, therefore there should be no
problem.

switch
{
    when 1,2,3:
        ...
    case 4:
        ...
    break;
    default:
        ...
    break; //put it in or out, it doesn't matter.
}

Would be be re-interperated by the compiler as:

switch
{
    case 1:
    case 2:
    case 3:
        ...
    break;
    case 4:
        ...
    break;
    default:
        ...
}

Note that a break could still be used in a when statement, such as in an if
statement for early exit.

switch
{
    when 1,2,3:
        if (error) break;
        ...
    case 4:
        ...
    break;
    default:
        ...
    break; //put it in or out, it doesn't matter.
}

Simply using a differn't word, and making things backwards compatable, will
reduce confusion.

It's also be nice if when supported ranges.

switch
{
    when 1..10:
    break;
    default:
};

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ako6oc$fb7$1 digitaldaemon.com...
 Something you guys have missed is that if you leave the existing behavior
 for case:, you will also end up leaving the existing behavior for
default:.
 Adding a new when keyword won't fix everything.

 I don't know which posts you've been reading but it seems that an awful
lot
 of the contributors don't want C compatibility.  C interoperability is
nice.
 But if I wanted to program in C, I'd program in C.

 I suppose goto case would be better than fallthrough.

 Sean

 "C.R.Chafer" <blackmarlin nospam.asean-mail.com> wrote in message
 news:akntei$4up$1 digitaldaemon.com...
 Just to sum up where we are so far...
 (my comments are in square brackets []) (please refer to ajoined
 thread for original contributers of various ideas)

 (0)     something needs to be done about errors caused by
         default fall though behaviour in switch statements
 (1)     switch statement should be compatible with C switch statement
 (1a)    case should always be fall through [backward compatibility]
 (1b)    fallthough statement just adds extra typeing resulting in little
         gain for experienced users. [seems people do not like this idea]
 (1c)    case <x> {} is easily mixed up with case <x>: {} and therefore
         that syntax is no good. [idea withdrawn]
 (2)     a new keyword ['when' seems good - here after refered to as
         when? to signify the actual keyword has not been decided]
         should be added which exibits default break behaviour
 (2a)    'case' should be not recommended (but present where
         fallthough is needed - and for porting C apps) similar to goto.
 (2b)    when? should be recommended.
 (2c)    when? format syntax should be easy to add to the current
         compiler with out to much effort [though having not seen the
         compiler internals this is only a guess].
 (3)     enhanced case & when? statements
 (3a)    support for other constant types (D supports strings currently)
 (3b)    multiple options (case 1,5,9:)
 (3c)    ranged options (case 1..6:)
 (3d)    variable options (case myVar:)  [I would not recommend
         this as I see a switch statement as a hint to the compiler that
         a lookup table may be a good optimisation in this situation -
         variable options prevent such a table being constructed and
         the 'else if' construct is often suitable for this case]

 Not discussed / or discussed in other threads.
 (4)     automatic 'default: assert;' where default is ommited
         [seems a good idea - I think D already does this].
 (5)     break; and continue; should continue to operate in same way
         as in C - as break aLabel; and continue aLabel; can be used
         when different behaviour is required - an should probably be
         recommended as they are far clearer.
 (5a)    aLbl: switch(..){ .. continue aLbl; .. } could be useful for
         implementing state machines.
 (5b)    continue; and break; behaviour slightly confusing in switch
         statements.

 Comments please (especially from Walter - who has as yet not contributed
to
 this thread).

 C 2002/8/30
Aug 31 2002
parent C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
anderson wrote:

 Default should be recomended to be last, therefore there should be no
 problem.
 
 switch
 {
     when 1,2,3:
         ...
     case 4:
         ...
     break;
     default:
         ...
     break; //put it in or out, it doesn't matter.
 }
 
 Would be be re-interperated by the compiler as:
 
 switch
 {
     case 1:
     case 2:
     case 3:
         ...
     break;
     case 4:
         ...
     break;
     default:
         ...
 }
 
 Note that a break could still be used in a when statement, such as in an
 if statement for early exit.
 
 switch
 {
     when 1,2,3:
         if (error) break;
         ...
     case 4:
         ...
     break;
     default:
         ...
     break; //put it in or out, it doesn't matter.
 }
That was exactly what I thought.
 Simply using a differn't word, and making things backwards compatable,
 will reduce confusion.
 
 It's also be nice if when supported ranges.
 
 switch
 {
     when 1..10:
     break;
     default:
 };
Yes, nice, though not required at the present time. However, the 'when' statement (in my opinion) should be included as soon as possible as it should solve one of the remaining potential bug causes in D. C 2002/8/31
Aug 31 2002