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.

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.

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
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.
>

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.

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