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 <mg...@arscreat.com> 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, 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 <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 ?
>
>
>
>
>
