Overload resolution simplification

[Ali Ebrahimi]

Hi,

On Thu, Aug 15, 2013 at 1:59 AM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> On 14/08/13 19:57, Ali Ebrahimi wrote:
>
>> Hi,
>> please reread Eric's last two paragraph again[1]:
>>
> I think I read it well - I just believe Eric is talking about two
> different  kinds of information flow:
>
> 1) return type constraints on methods cannot influence overload resolution
> [as in Java]
>
> 2) lambda return value constraints CAN influence overload resolution [as
> in Java]
>

3) lambda return value constraints CAN also influence type inference (as in
C#, based on my understandings from C#'s Spec & Eric's blog)


>
> The big question mark is: how do I get to a lambda return value
> constraint? Well, you have to be able to check the lambda first; and when
> can you do that?


when you don't turn off type inference.


> When you have a grip on the _instantiated_ lambda parameter types. This, I
> believe, means that in certain cases, restriction (1) will play an
> important factor, as certain lambdas will not be checked (or will be
> checked with sub-optimal parameter types?) and you won't get what you
> expect. More or less what you get with Comparator.comparing.
>
>
Regards,
Ali Ebrahimi