Overload resolution simplification

Ali Ebrahimi ali.ebrahimi1781 at gmail.com
Wed Aug 14 16:42:06 PDT 2013


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.
Ali Ebrahimi

More information about the lambda-spec-observers mailing list