[
https://issues.apache.org/jira/browse/GROOVY-9484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Sun updated GROOVY-9484:
-------------------------------
Description:
Here is the issue reported by a Groovy 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]
was:
Here is the issue reported by a Groovy 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
> 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
> Priority: Major
> Labels: breaking_change
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Here is the issue reported by a Groovy 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)
