I am using the statically imported method
static <T> T eval(final Closure<T> cls) { cls() }
right now for this.
This works well, and just has the performance drawback that it is based
on closures. Return here of course leaves the closure, so effectively
returns from the eval method.
Should Groovy natively support if-expressions or something like this,
the return keyword is the big question mark here for me: Should it leave
the expression, or the surrounding method ?
Maybe if a construct is used as an expression, it should follow closure
semantics, and return should leave the expression, whereas otherwise
(e.g. for potential future "inline closures" not used as expressions,
for instance a SQL forEach loop construct) it should leave the
surrounding method ?
On 21.03.2018 22:08, eric.mil...@thomsonreuters.com wrote:
I think you could experiment with this using a closure, since return
statements have this expression property already:
final foo = ({ ->
if(...) { ... }
else if(...) { ... }
else if(...) { ... }
else { ... }
}())
*From:*mg [mailto:mg...@arscreat.com]
*Sent:* Wednesday, March 21, 2018 4:03 PM
*To:* dev@groovy.apache.org
*Subject:* Re: [RFE] Methods as expressions
Having control flow statements as expressions in Groovy would feel
pretty natural to me. I had always assumed there were reasons why this
was not supported, so I did not bring it up...
I currently use the simulated eval language extension I proposed for
that, i.e.
final foo = eval {
if(...) { ... }
else if(...) { ... }
else if(...) { ... }
else { ... }
}
in cases where using "?" would be too complex.
That uses a closure, of course, so not optimal for all applications.
Question: Does a return-statement inside the if-expression leave the
expression, or the enclosing method in Rust ?
