[ 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, in the groovy-parser project containing source code of some famous groovy projects, none of them are broken because of the proposed change. was: 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} > 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 > > 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, in the groovy-parser project containing source code of some famous > groovy projects, none of them are broken because of the proposed change. -- This message was sent by Atlassian Jira (v8.3.4#803005)