RFR: 8302344: Compiler Implementation for Unnamed patterns and variables (Preview) [v3]

[Aggelos Biboudis]

On Fri, 28 Apr 2023 09:17:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 278:
>> 
>>> 276: 
>>> 277:     /**
>>> 278:      * Flag that indicates that a local variable, a lambda parameter, or an unnamed pattern variable is unnamed.
>> 
>> question: cant we infer this from the name itself instead of consuming a flag?
>
> I have the same feeling. Flags are a scarce resource - if we can avoid using one that would be best :-)

Initially, the check was based on the name but that became confusing since the symbol may hold either the empty name or the underscore (coming from the tree) depending on whether we are in the new feature or not. The reason is that while the Tree API will continue to return (`_`), `VariableElement.getSimpleName()` needs to return `names.empty` ([JDK-8307007](https://bugs.openjdk.org/browse/JDK-8307007)).

Up until here, everything is ok, however adding the `isUnnamed` in the Symbol we cannot simply return a boolean based on simply checking the name. We would need to check the version again but this time in the Symbol (to take account whether or not we are in the Unnamed feature). 

Thus the flag seems cleaner. WDYT?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180629713