Lambdas with implicit type parameters

[Dan Smith]

On Feb 20, 2013, at 11:54 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:

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

Maurizio, thanks, that's useful.  At this stage, I don't think we'd want to consider it at all if the implementation were nontrivial.

Sam, even so, we do still need to keep in mind that our budget is quite small at this point, and there are costs (e.g., testing overhead) associated with every "new feature," no matter how easy it is to implement.  Worth considering whether _this_ is the feature we want to spend our budget on.  (Perhaps at some point soon I should collect all practical outstanding feature ideas and we can pick our favorites, limited by our remaining budget...)

Beyond that, I think the main question is how we feel about the instability it creates in the language design -- the most stable point would be either to prohibit generic descriptors altogether, or provide syntax for generic lambdas.  But those alternatives are unattractive.  Our compromise point was to say method references can be generic, but lambdas cannot -- a little more awkward, but still a pretty clear line.  Making this change would mean lambdas can be generic *as long as you don't need to talk about the type parameters*.  That's a lot harder to explain, and increases the likelihood that somebody's going to be really annoyed when they need to tweak their program and find that the syntax arbitrarily prohibits what they want to say.

Intertwined with this is the problem that non-denotable types are generally a pain, and this would introduce them in yet another place.

So that's the argument against.  I'm also sympathetic to the argument for, which is that [big number]% of uses cases don't need to mention the type variables, and this would sure be convenient for them.

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

It's essentially a theoretical concern for specification.  Types have to be interpreted in a particular scope, and we can't have the descriptor's type variables polluting the scope with names that shadow enclosing things.  But, depending on the details of an implementation, it might be able to ignore this (e.g., maybe the implementation's types don't need to be interpreted in a scope).

—Dan