I’m against breaking changes and changing core concepts for so little gain.
Groovy has (x) to make x an expression. We could make that lexically scoped. Dierk sent from:mobile > Am 21.03.2018 um 01:53 schrieb MG <[email protected]>: > > Hi Daniel, > >> On 21.03.2018 01:33, Daniel Sun wrote: >> Parrot is smart enough to distinguish closure and code block, so >> `block` is not necessary. > > Under http://groovy-lang.org/releasenotes/groovy-3.0.html it says: > > "Be aware though that in Groovy having a code block looking structure after > any method call will be seen as an attempt to pass a closure as the last > parameter in the method call. This happens even after a new line. So it’s > safe to start an anonymous code block after any other block (e.g. an > if-then-else statement or another anonymous code block). Anywhere else and > you might need to terminate the previous statement with a semicolon. In which > case, see the note above about refactoring your code! :-)" > > If that is no longer true, it should be updated :-) > > Apart from that, as I said, "block" would make the semantic explicit. I > always found nested code blocks inelegant/error prone, so in C++ I used > #define block if(false) {} else > >> BTW, new keywords may break existing code ;) > > Yes, every new reserverd word / keword must be evaluated whether it is worth > introducing, also under this criteria. > >> >> As for `eval`, we can use `{ /* do something here */ }()` instead, e.g. >> `{ 'abc' }()` > > Yes, that is what I used to use. Now I am wrapping it in a statically > imported helper method, since the "()" at the end of the closure is > syntactically inelegant: > > static def eval(finalClosure cls) { cls() } > > eval { ... } > > But this creates a Closure instance, so it is inefficient. If Groovy had > "inline closure" support, I would use that, but since it looks like this is > still a long way off (if it ever comes - it was shot down a few years back > when someone else created a ticket for it), I suggest this special version of > it. > > Cheers, > mg > > > >
