D - what about supporting ranges in switch/case statement?
- Chris Friesen (17/17) Aug 16 2001 To go along with your support of ranges in arrays, what about supporting...
- Mark Shackelford (9/26) Aug 17 2001 Hi Chris,
-
Walter
(12/40)
Aug 18 2001
Forgive me for not replying right away. I am buried
. I actually like... - Axel Kittenberger (15/15) Aug 18 2001 Do we really need that stupid breaks in switches???
- Russell Bornschlegel (22/43) Aug 18 2001 Is anything wrong with:
To go along with your support of ranges in arrays, what about supporting them for the case expressions in a switch statement? The code could look something like the following: switch(input) { case 'a'..'z': //do stuff break; case 'A'..'Z': //do other stuff break; default: //do default stuff break; } Since all the valid switch inputs are defined as being comparable in the language definition, this will work for strings too.
Aug 16 2001
Hi Chris, I also tried to address this in my post Thurs afternoon, also with no response from Walter. I don't think he's interested in fixing the horribly ugly C switch statement. Adding case ranges does seem like a straightforward improvement, though. Cheers! -- Mark Shackelford Chris Friesen wrote:To go along with your support of ranges in arrays, what about supporting them for the case expressions in a switch statement? The code could look something like the following: switch(input) { case 'a'..'z': //do stuff break; case 'A'..'Z': //do other stuff break; default: //do default stuff break; } Since all the valid switch inputs are defined as being comparable in the language definition, this will work for strings too.
Aug 17 2001
Forgive me for not replying right away. I am buried <g>. I actually like the horrible ugly C switch. One improvement in D is that if there is no default, then the compiler generates one for you that throws a SwitchException. Implementing case ranges is not quite trivial, because if the range is large the compiler can't generate a table lookup. So there is some fiddling around to make it work. -Walter Mark Shackelford wrote in message <3B7D6C7C.8346ABF2 shackelford-family.org>...Hi Chris, I also tried to address this in my post Thurs afternoon, also with noresponsefrom Walter. I don't think he's interested in fixing the horribly ugly Cswitchstatement. Adding case ranges does seem like a straightforward improvement, though. Cheers! -- Mark Shackelford Chris Friesen wrote:themTo go along with your support of ranges in arrays, what about supportingsomethingfor the case expressions in a switch statement? The code could looklike the following: switch(input) { case 'a'..'z': //do stuff break; case 'A'..'Z': //do other stuff break; default: //do default stuff break; } Since all the valid switch inputs are defined as being comparable in the language definition, this will work for strings too.
Aug 18 2001
Do we really need that stupid breaks in switches??? I think no. Do we need fall through? Yes, why not. But they can be archivied more easily. switch(expr) { case 'd': ..... case 'u': ..... continue switch; // makes a fall through. case 'l': ..... } That does not even introduce a new keyword. And with for an LALR parser I can tell it will create no new shift/reduce conflicts.
Aug 18 2001
Axel Kittenberger wrote:Do we really need that stupid breaks in switches??? I think no. Do we need fall through? Yes, why not. But they can be archivied more easily. switch(expr) { case 'd': ..... case 'u': ..... continue switch; // makes a fall through. case 'l': ..... } That does not even introduce a new keyword. And with for an LALR parser I can tell it will create no new shift/reduce conflicts.Is anything wrong with: goto case 'l'; Advantages: - Its meaning is blindingly obvious even to a BASIC programmer - It gives you the added flexibility of being able to do: case StartThisWay: do_something(); goto case ContinueCommonWay; case StartTheOtherWay: do_something_different(); goto case ContinueCommonWay; case ContinueCommonWay: do_the_common_part(); Personally, I used to be okay with the fall through behavior of C. If I wanted a fall-through, I'd even put in a big loud comment like this: // NOTE: INTENTIONAL FALL THROUGH Then one day I added a new case in the middle of the intended fall-through. I looked right past the big loud comment. That's enough for me; I don't want automatic fall through any more. -Russell B
Aug 18 2001