heads-up: biggie overload rewrite

[Maurizio Cimadamore]

On 25/07/13 20:22, Maurizio Cimadamore wrote:
> On 25/07/13 19:15, Sam Pullara wrote:
>> I just did a build this morning and still see these fail:
>>
>>           Comparator<String> comparator = Comparator.comparing(String::length);
>>           Comparator<String> comparator = Comparator.comparing(s -> s.length());
>>
>> Are they still supposed to result in:
>>
>> java: reference to comparing is ambiguous
>>     both method <T>comparing(java.util.function.ToLongFunction<? super T>) in java.util.Comparator and method <T>comparing(java.util.function.ToDoubleFunction<? super T>) in java.util.Comparator match
> Possible that you didn't pick up the changes?
The first work for me (haven't tried the second but should be ok).

Maurizio
> Maurizio
>> Sam
>>
>> On Jul 25, 2013, at 9:47 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>
>>> Dear lambdians,
>>> I've just pushed a patch [1] that enhances javac overload
>>> resolution/most specific story in several ways. One of the most notable
>>> effects is the removal of the dreaded 'inference loop' message [2]. The
>>> logic behind that message was noble: at the time we thought it would
>>> have been better to report an error when the compiler was forced to
>>> infer a variable to some 'default' instantiation (such as j.l.Object),
>>> as this could cause severe downstream problems when type-checking a
>>> lambda whose body depended on that choice. However, this was before we
>>> added the more complex inference support; now that we have a more
>>> capable inference engine, with all bells and whistles, we also have a
>>> bigger degree of complexity and, because inference constraints are
>>> propagated transitively, the line between default and non-default
>>> instantiation has become a lot fuzzier than it used to be. Hence the
>>> decision of getting rid of that logic (and related error message) -
>>> which also makes the language more consistent (as inference typically
>>> only gave such errors when lambdas/method references are present).
>>>
>>> Other improvements in sight for the structural most specific logic; many
>>> of you [3,4,5] have reported cases in which the compiler was unable to
>>> distinguish between several signatures, where the 'right' choice seemed
>>> indeed really easy. The problem in that case was that the structural
>>> most specific check would only kick in if the compiler can prove that
>>> all target types agree on the parameter types to be inferred for i.e. an
>>> implicit lambda. In certain cases (when generic methods were used), the
>>> compiler couldn't do that, so it basically went back to the old most
>>> specific logic. Here's an example:
>>>
>>> <T,R> Stream<R> map(Stream<T> s, Function<T,R> f) { }
>>> <T> IntStream map(Stream<T> s, ToIntFunction<T> f) { }
>>>
>>> map(ss, s->s.length()); //now ok - used to be ambiguous
>>>
>>> There are rules to this game though; if the variable to be inferred to
>>> be able to type-check the lambda (T in the above example) happened to
>>> depend on one of the inference variables mentioned in the method return
>>> type, the most specific check would fail and the compiler would again
>>> report an ambiguity. The reason for this is that it's not possible to
>>> guarantee that the eager instantiation of T would remain the same after
>>> looking at the target type (and we want overload selection to be
>>> independent from the target type, as we believe it's crucial to keep the
>>> model tractable for developers).
>>>
>>> The last improvement is related to the way in which method arguments are
>>> type-checked; javac is now able to reason about the subtle dependencies
>>> that arise when a lambda is passed as an argument to a generic method;
>>> in the above case for instance, javac will detect that there's a
>>> dependency between T and R in the first method. In fact, if we had an
>>> instantiation for T, we would then be able to type-check the lambda and
>>> we will most likely be able to derive new constraints for R. So, it
>>> would be mad for the compiler to go and try to infer R _before_ looking
>>> at the lambda expression.
>>>
>>> I think those improvements go a long way in terms of polishing the
>>> overall overload resolution story that the language presents to
>>> developers; it gets rid of several outstanding issues, and makes the
>>> whole overload selection process more streamlined and consistent. I'm
>>> looking forward to hear your feedback (and bug reports :-)) as you start
>>> using the next promoted lambda bits.
>>>
>>> Enjoy the ride!
>>>
>>> [1] - http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d34073d069c8
>>> [2] -
>>> http://mail.openjdk.java.net/pipermail/lambda-dev/2013-July/010352.html
>>> [3] -
>>> http://mail.openjdk.java.net/pipermail/lambda-dev/2013-July/010476.html
>>> [4] -
>>> http://mail.openjdk.java.net/pipermail/lambda-dev/2013-June/010088.html
>>> [5] -
>>> http://mail.openjdk.java.net/pipermail/lambda-dev/2013-July/010590.html
>>>
>>> Maurizio
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>