Overload resolution simplification

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Mon Aug 19 05:29:55 PDT 2013

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.

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, 

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.


More information about the lambda-spec-observers mailing list