JEP 302: Lambda Leftovers

[Brian Goetz]

> TLDR: I've seen direct evidence of not being able to shadow lambda
> parameters actually being beneficial for readability.
>

I believe you.  Both ways have pros and cons; there are times when it 
forces you to be clearer, and there are times when it just forces you to 
crap up your code.  The debate over this in the original JSR-335 EG 
reflected this.  Ultimately the decision didn't end up getting made on 
the basis of one being demonstrably better than the other -- because no 
one could offer a strong enough argument for either; instead, we hid 
behind that last refuge of scoundrels, "consistency".  Specifically, the 
scoping rules seemed more consistent the way they were originally 
written, but no one was really all that comfortable with the decision.

> 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.

Yes, this is very tempting.  And for simple lambdas (x -> x + 1), its 
just fine.  But as lambdas get more complicated, developers don't always 
adjust their habits, as you've observed.

The main place where the current scoping rules bite is when the argument 
of the nested lambda _refers to the same thing_ as the same-named 
argument in the outer lambda.  Such as:

     Function<K, V> mapGetter k -> map.computeIfAbsent(k, k -> new 
PlaceHolder());

Here, both k's are the same thing, so calling the second 'kk' seems 
gratuitously specific.  But this is just one use case; there are others 
where multiple names would make the code more readable.