support for 'var' in lambda parameters

[Maurizio Cimadamore]

On 27/09/17 13:20, Zheka Kozlov wrote:
> Why should we allow `var` in lambda parameters? Who will ever need 
> writing `(var x) -> x` instead of `x -> x`?
Hi,
first of all, to clarify things, this is an experimental feature - which 
is why it was left out from the JEP 286 integration into jdk10/master.

Secondly, JEP 286 is not just about 'var' in local variable declaration 
(although I agree that's the most frequent use case). You can also use 
'var' in other places too, such as for loops and try-with-resources. 
 From an uniformity perspective, one could argue that lambda parameters 
are another place where the 'var' treatment could be applied.

As you point out, lambdas do provide a more succint version to declare 
implicit parameters - but in a language that is evolving to use 'var' in 
more places (pattern matching will likely use 'var' for pattern 
bindings), I think that, from a pedagogical question at least, it makes 
sense to allow 'var' in all places where you want to declare a variable 
but you don't care about giving it an explicit type.

Maurizio
>
> 2017-09-27 19:07 GMT+07:00 Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com <mailto:maurizio.cimadamore at oracle.com>>:
>
>     Hi,
>     I've recently pushed a changeset [1] to enable use of 'var' in
>     lambda parameters. Below is some rationale on the implemented support.
>
>     In the current (e.g. JDK 9) grammar, we have two versions of
>     lambdas: *implicitly*- and *explicitly*-typed. Furthermore, an
>     implicitly typed lambda can come in two form (there's no
>     terminology for it, so I'll make up one): *compact* and
>     *parenthesized*.
>
>     Let's see some examples:
>
>     x->x //implicit, compact
>     (x)->x //implicit, parenthesized
>     (String x)->x //explicit
>
>     So, the first question is - when is it ok to use `var`? There are
>     two choices here:
>
>     1. allow `var` on all implicit lambdas
>     2. allow `var` only on implicit parenthesized lambdas
>
>
>     We concluded that (2) is the option that makes more sense - this
>     allows for a smooth verbosity curve (see below from most compact
>     to least compact):
>
>     x->x
>     (x)->x //added parens
>     (var x)->x //added 'var'
>     (String x)->x //ok, fully typed
>
>     Second question: we basically have now two kind of implicitly
>     typed parameters - those that omit type info in full (e.g. the
>     formal decl is just an identifier) and those using `var`. Can we
>     mix and match between these e.g.
>
>     (var x, y)->x+y
>
>     We have concluded that there's no need to mix and match. In fact,
>     it is more likely that one form of implicit parameter declaration
>     will supplant the other in the long run.
>
>     Third question: what about parameter modifiers such as `final`
>     and/or annotations? Historically, such modifiers were not allowed
>     in implicit lambda parameters (as those were just identifiers, and
>     it poses several parser challenges to e.g. allow annotations
>     there); on the other hand, local variables using `var` support
>     both modifiers and annotations. We concluded that, for
>     consistency, we have to do the same when `var` occurs in a lambda
>     parameter.
>
>     Last question: can I mix implicit an explicit parameters?
>
>     (var x, String y)-> x + y
>
>     While that would be nice, it must be noted that this is a much
>     deeper change, with ramifications in overload selection, since
>     implicit and explicit lambdas are currently two disjoint sets,
>     with very different behavior w.r.t. overload resolution (see
>     definitions of 'pertinent to applicability' in JLS 15.12.2.2). For
>     that reason, we won't go down there now (but it's something worth
>     considering in the future).
>
>     Maurizio
>
>     [1] -
>     http://mail.openjdk.java.net/pipermail/amber-dev/2017-September/002138.html
>     <http://mail.openjdk.java.net/pipermail/amber-dev/2017-September/002138.html>
>
>
>