Extending switch for Pattern Matching

Natural scoping for binding variables

The following example illustrates the that “natural” scope of a binding variables is complex and not necessarily contiguous:

if (x matches Foo(var y)) { .. y .. }                 // OK
if (x matches Foo(var y)) { ... } else { .. y .. }    // not OK
if (x matches Foo(var y) && .. y ..) { ... }          // OK
if (x matches Foo(var y) || .. y ..) { ... }          // not OK
if (!(x matches Foo(var y)) && .. y .. ) { ... }      // not OK
if (!(x matches Foo(var y)) || .. y .. ) { ... }      // OK
if (!(x matches Foo(var y))) { ... } else { .. y .. } // OK
if (!(x matches Foo(var y))) { y } else { ... }       // not OK

The above cases are derived from a standard application of definite assignment rules; we’d like for a binding variable to be in scope wherever it is definitely assigned, to not be in scope wherever it is not definitely assigned, and for a binding variable to always be definitely unassigned at the point of its declaration.

We can construct a set of rules for the natural scope of these variables. To start with, we say that each expression e gives rise to two sets of binding variables, e.T and e.F, along with rules for when one or the other of these sets are included in the scope of a statement or expression, over all the expression forms. If not otherwise defined, e.T = e.F = {} — most expressions (including all current expression forms) make available no new bindings. We also define a set of binding variables to additionally be in scope for certain expressions or statements via the “include in” clauses below.

• If e is x matches P:

  e.T = { binding variables from P }
  e.F = { }

• If e is x && y:

  e.T = union(x.T, y.T)
  e.F = intersection(x.F, y.F)
  include x.T in y

• If e is x || y:

  e.T = intersection(x.T, y.T)
  e.F = union(x.F, y.F)
  include x.F in y

• If e is x ? y : z:

  e.T = union(intersect(y.T, z.T),
              intersect(x.T, z.T),
              intersect(x.F, y.T))
  e.F = union(intersect(y.F, z.F),
              intersect(x.T, z.F),
              intersect(x.F, y.F))
  include x.T in y
  include x.F in z

• If e is (x):

  e.T = x.T
  e.F = x.F

• If e is !x:

  e.T = x.F
  e.F = x.T

We can do the same for statement forms:

• For if (x) y else z:

  include x.T in y
  include x.F in z

• For if (x) return/throw; z

  include x.T in return/throw
  include x.F in z

• For while (x) y:

  include x.T in y

• For for (a; b; c) d:

  include b.T in c
  include b.T in d

• For switch (x) { ... case P: y; case Q: ... }

  include binding variables from P in y

Further, union and intersection should be limited to avoid conflicts. The union function should be a disjoint union: it is an error if any binding varible is present in both sets — otherwise, expressions like x matches Foo(var x) && y matches Bar(var x) would include two different variables called x in the same scope. Similarly, for intersect, it is an error if the same binding variable is present in both sets but with different types.

Guards, compound patterns, and continue

Nested patterns, such as:

case Point(0, 0):

express compound conditions; we’re testing that the target is a Point, and that both its x and y components match the constant pattern 0. While nested patterns are powerful, they have their limits; we can’t easily test for whether a point is, say, on the diagonal. We could express this with a guard:

case Point(var x, var y) && x == y:

Alternately, we could express compound conditions by pushing the subordinate test into the body, and permitting the continue control flow construct in switches, which would indicate we want to break out of the existing case arm, and resume matching at the next case label:

case Point(var x, var y):
    if (x != y)
        continue;

(Note that nested patterns desugar to guards, and guards desugar to continue, so we are likely to have to implement all these mechanisms internally anyway.)

Dead code

In some cases, the compiler may be able to prove that a case is unreachable, such as:

switch (x) {
    case Comparable c: ... break;
    case Integer i: // can't reach this
}

In these cases, the compiler will issue an error (just as with unreachable catch clauses.)

Mixing statements and expressions

While the common case with a switch expression is that the RHS of a case label is a single expression, occasionally the result may not be constructible in this way (or construction of the result might require side-effects, such as debugging output). Other languages usually handle this with block expressions; we can construct a limited form of block expression for use in expression switch by coopting the break keyword, as in these examples:

case String s -> {
    System.out.println("It's a string!");
    break s.toUpperCase();
}

case Flooble f -> {
    FloobleDescriptor fd = new FloobleDescriptor();
    fd.setFlooble(f);
    break fd;
}

There is some potential ambiguity between label-break and result-break here, but working these out is practical.

Throw expressions

It is not uncommon that one or more arms of a switch expression will result in a transfer-of-control operation, such as:

int size = switch (x) {
    case Collection c -> c.size();
    case String s -> s.length();
    default -> throw new IllegalArgumentException(...);
}

Even though throw is a statement, not an expression, the intent here is clear, so we want to allow throw (and possibly other transfer-of-control operations) in this context.

Targetless switch

In the theme of elevating switch as the generalization of the ternary conditional operator, we may also wish to allow a simplified form of switch where there is no switch target, and all case labels are boolean expressions:

String fizzbuzz(int n) {
    boolean byThree = n % 3 == 0;
    boolean byFive = n % 5 == 0;
    return switch {
        case byThree && byFive -> "fizzbuzz";
        case byThree -> "fizz";
        case byFive -> "buzz";
        default -> Integer.toString(n);
    }
}