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

Sun Jan 28 22:10:28 UTC 2018

Hi all,

I'll just reply to Brian's response as he covers everything (but thanks to
everyone else who responded!)

On 27 January 2018 at 05:02, Brian Goetz <brian.goetz at oracle.com> wrote:

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

I personally don't have an issue it being a small or seemingly trivial
feature, this is a good thing given the new cadence :-). What I was missing
(my lack of understanding) was that this smaller feature fit into the
larger (LVTI) picture.  It might be worth (annoying as it is to have to
summarise what's already been discussed on lists) putting that sort of
summary statement in similar JEPs going forward - "This JEP is also a piece
/ stepping stone to X, Y, Z".

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

OK, this makes total sense and is indeed cleaner.  There will of course be
the issue of there being a lot of historical examples and literature out
there which will need to be updated with the hierarchy you described.  The
adoption group can go and find some top SO Q&A posts around this topic and
update them when the time comes (as well as adding some small blog posts
etc).

I can also see people asking "Why can't I use var in my lambda when I can
use it everywhere else?" so it's more consistent this way.

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

Less corner cases are most welcome and from Maurizio's response I see that
one of my corner case concerns could be resolved (assuming it becomes a
real problem) and that the other one matches existing behaviour (so it
doesn't make it worse at least), so that's OK as well.

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

Ah even better!

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

This certainly wasn't my personal concern, I just couldn't figure out the
stand alone value of this JEP, especially when (for me) it added more
cognitive load to the developer as opposed to less.

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

In isolation I was scratching my head over this feature, but as part of the
LVTI JEP it totally makes sense, and I missed that hierarchy piece in my
thinking.

Thanks for taking the time to respond everyone, I appreciate it's an extra
unwelcome load when a part timer comes in and asks for explanations!

Cheers,
Martijn

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