From: dfoster@jarthur.claremont.edu (Derek R. Foster)
Subject: Re: Proposal - enhancement for switch statement.
Organization: Harvey Mudd College, Claremont, CA 91711
Date: Mon, 16 Nov 1992 00:45:58 GMT

In article <MCGRANT.92Nov15132747@rascals.stanford.edu> mcgrant@rascals.stanford.edu (Michael C. Grant) writes:
>In article <1992Nov15.190830.11622@cssc-syd.tansu.com.au>
>pete@cssc-syd.tansu.com.au (Peter Alexander Merel) writes:
>   Before I describe what occurred to me, yes folks I know that a switch is not
>   as useful as a virtual function.
>   But what I'd like for a snippet I'm working on at the moment would be for
>   switch to use operator== rather than relying on conversion to int, so that 
>   I could use it to test cases on objects rather than building an industrial 
>   strength if statement. 
...
>   Any chance?
>
>I doubt it... Even before C++ came along, switch statements could not
>handle floats, strings, structures, etc. Sure, a switch statement could
>be turned into a set of if-then-else statements, but it isn't because
>it usually is best turned into a jump table.

Personally, I would like to see a few more changes made to the 'switch'
statement (in my opinion, one of the ugliest warts on the face of the
C language, and regrettably C++ also.)

I wouldn't advise actually getting rid of the 'switch' statement (it is
needed for backwards compatibility), but instead creating a (somewhat) 
parallel statement, called, say, 'switchc'. The purposes of 'switchc' would be:

  1) Remove the requirement for a 'break' after each statement (the accidental
     omission of which is the cause of a ridiculously large number of errors
     within C programs.) Make a 'break' the default, rather than fallthrough
     being the default. Add a 'fallthrough' keyword (or extend the
     meaning of the 'continue' keyword perhaps?) to still allow programmers
     to use fallthrough in those rare occasions for which it is necessary/
     desirable.

  2) Allow multiple labels for each 'case' statement, and extend the case
     statement to allow ranges and multiple arguments (as in Pascal.) This
     avoids the excessively verbose lists of 'case' statements that are
     necessary in C to represent ranges of values.

as per Peter's suggestion, we could easily add...

  3) for class-typed switching variables, we could require that 'switchc' 
     use operator == and a simple linear search to work its way down the
     list. (yes, this is possibly inefficient. It is, however, extremely
     clear code which is easy to read.) In the case of non-class-typed
     switching variables, the compiler is allowed to use a jump table,
     binary search, or whatever seems appropriate.
  4) in implementing 3, we could allow, for class typed variables, the
     switch labels to be any data type for which operator == with the
     given class type is defined. For instance, char *'s, floating point
     values, (references to const objects?,) etc.

     thus, code like:
       int x;
       switch(x)
       {
         case '1': case '2': case '3': case '4': case '5': case '6':
         case '7': case '8': case '9': case '0': 
           cout << "x is a digit\n";
         case 'A':
           cout << "x is a digit or the letter 'A'\n"; 
           break;
         default:
           cout << "x is not a digit or the letter 'A'\n";
       }
     could also be written:
       switchc(x)
       {
         case 0...9: cout << "x is a digit\n"; fallthrough;
         case 'A':   cout << "x is a digit or the letter 'A'\n;
         default:    cout << "x is not a digit or the letter 'A'\n";
       }

    also, consider the possibility of code like:

      String command;
      cin >> command;
      switchc(command)
      {
        case "DIR":          do_directory();
        case "VIEW":         do_view();
        case "QUIT","EXIT":  do_exit();
        default: cerr << "Unknown command!";
      }
    If the above code is written using 'if's, it is a) much harder to
    read, b) much harder to understand (the reader may not immediately
    see the overall structure), and c) more error-prone (it is possible to
    get mismatched 'else's, etc. which will compile fine, but not do
    what they're supposed to.

    I would LOVE to see the addition of something like this to the language.
    Control flow in many of my programs would be vastly simplified, and I
    think the number of errors I would make would be substantially smaller.

>I wouldn't object to such an addition in principle, except for the fact
>that it's unnecessary (a big objection for sure).

C++ is unnecessary. It's there because it makes programs easier to understand,
and because it reduces programming errors. Those seem like good reasons to me.
I think this extension satisfies those goals as well.

>Michael C. Ggrant

Derek Riippa Foster