Bug in the compiler I think?

[maurizio cimadamore]

On 27-Jun-12 4:08 PM, Brian Goetz wrote:
> 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.
Uhmm - the compiler implements the structural most specific check 
correctly - however this case is similar, I believe to the already 
discussed into(new ArrayList<>) case - the method comparing accepts a 
single parameter that contains inference variables in argument position 
of the corresponding functional descriptor, so the compiler doesn't have 
an handy target-type to type-check the method reference passed in as 
argument. This kind of problems could be alleviated by special-casing 
method references for which there's a single match (no overloads).

Maurizio
>
>
> 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
>>
>