Summary

Based on experiences with the preview of pattern matching for switch, we propose a few improvements and simplifications.

Problem

Two issues related to pattern matching for switch have been identified:

• The grammar for switch labels and their associated validity conditions are too complex. We propose to simplify both.

• The current specification of exhaustiveness of switch statements and expressions does not cover certain cases that are obviously exhaustive. The specification has been strengthened to cover these cases.

Solution

Updated Switch Labels

The previous specification allows several complex constructs:

• Nullable type patterns - for example the label case null, String s should match either the null value or a String, and in both cases the pattern variable s is initialized with the value. These add a lot of specification complexity, and have proved difficult for users to understand.

• The new default and null case labels can be combined in a number of ways with other labels. This adds a lot of specification complexity, and have proved difficult for users to understand.

• The default case does not need to be last in a pattern switch, which has generated negative feedback from users.

In this update, we propose the following:

• The support for case labels with null be simplified to just two new forms: case null and case null, default. They are not permitted in any other order and can not combine with any other case label, including type patterns.

• The dominance rules be updated to require a default label to appear last in the body of enhanced (new) switch statements and expressions.

  (Note that these dominance rules do not apply to switch statements and expressions that do use any of the new features.)

Exhaustive switch Statements and Expressions

A number of switch statements and expressions are currently not considered exhaustive, despite being obviously exhaustive. For example:

sealed interface I<T> {}
record R<T>(T t) implements I<T> {}

I<String> i = ...;

switch (i) {
     case R<String>(String s) -> {}  // Currently an error!
}

As currently specified, this is erroneously considered not exhaustive due to imprecise treatment of generic type arguments involving record patterns. The treatment of record patterns with generic types and the recursive analysis of their component patterns has been strengthened to deduce that switch blocks like the above are exhaustive.

Preview Status

The pattern matching for switch feature will continue to be a preview feature given its co-dependence on the record patterns feature.

Specification

The preliminary specification draft is available for convenience here: http://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432%2b433-20221028/specs/patterns-switch-record-patterns-jls.html and is attached as jls-jep432+433-20221028.zip. Please note that, for technical reasons, the specification draft also includes changes for JEP-432 (https://openjdk.org/jeps/432), which are reviewed under CSR JDK-8294944.

There are no API changes proposed under this CSR.