JEP 302: Lambda Leftovers

Stephen Colebourne scolebourne at
Wed Dec 7 11:25:32 UTC 2016

On 7 December 2016 at 10:47, Maurizio Cimadamore
<maurizio.cimadamore at> wrote:
> As a kind of a counter example, consider this:
> Map<String, String> mss = ...
> String s = "hello";
> mss.computeIfAbsent(s, s2 -> s2.toLowerCase());
> vs. this:
> mss.computeIfAbsent(s, _ -> s.toLowerCase());
> The first is a non-capturing lambda - the second is a capturing one!


I'm afraid this rather confirms my initial opinion that adding _ and
removing the shadow restriction are a bad idea. (FWIW, it is very rare
for me to have an unused parameter where I find naming it to be a
hassle - normally the IDE will choose a sensible name anyway and I
just don't worry).

I imagine everyone will be in favour of better disambiguation.


> On 07/12/16 09:10, Martijn Verburg wrote:
>> I'll preface this with IANALE (I Am Not A Language Expert),
>> TLDR: I've seen direct evidence of not being able to shadow lambda
>> parameters actually being beneficial for readability.
>> -----
>> I currently read a lot of code by developers who are using lambdas and
>> wanted to add some anecdotal evidence to the shadowing use case.  I notice
>> the JEP author has already stated:
>> "It would be desirable to lift this restriction, and allow lambda
>> parameters (and locals declared with a lambda) to shadow variables defined
>> in enclosing scopes. (One possible argument against is readability: if
>> lambda parameters are allowed to shadow, then in the above example, the
>> identifier 'key' means two different things in the two places where it is
>> used, and there seem to be no syntactic barrier to separate the two
>> usages.)"
>> ---
>> The readability issue is really cropping up a lot with the lambdas code
>> I'm
>> seeing. Many developers are already following a short hand idiom for
>> lambda
>> variables e.g. using 'k' instead of 'key', along with some other idioms
>> that do lessen the readability of lambdas based code in general. This is
>> clearly not the fault of the language / syntax today, it's more the fault
>> of the developer! A similar argument can be applied to the proposed 'var'
>> JEP, as long a developers name their variables properly, readability is
>> maintained.
>> That said, the current status quo of not being able to shadow lambda
>> parameters is actually forcing developers to think more clearly about
>> naming and scope, which is generally a good thing.  My concern is that if
>> we are able to shadow lambda parameters this will cause even more
>> confusion
>> to the reader unless they carefully hover over the section in their
>> favourite IDE *or* have the 'scope of variables outside of the lambda vs
>> inside the lambda' concept firmly in their heads (an educational issue).
>> ----
>> As a side note, JEPs 300, 301 and 302 are very cool. Anything that
>> improves
>> type inference and safety automatically for the developer is a welcome
>> addition and I appreciate how hard it is to get that right internally in
>> the JVM and in the language.
>> Cheers,
>> Martijn
>> On 7 December 2016 at 08:37, Remi Forax <forax at> wrote:
>>> I really appreciate this proposal,
>>> i hit both better disambiguation and shadow of lambda parameters issues
>>> quite frequently.
>>> For treatment of underscores,
>>> as i understand, the idea is that you can use '_' as parameter without
>>> having '_' being entered in the scope of the method,
>>> i.e. this code will not compile:
>>>    void setBar(Bar _) {
>>>      foo(_);
>>>    }
>>> cheers,
>>> Rémi
>>> ----- Mail original -----
>>>> De: "mark reinhold" <mark.reinhold at>
>>>> À: "maurizio cimadamore" <maurizio.cimadamore at>
>>>> Cc: platform-jep-discuss at
>>>> Envoyé: Mercredi 7 Décembre 2016 00:50:02
>>>> Objet: JEP 302: Lambda Leftovers
>>>> New JEP Candidate:
>>>> - Mark

More information about the platform-jep-discuss mailing list