[
https://issues.apache.org/jira/browse/GROOVY-10943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17692376#comment-17692376
]
Paul King edited comment on GROOVY-10943 at 2/25/23 3:45 AM:
-------------------------------------------------------------
Leaving off trailing components was perhaps not the best example, though you
could argue about which is clearer I guess.
I was mostly trying to cater for examples like this:
{code:java}
def (_, y, m, _, _, d) = Calendar.instance
println "Today is $y ${m+1} $d"
{code}
Similarly, there are numerous examples which Java will support (one day), so it
would be good to get ahead of the game rather than have to close the gap when a
future Java version supporting this feature is released.
One of the reasons in the JEP is improved possibilities for static type
checking. I haven't explored that yet.
I haven't explored pattern matching scenarios either.
was (Author: paulk):
Leaving off trailing components was perhaps not the best example, though you
could argue about which is clearer I guess.
I was mostly trying to cater for examples like this:
{code:java}
def (_, y, m, _, _, d) = Calendar.instance
println "Today is $y ${m+1} $d"
{code}
One of the reasons in the JEP is improved possibilities for static type
checking. I haven't explored that yet.
I haven't explored pattern matching scenarios either.
> 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)
