• Chris Friesen <chris_friesen sympatico.ca> Aug 16 2001
• Mark Shackelford <mark shackelford-family.org> Aug 17 2001
• "Walter" <walter digitalmars.com> Aug 18 2001
• Axel Kittenberger <axel dtone.org> Aug 18 2001
• Russell Bornschlegel <kaleja estarcion.com> Aug 18 2001

Chris Friesen <chris_friesen sympatico.ca> writes:

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.

Mark Shackelford <mark shackelford-family.org> writes:

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.

"Walter" <walter digitalmars.com> writes:

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 no


from Walter. I don't think he's interested in fixing the horribly ugly C


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




 for the case expressions in a switch statement?  The code could look




 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.

Axel Kittenberger <axel dtone.org> writes:

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.

Russell Bornschlegel <kaleja estarcion.com> writes:

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