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

[Maurizio Cimadamore]

On Fri, 28 Apr 2023 16:56:34 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> 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?

I guess what I'm kind of questioning is: why are we using `_` for the variable name?  The way I see it is that `_` is a token that is used to say "I don't want to specify a name". So the program element declared using `_` becomes effectively "unnamed" (as the JEP says). This would be consistent with looking for `_` in the parser, and then replace them with `names.empty` - which would then be consistent with the rest of the compiler (as you wouldn't need to filter out things). Or, is there a concrete use case where keeping the `_` around is useful?

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

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