Lambdas with implicit type parameters

[Sam Pullara]

I think we should allow it as well. Is there some downside?

Sam

On Wed, Feb 20, 2013 at 10:35 AM, Dan Smith <daniel.smith at oracle.com> wrote:
> 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