Hi Jochen, On 16.02.2018 01:52, Jochen Theodorou wrote:
For me inline closures are not a no-brainer, not at all. just because their solution may look simple does not mean it was easy to develop or that it can be used for Groovy.
not being in any way used to thinking about how to extend/improve a computer language, it took me under 30min to arrive at the solution, which I later found Kotlin, it seemed, had already implemented (starting from my own implementation using exceptions, and the obvious other idea based on special return values (both ideas have been discussed for a long time by Groovy devs as I later learned)).
That makes it a no brainer to me, same as its benefits from a Groovy user's perspective: It is the fastest solution runtime wise, and has no surprising properties (caught exceptions, etc).
You are one of the experts on the implementation side, of course, and I am constantly surprised how many problems/side effects the implementation of the most innocent looking Groovy feature can have (a good learning experience to understand how a manager must feel when you try to explain to him that the seemingly small extension he envisions actually carries a lot of implementation effort, and also does not come free side effect wise). So the implementation side can easily be no no-brainer - but that does imho not make Kotlin a language with a language design that Groovy can learn from...
Cheers, mg
