[
https://issues.apache.org/jira/browse/GROOVY-10943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-10943:
-------------------------------
Description:
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.
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]
was:
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.
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}
[1] [https://openjdk.org/jeps/302]
> Consider additional use of _ as a placeholder
> ---------------------------------------------
>
> Key: GROOVY-10943
> URL: https://issues.apache.org/jira/browse/GROOVY-10943
> Project: Groovy
> Issue Type: Dependency upgrade
> 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.
> 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)
