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