Lambda and method reference inference

[Remi Forax]

On 12/10/2012 09:38 PM, Dan Smith wrote:
> On Dec 8, 2012, at 5:09 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>
>> On 12/07/2012 11:10 PM, Dan Smith wrote:
>>> It would be useful if you could expand on your motivation.  I'm guessing it is one (or both) of:
>>> 1) You don't like the model we have and prefer yours.
>>> 2) You want direct control over the signature of the method generated by the compiler, for performance reasons.
>> it's 2) but not for performance reason but for semantics reason, given that in Java, Integer and int doesn't have the same semantics, as a user I want the to specifies that a lambda takes two ints and not two integers. You can argue that users can insert cast to int where needed but from experience, users poorly understand where to put cast in the middle of the code and given that in our case types are implicit, it doesn't help.
>>
>> About performance, that true that if the signature only use primitive type, it will be easier for the VM to remove all boxing if the lambda proxies generated use method handles because the current optimizations done by Hotspot is enough, we don't have to rely on some hypothetical optimization not yet written.
>>
>>> Where we left this last is that we like the model ("we" meaning Oracle folks, plus I haven't heard much opposition from other EG members), but it's something to reconsider if we find that performant code requires some manual intervention for tuning (e.g., minimizing boxing).
>> see above, performance is part of the equation but not the important one. Being able to specify the right semantics is more important.
> I would describe what you're saying as (1)—you feel like modeling the lambda invocation as delegation (functional interface method calls the lambda) rather than overriding (functional interface method _is_ the lambda) is nicer.

It's not nicer, what user want is to not think too much about boxing, so 
if they specify that their lambda takes ints, it should just work.
Note that I don't propose to have the *full* invocation semantics 
because i don't think that allowing varargs call is a good idea.
So if you want you can see it as the overriding semantics + boxing 
conversions.

>
>>> You point out that certain adaptations on the parameters can't be performed, and you have to do that yourself inside the body (e.g., cast Integer to int or call a method that will do the conversion automatically).  In the rare circumstance in which such conversions have semantic consequences, that's true enough.
>> I disagree, it will not be that rare because features all goes in the same direction.
>>   - there is no way to declare a collection of primitive type
>>     => so user use wrapper type and usually it works
>> - collection API use lambdas to filter/map so
>>     => so users use lambda to specify boolean expression like equality test
>> - lambda doesn't require to specify type of parameters
>>     => so users will not see that the inferred type is boxed
> Boxing/unboxing will not be rare.  But use of lambda parameters in contexts in which it matters whether they're boxed/unboxed or not (e.g., as you point out, '==' or 'List.remove') will be rare.

== is a filter will not be rare.

>
> —Dan

Rémi