Overload resolution simplification

Dan Smith daniel.smith at oracle.com
Fri Aug 9 16:39:44 PDT 2013

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


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.


More information about the lambda-spec-experts mailing list