Hi Daniel, good to hear you seem to be well :-)
Maybe I am missing something, but right now I don't see where writing a standalone closure in the code would makes sense, since it is not assigned to anything, and its creation has no side effects (?)
The only application I can see is calling it immediately inline, which I have sometimes done in the past to do e.g. some if-then-else-cascade based calculations depending on parameters/variables from surrounding scope and assign the result to a final variable (without having to introduce a method). I have however switched to using a static eval method for that case, since it is much cleaner:
final x = { ... }.call() final x = eval { ... } with statically imported (trivial) eval method static <T> T eval(final Closure<T> cls) { cls() } Cheers, mg On 28/03/2020 04:06, Daniel.Sun wrote:
Hi all, Current groovy grammar of method call contains the following ambiguities, which are odd for users. For example, 1) method call with closure argument. That means the closure on the next line could be treated as argument of method `meth` ``` meth { p -> } ``` 2) binary expression and closure expression. That means the closure is not an argument. ``` a | meth { p -> } ``` I propose to unify the grammar of closure arguments: when closure follows method name directly, it is an argument, otherwise it is just standalone closure. For example, 3) method call with closure argument ``` meth { p -> } ``` 4) variable and closure ``` meth { p -> } ``` Luckily, groovy-parser project containing source code of some famous groovy projects, none of which are broken because of the proposed change[1]. Here is a JIRA ticket[2] to track the proposed change, and here is the PR[3] to implement the change. Any thoughts? Cheers, Daniel Sun [1] https://github.com/danielsun1106/groovy-parser/commits/GROOVY-9484 [2] https://issues.apache.org/jira/browse/GROOVY-9484 [3] https://github.com/apache/groovy/pull/1211 ----- Apache Groovy committer & PMC member Blog: http://blog.sunlan.me Twitter: @daniel_sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html