Hi Cedric, > De: "Cédric Champeau" <cedric.champ...@gmail.com> > À: dev@groovy.apache.org > Envoyé: Mercredi 19 Octobre 2016 09:09:51 > Objet: Re: Lambda expression for Groovy 3
> First of all, great work, Daniel ! I'm confident that making the "lambdas" be > "closures" in Groovy is enough. I stated it in the past but I'm going to > repeat > myself here, I don't think having 2 syntax for "closures/lambdas" with > slightly > different semantics would help our users/language. That said, the static > compiler can do better, doing escape analysis, and using "real" lambdas when > the target bytecode is 8, as an optimization. The main issue i see of having one semantics is that the meaning of 'this' in a Groovy closure means the closure itself while 'this' in a Java lambda means the enclosing object, so { -> this } in Groovy is a substitute to () -> this in Java. The choice seems to be, the semantics of 'this' in a lambda in Groovy can be either the same as Java so you can copy/paste a Java code and it will work as is in Groovy or the same semantics as in a Groovy closure so as you said you will not have to explain why in Groovy { -> this } and () -> this do not return the same value. I have no opinion about that, i let you guys decide :) That said, the lambda metafactory takes a desugared lambda as argument (a plain old static method, apart in corner cases), so choosing the semantics of the lambda in Groovy is orthogonal to the choice of using the lambda metafactory or not. Rémi