Lambdas with implicit type parameters

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Feb 20 10:54:18 PST 2013


On 20/02/13 18:46, Sam Pullara wrote:
> I think we should allow it as well. Is there some downside?
Implementation-wise seems reasonably straightforward - not much more 
than just allowing generic functional descriptors on lambdas, I think.

Actually, is there any reason why we should recreate new type-variables 
_at all_ as opposed as to reusing those from the functional interface 
declaration?

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



More information about the lambda-spec-observers mailing list