sorry, Result is an enum that "Ok" and "Err" are members of.
On 22 March 2018 at 00:18, MG <mg...@arscreat.com> wrote: > 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 <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 ? >> >> >> >> >> > >
