RFR: 8294943: Implement record patterns in enhanced for [v4]

Vicente Romero vromero at openjdk.org
Mon Oct 31 21:01:22 UTC 2022


On Mon, 31 Oct 2022 14:55:08 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR enables the ability to use record patterns in the enhanced-for, initializing the record components accordingly: 
>> 
>> 
>> record Complex(double real, double img) {}
>> 
>> List<Complex> list = ...;
>> 
>> for (Complex(var real, var img) : list) {
>>     // can use “real” and “img” directly
>> }
>> 
>> 
>> This PR proposes an implementation for the "Record Patterns in Enhanced For" [subtask](https://bugs.openjdk.org/browse/JDK-8294943) regarding the following [CSR](https://bugs.openjdk.org/browse/JDK-8294944) (note the different JBS entries), summarised by the following:
>> 
>> - It enhances the grammar for the `EnhancedForStatement` to support record patterns too, alongside `LocalVariableDeclarations`.
>> - Any pattern variables introduced by the record pattern in the header of the pattern are definitely matched in the statement block of the enhanced for. 
>> - The record patterns are only permitted when the pattern is exhaustive over the enhanced for's expression.
>> - In the case that the element of the iteration is `null`, the switch raises a `MatchException` wrapping the `NullPointerException`.
>> - The enhanced for, supports record patterns for both arrays and reference types.
>> 
>> Currently, the precise meaning of the enhanced for statement is given by translation into a basic for statement. By introducing record patterns in the pattern header, the new meaning is defined by the new translation which incorporates a switch whose selector expression is the enhanced for's expression, and whose singleton case has the given record pattern as a sole label would be exhaustive. Note, that in cases where the imaginary switch would reach the default clause and end abruptly, the enhanced for each will end abruptly for the same reason.
>> 
>> For more information on the changes please see:
>> 
>> - the JEP: [JEP 432](https://openjdk.org/jeps/432) 
>> - the CSR: [JEP 432 - JDK-8294944](https://bugs.openjdk.org/browse/JDK-8294944) 
>> - the current [specification draft](https://cr.openjdk.java.net/~gbierman/jep432%2b433/jep432+433-20221018/specs/patterns-switch-record-patterns-jls.html#jls-14.14.2) 
>> 
>> Looking forward for your review.
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Adjustments to make for-patterns and JDK-8294942 work together.
>  - Merge remote-tracking branch 'lahodaj/JDK-8294942' into for-patterns
>  - Fixing test.
>  - Cleanup.
>  - Some more cleanup.
>  - Various cleanup and adjustments to specification updates.
>  - 8294942: Compiler implementation for Record Patterns (Second Preview)
>  - Address Review
>  - Fix applicability bug
>  - Store element type calculation result in JCEnhancedForLoop
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/f1323c33...892fddf3

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java line 1248:

> 1246:         @Override @DefinedBy(Api.COMPILER_TREE)
> 1247:         public EnhancedForLoopTree.DeclarationKind getDeclarationKind() {
> 1248:             if (varOrRecordPattern instanceof JCVariableDecl) {

probably better to use `JCTree::hasTag` instead of `instanceof`?

-------------

PR: https://git.openjdk.org/jdk/pull/10798


More information about the compiler-dev mailing list