[jira] [Commented] (GROOVY-10943) Consider additional use of _ as a placeholder

[ASF GitHub Bot (Jira)]

    [ 
https://issues.apache.org/jira/browse/GROOVY-10943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695805#comment-17695805
 ] 

ASF GitHub Bot commented on GROOVY-10943:
-----------------------------------------

sonatype-lift[bot] commented on PR #1867:
URL: https://github.com/apache/groovy/pull/1867#issuecomment-1452138594

   ## 🛠 Lift Auto-fix
   Some of the Lift findings in this PR can be automatically fixed. You can 
download and apply these changes in your local project directory of your branch 
to review the suggestions before committing.[^1]
   ```bash
   # Download the patch
   curl https://lift.sonatype.com/api/patch/github.com/apache/groovy/1867.diff 
-o lift-autofixes.diff
   
   # Apply the patch with git
   git apply lift-autofixes.diff
   
   # Review the changes
   git diff
   ```
   Want it all in a single command? Open a terminal in your project's directory 
and copy and paste the following command:
   ```bash
   curl https://lift.sonatype.com/api/patch/github.com/apache/groovy/1867.diff 
| git apply
   ```
   Once you're satisfied, commit and push your changes in your project.
   [^1]: You can preview the patch by opening the [patch 
URL](https://lift.sonatype.com/api/patch/github.com/apache/groovy/1867.diff) in 
the browser.




> Consider additional use of _ as a placeholder
> ---------------------------------------------
>
>                 Key: GROOVY-10943
>                 URL: https://issues.apache.org/jira/browse/GROOVY-10943
>             Project: Groovy
>          Issue Type: Improvement
>            Reporter: Paul King
>            Priority: Major
>              Labels: GEP
>
> Recent Java versions make underscore, "_", an illegal variable name. This is 
> to allow it to be used as a placeholder as per JEP 302: Lambda Leftovers[1]. 
> This issue is to explore how better to have such a placeholder in Groovy.
> This strengthens an informal convention already in use. Instead of writing 
> this:
> {code}
> def (coordX, coordY, unusedZ) = coord3D()
> {code}
> Sometimes it is written as:
> {code}
> def (coordX, coordY, _) = coord3D()
> {code}
> Currently, the underscore is a variable and could be used but the convention 
> is that
> it would be ignored.
> This convention doesn't scale if more than one result is to be ignored (here 
> a double underscore is used for the second ignored result):
> {code}
> def (coordX, coordY, _, __) = coord3DwithColor()
> {code}
> This idea being that the following should be valid:
> {code}
> def (coordX, coordY, _, _) = coord3DwithColor()
> {code}
> Which currently gives an error for the duplicated variable name.
> Another example:
> {code}
> def (x, _, y, _, z) = 1..5
> assert "$x $y $z" == '1 3 5'
> {code}
> Similarly, the idea is applicable for lambda parameters (as per the example 
> in the previously mentioned Java JEP):
> {code}
> BiFunction<Integer, String, String> biss = (i, _) -> String.valueOf(i)
> {code}
> We could follow Java's lead and make underscore an invalid variable name but 
> it might be possible to keep uses of that name except where there is more 
> than one occurrence of the name. In such a circumstance, use of the name 
> would no longer reference a variable. We need to check the impacts of 
> shadowing as per discussions in the JEP.
>  [1] [https://openjdk.org/jeps/302]
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)