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

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

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


##########
src/main/java/org/apache/groovy/parser/antlr4/AstBuilder.java:
##########
@@ -3906,13 +3906,17 @@ private void validateParameterList(final 
List<Parameter> parameterList) {
         for (int n = parameterList.size(), i = n - 1; i >= 0; i -= 1) {
             Parameter parameter = parameterList.get(i);
 
+            String name = parameter.getName();
+            if ("_".equals(name)) {

Review Comment:
   <picture><img alt="8% of developers fix this issue" 
src="https://lift.sonatype.com/api/commentimage/fixrate/8/display.svg";></picture>
   
   <b>*[YodaCondition](https://errorprone.info/bugpattern/YodaCondition):</b>*  
The non-constant portion of an equals check generally comes first.
   
   ---
   
   
   ```suggestion
               if (Objects.equals(name, "_")) {
   ```
   
   
   ---
   
   <details><summary>ℹ️ Expand to see all <b>@sonatype-lift</b> 
commands</summary>
   
   You can reply with the following commands. For example, reply with 
***@sonatype-lift ignoreall*** to leave out all findings.
   | **Command** | **Usage** |
   | -----------

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

Reply via email to