JEP proposed to target JDK 11: 323: Local-Variable Syntax for Lambda Parameters

[Brian Goetz]

Additionally…

1.  It seems that part of the force behind the reactions is due to the seeming triviality of the feature.  But this is more about the more rapid cadence than about the feature itself.  The Amber EG discussed this feature in the context of local variable type inference, but chose to carve it off to reduce the risk of the main part of that feature missing the train, and then continue deliberating on the finer points of the interaction with lambdas.  This is a feature, not a bug.  

2.  Part of the motivation here is pedagogical / historical cleanup.  When we did lambdas, we found there was a lot of confusion over the various syntactic forms for lambdas (explicit, implicit, unary implicit), and early articles and textbook drafts made it seem way more complicated than it was, treating each form as its own special case.  Adding in the var form smooths out what was a bump in the explanation, now we can say

    x -> e

is just shorthand for

    (x) -> e

which is just shorthand for

    (var x) -> e

which is just shorthand for a particular instantiation of

    (T x) -> e

Defining one syntactic form in terms of another reduces the cognitive load of learning and reasoning about the feature, and helps users direct their brain cycles to the actual hard part of the feature.

Aligning the use of inference for variables and for function parameters additionally helps people learn, because by using the same syntactic indicator, people realize that it is the same concept: “I would rather not write down the type here, please infer it.”  Each use of var strengthens the other.  

As features are added incrementally, it will periodically become sensible to clean up their interactions to reduce the number of special cases and sharp corners, not only to make the language easier to learn and reason about, but also to provide a smoother base to build future features on.  So while this feature may not get anyone excited about “boy, I want to write my lambdas that way”, that’s not the point.  We’re not taking away your favorite syntax, we’re putting that syntax on a firmer footing.  

3.  Laying groundwork for the future.  Maurizio is correct that we are not ready to do partially implicit lambdas ( (var x, int y) -> e ), as we were similarly not ready to do in 8 when the feature first came up.  However, regularizing the syntactic basis for lambdas paves the way to a smoother path to doing so in the future, which I think we would still like to do (though it is not yet near the top of the priority list, which is why we haven’t done it yet.)

4.  I find that much of the angst about proposed new features is a generalized fear that we’re investing significant effort in something people don’t care about, which is taking resources away from things they do.  I assure you that is not the case; the spec and implementation here are trivial.  

In a perfect world, this would have been part of the LVTI JEP; for good and valid reasons, we severed it, and now we’re reattaching it.  That’s all that’s going on here.  


> On Jan 26, 2018, at 10:08 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> In response to the many comments in this thread, let me clarify what the goals are here:
> 
> * first, as in JDK 10 we have 'var' in certain places (local variable decl, for loop variable, try with resource variable), it seems consistent to apply 'var' in other places too; a lambda parameter is yet another case where the parameter type is implicitly typed, so it kind of makes sense to let the programmer be able to use 'var' if he/she so wishes.
> 
> * the second reason, which was pointed out correctly in the email, is to provide a path to add modifiers (such as 'final') and or annotations to a lambda parameter w/o the need of resorting to explicit types. That is IMHO a small, but valuable improvement. Also note that, while availability of annotations on lambdas at runtime depends on the translation strategy, there could be compile-time clients (e.g. annotation processors) that might be interested in consuming such annotations.
> 
> * I'm not too worried about the restriction of mixing 'var' and implicit parameter in the same lambda, because I'd say that mixing var and legacy implicitly typed param leads to less readable code IMHO. That said, there's actually no technical reason for enforcing this constraint, so this might be a point where we might have some degree of freedom (or which could be revised at a later date).
> 
> * There *is* a technical reason behind not allowing a mix of explicit and implicit parameters, so that's not up for debate. That has been the case since JDK 8, and it did not create any concern.
> 
> Regards
> Maurizio
> 
> On 25/01/18 19:40, mark.reinhold at oracle.com wrote:
>> The following JEP is proposed to target JDK 11:
>> 
>>   323: Local-Variable Syntax for Lambda Parameters
>>        http://openjdk.java.net/jeps/323
>> 
>> Feedback on this proposal is more than welcome, as are reasoned
>> objections.  If no such objections are raised by 23:00 UTC on Thursday,
>> 1 February, or if they're raised and then satisfactorily answered, then
>> per the JEP 2.0 process proposal [1] I'll target this JEP to JDK 11.
>> 
>> - Mark
>> 
>> 
>> [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html
>