Lambdas with implicit type parameters

[Dan Smith]

On Feb 6, 2013, at 2:44 PM, Dan Smith <daniel.smith at oracle.com> wrote:

> Our status quo for handling of generic function descriptors (derived from functional interfaces with generic methods) was described by Brian back in April [1]: method references can target these functional interfaces, but lambdas, because they can declare no type parameters, cannot.
> 
> I remember discussions about an alternative approach, but I don't know whether it really got proper treatment from the EG, so I'll describe it here.  If anyone thinks this is a good enhancement to make, or if anybody remembers a previous, more in-depth discussion, please say so.
> 
> (Background: Remember that a lambda is treated like an override of the functional interface's method; generally speaking, the rules for a legal lambda correspond to the rules for a legal overriding declaration -- this means the lambda must declare the "same" (allowing for renaming) type parameters as the descriptor.  Also recall that we tried to find a syntax for generic lambdas, and failed to find anything acceptable.)
> 
> The idea: a lambda that targets a generic function descriptor may have an implicit type parameter declaration. Unlike most other forms of inference (using the term broadly), this is inference of a _declaration_ of a new name.  Sort of like wildcard capture.  The new names would be unmentionable, but if the lambda can be defined without needing to refer explicitly to a type parameter name (probably fairly common, especially when the lambda parameter types are inferred), that's fine.
> 
> Error messages would have to find a way to talk about these nameless tparams, of course (if, say, there's a type error in the lambda body).  Typically the functional interface declaration provides a reasonable name, although, in general, there can be multiple methods that describe the same descriptor with different type parameter names.
> 
> Example:
> 
> interface ListFactory {
>  <T> List<T> make();
> }
> 
> ListFactory f1 = ArrayList::new; // currently legal
> ListFactory f2 = () -> new ArrayList<>(); // illegal currently, the enhancement would allow it
> ListFactory f3 = () -> new ArrayList<T>(); // definitely illegal: T is not in scope
> 
> —Dan
> 
> [1] "Generic functional interfaces, generic method refs, and generic lambdas", 12 Apr 2012, from jsr-335-eg at jcp.org

Remi says "yes, please":

On Feb 20, 2013, at 8:15 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> Hi Dan,
> I'm interested :)
> Yes, the compiler should try to infer the type variables and that these variables should not be accessible in Java.
> 
> Rémi

Anybody else have an opinion?

—Dan