JEP 302: Lambda Leftovers

[Stephen Colebourne]

On 7 December 2016 at 10:47, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> 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!

Yuck.

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.

Stephen

> 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 univ-mlv.fr> 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 oracle.com>
>>>> À: "maurizio cimadamore" <maurizio.cimadamore at oracle.com>
>>>> Cc: platform-jep-discuss at openjdk.java.net
>>>> Envoyé: Mercredi 7 Décembre 2016 00:50:02
>>>> Objet: JEP 302: Lambda Leftovers
>>>> New JEP Candidate: http://openjdk.java.net/jeps/302
>>>>
>>>> - Mark
>
>