Overload resolution simplification

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Mon Aug 19 08:16:47 PDT 2013

On 19/08/13 16:04, Ali Ebrahimi wrote:
> Hi,
> On Mon, Aug 19, 2013 at 4:59 PM, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com 
> <mailto: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? 
> yes,
> Add to list:
> Only lambdas that don't have nested implicit lambdas.
Yes and no. Combinatorial explosion is not the only problem. Brittleness 
is another big one the EG is very concerned about. As soon as you start 
type-checking a lambda against each possible target, and reject a method 
if the target leads to a type error, your strategy becomes fragile and 
dependent on errors. We won't go down there - the same way we decided 
that disambiguating using inferred thrown types of a lambda was too big 
of a jump.
>     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, no?).
> Not always. In simple cases result may be reverse.
> Most of lambda bodies would be single line or even single expression. 
> So supporting 90% of cases would be better than No Support.
See my point above about errors - no matter how short/unnested your 
lambda is, we think disambiguating on errors is evil.

>     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.
> As I said before in my proposed scheme lambda body checking only 
> occurs if its input type args already inferred. So if we can not infer 
> them you can issue error.
> So I think we can limit problem space and only support common cases.
> Best Regards,
> Ali Ebrahimi

More information about the lambda-spec-observers mailing list