You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Paul King (Jira)" <ji...@apache.org> on 2023/02/25 03:45:00 UTC

[jira] [Comment Edited] (GROOVY-10943) Consider additional use of _ as a placeholder

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