Overload resolution simplification

[Dan Smith]

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