Re: [PROPOSAL]Support conditional return

2020-07-26 Thread Jochen Theodorou
On 26.07.20 20:23, Daniel Sun wrote: Hi mg, maybe you can give some real life code where you encounter this on a regular basis ? Let's think about the case about choosing method by method name and arguments: ``` def chooseMethod(String methodName, Object[] arguments) { def methodChosen

Re: [PROPOSAL]Support conditional return

2020-07-26 Thread Keegan Witt
> Second, WRT the syntax of Kotlin, it mixes the expressions and statements. But Groovy extends the design of Java, which does not support the mixing. I wasn't saying we should support that because Kotlin does. I'm saying because we *won't* support both usages, it makes it feel more out of

Re: [PROPOSAL]Support conditional return

2020-07-26 Thread Mikko Värri
I'm leaning towards +1 for the simpler cases, but referencing earlier (labeled) return expression values via `label._` syntax... doesn't feel like Groovy anymore, IMHO. OTOH, just because I wouldn't use it doesn't mean it's a bad idea. So, if I've understood the proposal, I'd limit it to: *

Re: [PROPOSAL]Support conditional return

2020-07-26 Thread Daniel Sun
Hi Keegan, First, maybe we could use `$` instead of `_` to represent the return value, e.g. ``` return callA() if $ > 5 ``` Second, WRT the syntax of Kotlin, it mixes the expressions and statements. But Groovy extends the design of Java, which does not support the mixing.

Re: [PROPOSAL]Support conditional return

2020-07-26 Thread Daniel Sun
Hi mg, > maybe you can give some real life code where you encounter this on a regular > basis ? Let's think about the case about choosing method by method name and arguments: ``` def chooseMethod(String methodName, Object[] arguments) { def methodChosen = doChooseMethod(methodName,

Re: [PROPOSAL]Support conditional return

2020-07-26 Thread Keegan Witt
For context, here's a summary of a discussion we had outside this thread. Like MG, I mostly use multiple returns for early bailouts of the method, and only occasionally otherwise where it adds additional readability. I don't find the standard Java-like syntax for your use case overly-cumbersome,

Re: [PROPOSAL]Support conditional return

2020-07-26 Thread Daniel Sun
Reference other return value with the following syntax: ``` returnA: return callA() if _ > 5 return callB() if _ > 10 && returnA._ > 1 ``` Cheers, Daniel Sun On 2020/07/25 19:57:16, Daniel Sun wrote: > Or a more verbose version: > > ``` > return callB() if (r -> r > 10) > ``` > > Cheers, >

Re: [PROPOSAL]Support conditional return

2020-07-26 Thread MG
Hi Daniel, currently I would be +/- 0 on this. Thoughts: 1. I feel I have written this before, but I myself do not encounter the situation where I would need to return the result of a method call only if it meets certain conditions when programming (maybe you can give some real life

Re: [PROPOSAL]Support conditional return

2020-07-26 Thread Daniel Sun
Hi Mario, > Once said that, I would say this conditional return could be useful only > when there are more than two exit points, otherwise ternary or elvis > operators may be good enough. Actually even if there are only two exit points, ternary or elvis operators are hard to meet all our

Re: [PROPOSAL]Support conditional return

2020-07-26 Thread Daniel Sun
Hi Mario, I think you have got the point of the proposal ;-) If we prefer the verbose but clear syntax, I think we could introduce `_` to represent the return value for concise shape: ``` return callB() if (_ != null && _ > 10) // The following code is like lambda expression, which is

Re: [PROPOSAL]Support conditional return

2020-07-26 Thread Mario Garcia
Hi all: Very interesting topic. The first idea sprang to mind was the PMD rule in Java saying you should have more than one exit point in your methods ( https://pmd.github.io/latest/pmd_rules_java_codestyle.html#onlyonereturn). But the reality is that sometimes (more often than not) we are