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