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