Overload resolution simplification
ali.ebrahimi1781 at gmail.com
Thu Aug 15 02:30:23 PDT 2013
This  is another post from Eric.
On Thu, Aug 15, 2013 at 4:12 AM, Ali Ebrahimi <ali.ebrahimi1781 at gmail.com>wrote:
> 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:
>>> please reread Eric's last two paragraph again:
>> 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.
> Ali Ebrahimi
More information about the lambda-spec-observers