D - Switch statement (again)
- C.R.Chafer (33/33) Aug 27 2002 Just because I like metaphorically beating dead horses...
- Suporte Internet (16/40) Aug 27 2002 Good idea !
- C.R.Chafer (11/27) Aug 27 2002 I think using labeled breaks for such a piece of code would be preferabl...
- Richard Krehbiel (21/45) Aug 27 2002 Look at subtle difference between
- C.R.Chafer (38/59) Aug 27 2002 That is why I recommend the compiler checks for this and disallows it (i...
- Mac Reiter (59/62) Aug 27 2002 Slightly off topic, but in C/C++, the
- C.R.Chafer (38/115) Aug 28 2002 Yes, though I know about this form I never use it - that is why I think ...
- Pavel Minayev (9/12) Aug 27 2002 'continue',
- Sean L. Palmer (6/9) Aug 27 2002 anyway -
- Joel Lucsy (12/21) Aug 27 2002 How about this in addition to:
- anderson (4/25) Aug 29 2002 I'm sorry I don't see much of an advantage here. Mite as well add a brak...
- anderson (17/17) Aug 29 2002 I apologise if this idea has already been mentioned. I'd like some form ...
- C.R.Chafer (19/25) Aug 29 2002 That seems a good idea. However "select" may be better replaced by "whe...
- Mark Evans (26/26) Aug 29 2002 Fallthrough is a sometimes-important feature for expert C programmers. ...
- Pavel Minayev (12/17) Aug 29 2002 D also requires cases to be constant, but as a special case it
- anderson (9/34) Aug 30 2002 Yes, less typing is good. I don't like mandatory bracketing {} though. I
- C.R.Chafer (43/43) Aug 30 2002 Just to sum up where we are so far...
- Sean L. Palmer (11/54) Aug 30 2002 Something you guys have missed is that if you leave the existing behavio...
- anderson (55/113) Aug 31 2002 Default should be recomended to be last, therefore there should be no
- C.R.Chafer (7/64) Aug 31 2002 Yes, nice, though not required at the present time.
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
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
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
"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
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; andI 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
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
Mac Reiter wrote: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.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 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... MacMe 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
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 beingable 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
"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 disallowedanyway -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
"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
"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: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.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 29 2002
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
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
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
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
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:orswitch (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 includednot. 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
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
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 contributedtothis thread). C 2002/8/30
Aug 30 2002
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 fordefault:.Adding a new when keyword won't fix everything. I don't know which posts you've been reading but it seems that an awfullotof the contributors don't want C compatibility. C interoperability isnice.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 contributedtothis thread). C 2002/8/30
Aug 31 2002
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