Hi David,
thank you for the Rust example. The "Ok" and "Err" are special
constructs, right - interesting, though I am not convinced...
Leaving Groovy loop constructs would be possible, if their closure
argument would be inlined (same as a regular for or if block), which
would support break/return/continue:
https://issues.apache.org/jira/browse/GROOVY-8301 :-)
Cheers,
mg
On 22.03.2018 00:06, David Dawson wrote:
In rust, the generally promoted style is to not use returns if you can
avoid it, and have the final expression in a particular block
evaluated for the return.
You can do returns in a flow control expression, in which case the
surrounding block is returned (the function, say).
From the rust docs, slightly cut down, ignore the lifetime gubbins.
This parses a number from a string, if the parse fails, it returns
Err, if it succeeds, it does a multiply and returns the value.
fn multiply(first_number_str: &str) -> Result<i32, ParseIntError> {
let first_number = match first_number_str.parse::<i32>() {
Ok(first_number) => first_number,
Err(e) => *return Err(e)*,
};
Ok(first_number * 5)
}
If the second branch in the match expression is invoked, the method
will return. Otherwise, you get the Ok.
I _/think/_ this feels natural, but I suspect thats more that I've
just used it like this.
That said, I have sometimes found myself reading the Groovy docs
asking the question "how can I do an early punch out of this .each{}?"
On 21 March 2018 at 21:47, MG <[email protected]
<mailto:[email protected]>> wrote:
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, [email protected]
<mailto:[email protected]> 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:[email protected]]
*Sent:* Wednesday, March 21, 2018 4:03 PM
*To:* [email protected] <mailto:[email protected]>
*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 ?
