JDK-8304401 : Compiler Implementation for Record Patterns
  • Type: CSR
  • Component: tools
  • Sub-Component: javac
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 21
  • Submitted: 2023-03-17
  • Updated: 2023-05-18
  • Resolved: 2023-05-18
Related Reports
CSR :  
JDK-8300545 - Compiler Implementation for Record Patterns
Relates :  
JDK-8294944 - Compiler implementation for Record Patterns (Second Preview)
Relates :  
JDK-8284529 - Compiler implementation for Record Patterns
Description
Summary
-------

Based on experiences with the several rounds of preview of record patterns, we propose a reduction in the feature. We also propose to make the feature final and permanent.

Problem
-------

We've identified that the record patterns in enhanced for loops, introduced in the previous round of preview, may need a significant redesign, to better align with other features under consideration. The rest of the record patterns feature is, however, well vetted. We therefore propose to drop the record patterns in enhanced for loops sub-feature, and finalize the record patterns feature without this sub-feature.

The rules for exhaustiveness of switch statements and expressions in presence of record patterns were found to not be sufficient. A new set of rules for exhaustiveness is being proposed as a solution to this problem.

Solution
--------

The record patterns in enhanced for loops sub-feature will be dropped from:

 - the specification
 - the javac implementation
 - the Trees API. The relevant `EnhancedForLoopTree.getVariableOrRecordPattern`, `EnhancedForLoopTree.getDeclarationKind` and `InstanceOfTree.getTestKind` methods and `EnhancedForLoopTree.DeclarationKind` and `InstanceOfTree.TestKind` enums are marked as preview API, and therefore can be removed.

The exhaustivity rules for switches in presence of record patterns will be enhanced. Please see CSR JDK-8304394 for more details.

The rest of the record patterns feature will be made final and permanent.

Specification
-------------

The specification draft is available for convenience [here](https://cr.openjdk.org/~gbierman/jep440%2B441/jep440%2B441-20230509/specs/patterns-switch-record-patterns-jls.html) and is attached as" 20230509 Pattern Matching for switch and Record Patterns.pdf". Please note that, for technical reasons, the specification draft also includes changes for JEP-441 (https://openjdk.org/jeps/441), which are reviewed under CSR JDK-8304394.

The specdiff of API changes is available [here](https://cr.openjdk.org/~jlahoda/8300543/specdiff.00/overview-summary.html) and is attached as specdiff.00.zip. Please note that, for technical reasons, the specdiff also includes changes for JEP-441 (https://openjdk.org/jeps/441), which are reviewed under CSR JDK-8304394.

The feature will be made final and permanent.
Comments
Moving updated request to Approved.
18-05-2023
[~darcy] Updated spec uploaded
18-05-2023
Moving back to Provisional pending resolution of the type annotations question.
12-05-2023
A few observations/questions: * Consider an enum type two constants A and B a switch statement like the following is accepted: > Letter letter = Letter.A; > switch(letter) { > case A -> System.out.println("A"); > case B -> System.out.println("B"); > default -> System.out.println("Unexpected"); > } *At compile time*, the default case is strictly speaking unreachable because the switch is exhaustive without the default. (The default case could be reachable at runtime if the enum evolved to have an additional constant after compilation, etc. as discussed in chapter 13.) I think this is the desired behavior, but I wasn't sure the spec mandated it. * Are there any updates needed for type annotations and patterns, such as the JVMS tables Table 4.7.20*? Code like > if (o instanceof @TypeAnnotation Complex(double r, double i)) { > System.out.println(r + " + " + i + "i"); > } where TypeAnnotation is declared to have runtime retention doesn't generate any RuntimeVisbleTypeAnnotation attribute in the resulting class file.
12-05-2023
Re: enums. We do not require a default, but you can give one. (If you don't then the compiler implicitly adds one with a throw. This is how we implement the operational semantics given in 14.11.3.) In 14.11.1.1 we give almost the same example code, and state "Note this means that a default label is permitted, but not required in the case where all the enum constants appear as case constants."
12-05-2023
I've uploaded the specdiff as per the current PR, and Finalized the request. Looking forward to any feedback!
10-05-2023
[~gbierman], from a process perspective, is this CSR ready to be Finalized? Thanks.
09-05-2023
[~darcy] I uploaded the latest spec. Two main changes: 1. An improved treatment of type inference for record patterns. This is already implemented in the compiler. 2. Removed any patterns and the process of resolving patterns in favour of a compile-time property of type patterns. (This is a purely specification improvement and has no semantic content.) Hopefully makes the spec more readable.
09-05-2023
Moving to Provisional.
12-04-2023