Overload resolution simplification

Andrey Breslav andrey.breslav at jetbrains.com
Sat Aug 10 00:07:55 PDT 2013


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. 

Dan, could you post some problematic examples concerning method references?

--
Best regards,
  Andrey Breslav

On Aug 10, 2013, at 3:39 AM, Dan Smith <daniel.smith at oracle.com> wrote:

> 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


More information about the lambda-spec-experts mailing list