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

Vicente Romero vromero at openjdk.org
Sun Nov 6 21:40:21 UTC 2022


On Tue, 1 Nov 2022 08:18:22 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 ten additional commits since the last revision:
> 
>  - Simplify getDeclarationKind
>  - Adjustments to make for-patterns and JDK-8294942 work together.
>  - Merge remote-tracking branch 'lahodaj/JDK-8294942' into for-patterns
>  - Address Review
>  - Fix applicability bug
>  - Store element type calculation result in JCEnhancedForLoop
>  - API cleanup.
>  - Adding @since, adding PreviewFeature, restoring API method.
>  - 8294943: Implement record patterns in enhanced for

src/jdk.compiler/share/classes/com/sun/source/tree/EnhancedForLoopTree.java line 94:

> 92:      * @since 20
> 93:      */
> 94:     @PreviewFeature(feature=PreviewFeature.Feature.RECORD_PATTERNS, reflective=true)

same issue mentioned above with the javadoc comment

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1560:

> 1558:                 attribStat(tree.body, loopEnv);
> 1559:             }
> 1560:             else if (tree.varOrRecordPattern instanceof JCRecordPattern jcRecordPattern) {

nit: suggestion, consider moving this line up kind of:

        } else if (...

also I wonder about the need for the `if` here as I think that the there is only one option here right?

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

> 1214:         public JCExpression expr;
> 1215:         public JCStatement body;
> 1216:         public Type elementType;

is this new field strictly necessary? usually we try not to add new fields to ASTs unless we don't have any other option as they will imply more memory consumption.

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

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


More information about the compiler-dev mailing list