Overload resolution simplification

[Remi Forax]

On 08/10/2013 03:56 PM, Maurizio Cimadamore wrote:
> On 10/08/13 08:07, Andrey Breslav wrote:
>> The case of overloaded method references worries me as well (lambdas 
>> are ok). Note that C# supports overloaded method references (method 
>> groups) as arguments and only as arguments. It seems that inference 
>> can disambiguate method references rather well if we stick to what 
>> Dan proposes about lambdas, because for a method reference there is 
>> no body to check. But maybe I'm missing something.
> I believe C# is very different w.r.t. Java when it comes to 
> target-typing and overload resolution - as such C# is not subject to 
> all the issues we have here with 'stuck' expression - i.e. expression 
> such as lambda and/or method references that cannot be looked at by 
> the compiler because some type information is missing and the compiler 
> cannot safely go ahead and instantiate the inference variable that 
> would make it possible for the compiler to go ahead.

Taking about C#,
C# is also able to disambiguate if a lambda is an Action (T => void) or 
a Func<T,U> (T => U).

And, I would prefer that the compiler stops if there is a suck 
expression instead of giving up too early.

>
> I think 'comparing' is a good example of what can go wrong; even if we 
> added support for overloaded method references (which we had last 
> week), that API cannot be compiled by passing in a method reference, 
> as the inference variable that is keeping the method reference stuck 
> also appears on the 'comparing' return type. Which is, IMHO, a much 
> more subtle explanation than 'just don't use an overloaded method 
> reference here'.

yes, we all agree about that.
A the same time, overload methods already exists and there are not the 
issue.
Correct me if I'm wrong but the issue comes when you mix overloads and 
generics methods,
just say don't do that.

>
> If we could have a scheme that worked in all cases, then I'd be 
> totally in favor of having a more complex scheme. But, because of Java 
> legacy, I don't think such an approach exists here.
>
> The only incremental improvement I see viable here, one that has been 
> discussed before, would be to add some logic to detect that all 
> overloaded methods force the same choice on the implicit lambda 
> parameter/overloaded mref; that would be enough to get past Remi 
> example - but it doesn't scale too well to generic methods.

For implicit lambda, I see no issue if the compiler tries to typecheck 
the same lambda with different parameters but in that case, the compiler 
should not try go ahead by creating a new context. Again, it means that 
if one typechecking of the lambda expression is stuck, the compiler 
should stop.

I prefer this rational because this will also avoid the combinatorial 
explosion but also allows API designer to use overloads if all of them 
are not generics.

>
> Maurizio

Rémi

>
>>> On Aug 9, 2013, at 2:21 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>>
>>>> Also I've a nice parsing framework that use type specialised lambda 
>>>> to avoid boxing that doesn't compile anymore.
>>>>
>>>> public IntStream parse(BufferedReader reader, ToIntFunction<String> 
>>>> fun) { ... }
>>>> public LongStream parse(BufferedReader reader, 
>>>> ToLongFunction<String> fun) { ... }
>>>>
>>>> when called like this: parse(Integer::parseInt).
>>> Thanks for the use case.
>>>
>>> The 'parse' method is essentially the same shape as the 'map' method 
>>> that was discussed by the EG quite a bit, with the eventual 
>>> conclusion that it would be clearer to give each method a different 
>>> name (parseInts, parseLongs, etc.).
>>>
>>> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-February/001417.html 
>>>
>>> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-March/001441.html 
>>>
>>> http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-March/001458.html 
>>>
>>>
>>> Doesn't mean that all other developers must follow our lead, but the 
>>> fact that the EG tried it and then concluded that it didn't want 
>>> overloading here is a strong argument that this is potentially a bad 
>>> convention to follow.
>>>
>>> If somebody likes this convention anyway, then we made a 
>>> special-case effort to support method references. Unfortunately, 
>>> Integer::parseInt is overloaded and so outside of the set of 
>>> supported method references. As I mentioned in the EG meeting, by 
>>> drawing the line like this, it's great when it works, and annoying 
>>> when it doesn't and you fall off of a cliff. We considered using 
>>> arity (e.g., "is this overloaded with arity 1?"), but that just 
>>> moves the line, rather than solving the problem.
>>>
>>> So, I don't love the cliff, but I don't have a good alternative, 
>>> other than just not having any special treatment at all.
>>>
>>> —Dan
>