> 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 place to me (but Kotlin is the only place I've seen a trailing if like that, so maybe that's biasing my opinion). It feels like new syntax for just one specific use case.
-Keegan On Sun, Jul 26, 2020 at 8:50 PM Mikko Värri <mi...@varri.fi> wrote: > 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: > > * extend return statement to include form `return <expr1> if (<expr2>)` > * the parentheses around <expr2> are optional > * the <expr1> is evaluated first > * the <expr2> can reference the value of <expr1> via an implicit variable > * include short form `return? <expr1>` > > Earlier emails talked about supporting full closure syntax for <expr2>. > Is this still included? If so, the implicit variable would naturally be > the closure parameter (`it` usually). Would it make sense to use the `it` > name even in "plain expression" form, instead of `_` or `$`? To me, `_` > denotes an ignored parameter, and `$` looks like something internal added > by some AST transform. > > Is the short form short for avoiding null return value, or short for > Groovy truthiness check? All the use cases shown are for the former, but > it feels like the latter (b/c it is short for an if clause). > > -mikko > >
