Overload resolution simplification

[Zhong Yu]

On Mon, Aug 19, 2013 at 7:29 AM, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> On 19/08/13 12:20, Ali Ebrahimi wrote:
>>
>> If your intend is compiler side complexity base on your previous reply
>> problem already solved.
>
> The problem is solved - but at what cost? A sufficiently large (4/5 ?)
> number of nested lambdas will basically have the compiler spin forever. And
> that's not just javac - _all_ compiler will be affected by that. That's what
> we are uncomfortable with, regardless of whether the compiler code already
> exists and/or can be easily written or not.
>
> Now, it seems like we are in agreement that doing this combinatorial
> type-checking is bad, and we should look for ways to limit that - the
> restriction that I've seen popping up more frequently is: only do
> type-checking if _all_ overloads agree on the implicit lambda parameter
> types, correct? There would be no combinatorial explosion then.

I guess this strategy is currently not on the table and EG is
committed to the simplification that condemn all overloads with
implicit lambda? We are going to see a lot of ugly method names in
Java.

Zhong Yu

>
> This is generally a god strategy (in fact the one I've been proposing since
> the beginning as a possible incremental update). But it's not issue free. It
> requires global reasoning for the user. To asnwer the question: will this
> lambda be checked during overload (so that most specific will get better
> treatment)? You really have to work hard, look at all overloads, and see if
> they agree on the lambda parameter type. As I was trying to explain last
> week, this is way harder than it looks on the surface, as those target types
> can be nested within other generic types, type-variable declarations can be
> subtly swapped, you can have wildcards which require their own handling. All
> this _will_ make things more complex for the user (in the current model a
> lambda is type-checked during overload only if it has explicit parameters -
> rather easy to see, no?).
>
> Another problem is that the approach will create an asymmetry between
> generic and non-generic method overloads; while it is possible to close the
> gap,  it is not possible to completely eliminate it, as we cannot eagerly
> instantiate inference variable that depends on return type when doing
> overloading. This is the limit we hit with the previously implemented
> overload resolution scheme - and note that doing return-type dependency
> (with possible transitive bounds - not uncommon in the Stream API) is
> another 'hard' thing that we would ask user to worry about.
>
> Maurizio
>
>