PROPOSAL: Multiple switch expressions and case ranges

[Pinku Surana]

Updated: Added relevant bug id. Added support for sequences within
ranges. More info on how to compile this feature.

Maybe this should be split into two proposals? (1) case ranges and (2)
multiple switch expressions.


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 CaseExpression [, CaseExpression]* :
      default :

  CaseExpression:
      _
      ConstantExpression
      EnumConstantName
      [ CaseRanges ]

  CaseRanges
      CaseRange
      CaseRanges , CaseRange

  CaseRange
      ConstantExpression
      EnumConstantName
      ConstantExpression .. ConstantExpression
      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:

The implementation for these two features is similar to that of switch
in any optimizing compiler. There are two popular implementations for
switch: jump tables (JT) and branching search (BS). This high-level
switch statement must be "lowered" to a combination of JT and BS,
either implementing them manually and/or using the switch bytecode where
appropriate.

First, case ranges are a simple extension because it gives the
compiler an easily recognizable dense region of constants. If that
range is small enough (ask the JIT guys), then use the switch bytecode
so the JIT will generate an efficient JT. If the range is large and
the JIT would have done BS anyway, implement the range checks using
standard BS techniques. These techniques have been around for over 30
years.

Second, multiple switch expressions are a bit more complicated, but
the implementation has existed in pattern matcher compilers for
functional languages for over 20 years. In fact, this will be much
simpler because it only supports constants. Basically, the compiler
builds a decision tree where the case constant/ranges are at the
leaves. Then it merges redundant checks and generates BS code and/or
uses the switch bytecode to get the JIT to implement a JT.


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 package com.sun.source.tree 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.

4269827
I couldn't find any RFEs for multiple switch expressions.

URL FOR PROTOTYPE (optional):

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