[jira] [Closed] (GROOVY-9484) Closure on the next line should not be treated as argument

["Daniel Sun (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GROOVY-9484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Sun closed GROOVY-9484.
------------------------------
    Resolution: Won't Fix

> Closure on the next line should not be treated as argument
> ----------------------------------------------------------
>
>                 Key: GROOVY-9484
>                 URL: https://issues.apache.org/jira/browse/GROOVY-9484
>             Project: Groovy
>          Issue Type: Bug
>            Reporter: Daniel Sun
>            Assignee: Daniel Sun
>            Priority: Major
>              Labels: breaking_change
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> Here is the issue reported by a Spock user:
> in groovy 2.5
> {code:java}
>  modification                                | expected
>  { Instant i, ZoneId z -> i.plusSeconds(1) } | defaultInstant.plusSeconds(1)
> {code}
> these were treated as separate expressions
>  in groovy 3.0 the closure gets merged as argument to the expected above.
> {code:java}
>  modification | this.expected({ Instant i, ZoneId z ->
>             i.plusSeconds(1)
>         }) | defaultInstant.plusSeconds(1)
> {code}
> I propose to unify the grammar of closure arguments:
> {code:java}
> // 2 expressions: variable and closure
> meth
> { p ->
> }
> // 2 expressions: binary expression and closure
> a | meth
> { p ->
> }
> {code}
> In the old grammar, the following code is parsed as method call with a closure argument.
> {code:java}
> meth
> { p ->
> }
> {code}
> Luckily, groovy-parser project containing source code of some famous groovy projects, none of which are broken because of the proposed change.
> See the discussion in the dev mailing list: [http://groovy.329449.n5.nabble.com/About-eliminating-ambiguities-of-method-call-with-closure-argument-tt5766830.html]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)