PROPOSAL: Multiple switch expressions and case ranges

[Pinku Surana]

Has the switch statement in C languages evolved much since the '80s? I'm
envious of the case/match expression in functional languages and looking for
simple ways to make 'switch' more powerful.



AUTHOR(S): Pinku Surana

OVERVIEW

FEATURE SUMMARY:

Extend the switch statement to support multiple switch expressions and case
ranges.

MAJOR ADVANTAGE:

It is syntactic sugar that makes it easier to write/read complex
logic. This is one small aspect of the vastly more powerful match or
case expression in functional languages.

MAJOR BENEFIT:

Better readability for complex cases, and potentially better
performance relative to if statements.

MAJOR DISADVANTAGE:

Requires changes to compiler.

ALTERNATIVES:

It can currently be implemented with if statements.

EXAMPLES

Show us the code!

SIMPLE EXAMPLE: Show the simplest possible program utilizing the new
feature.

switch (c) {
  case ['a'..'z']: return "lower case" ;
  case ['A'..'Z']: return "upper case" ;
  default: return "something else" ;
}

ADVANCED EXAMPLE: Show advanced usage(s) of the feature.

switch (suit, value) {
  case [SPADE..CLUB],       [2..10]  : return "black low-value card" ;
  case [HEART..DIAMOND], [2..10]  : return "red low-value card" ;
  case _,                             [11..14]: return "face card" ;
}

DETAILS

SPECIFICATION: Describe how the proposal affects the grammar, type system,
and meaning of expressions and statements in the Java Programming Language
as well as any other known impacts.

* The lexer will need to support underscore ('_') and ".."
* The parser rules for switch statements must be changed.

  SwitchStatement:
      switch (Expression [, Expression]*) SwitchBlock

  SwitchLabel:
      case CaseExpressions :
      default :

  CaseExpressions:
      CaseExpression
      CaseExpressions , CaseExpression

  CaseExpression:
      _
      ConstantExpression
      [ ConstantExpression .. ConstantExpression ]
      EnumConstantName
      [ EnumConstantName .. EnumConstantName ]

* Semantic rules:
  - The number of CaseExpressions must equal the number of expressions in
the SwitchStatement
  - The underscore ('_') means "don't care"
  - In [ c1 .. c2], c1 should be less than c2
  - The types of the constants/enums must match the type of the expression
in the same position
  - If the range of constants/enums overlap between case arms, then raise an
error.

COMPILATION:

Simple desugaring transformations:

----------------------------------
     switch (e1, e2) {
       case C1, C2: stmt1 ;
       case C3, _: stmt2 ;
       default: stmt3 ;
     }
     ==>
     x = e1 ;
     y = e2 ;
     switch (x) {
       case C1: switch (y) {
                  case C2: stmt1 ;
                  case C4: stmt2 ;
                  default: stmt3 ;
                }
            break ;
       case C3: stmt2 ;
            break ;
       default: stmt3 ;
     }
-----------------------------------
     case [V1 .. Vn] : stmts ;
     ==>
     case V1:
     case V2:
     ...
     case Vn: stmts ;
-----------------------------------


Both of these could blow up in code size. Therefore, a better
implementation of the switch would compile down to gotos to the
correct statement block. This is why proper compiler support would be nice.

For case ranges, if the range is too big then turn into an if statement:
"if (x >= V1 && x <= V2)".


TESTING: How can the feature be tested?

Normal compiler testing.

LIBRARY SUPPORT: Are any supporting libraries needed for the feature?

None

REFLECTIVE APIS: Do any of the various and sundry reflection APIs need to be
updated? This list of reflective APIs includes but is not limited to core
reflection (java.lang.Class and java.lang.reflect.*), javax.lang.model.*,
the doclet API, and JPDA.

The reflection APIs will need to return a list of switch expressions
and case constants. Also, new expression nodes must be added for
ranges and for the "don't care" underscore.

OTHER CHANGES: Do any other parts of the platform need be updated too?
Possibilities include but are not limited to JNI, serialization, and output
of the javadoc tool.

Don't think so.

MIGRATION: Sketch how a code base could be converted, manually or
automatically, to use the new feature.

I think this would be difficult because the logic would be obscured in if
statements.

COMPATIBILITY

BREAKING CHANGES: Are any previously valid programs now invalid? If so, list
one.

None.

EXISTING PROGRAMS: How do source and class files of earlier platform
versions interact with the feature? Can any new overloadings occur? Can any
new overriding occur?

Should be backwards compatible.

REFERENCES

EXISTING BUGS: Please include a list of any existing Sun bug ids related to
this proposal.

URL FOR PROTOTYPE (optional):

If there's interest, I can cook up a prototype with Polyglot.