Bug in the compiler I think?

[Brian Goetz]

This is an issue where the compiler has not yet caught up with the spec (and, the EG is still negotiating the fine points of the spec.)  Currently, neither LongMapper nor IntMapper is "more specific" than the other (neither is a subtype of the other), so the compiler cannot pick an overload since both are equally applicable.  What is needed is to adjust the most-specific rules to "dive into" the structural type to disambiguate between T -> int and T -> long and choose which is the "most specific" in this case.  


On Jun 27, 2012, at 4:05 AM, David Conrad wrote:

> On Tue, 26 Jun 2012 09:05:31 -0700, Sam Pullara <sam at sampullara.com> wrote:
> 
>> 
>> ...
>> 
>> Fails to compile due ambiguous target type it appears -- seems like it
>> should pick the IntMapper:
>> 
>>   interface Person {
>>       int age();
>>   }
>>   public static void main(String[] args) {
>>       List<Person> list = new ArrayList<>();
>>       list.sorted(comparing(Person::age));
>>   }
>> 
>> src/test/java/spullara/Scratch.java:14: error: no suitable method found for
>> comparing(Person#age)
>>       list.sorted(comparing(Person::age));
>>                   ^
>> 
> 
> cyclic inference, cannot tell the difference between Mapper,
> IntMapper, LongMapper, DoubleMapper, yadda, yadda, yadda.
> 
> The mappers all take some T as a parameter which needs to be
> inferred here. Person::age is nullary, so T is void, or Void. I don't
> think it's allowed to disambiguate them by return type, and they're
> not distinguishable by parameter types. Ugly. Ugh.
> 
> Nice catch. :)
> 
> David
>