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,
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
More information about the lambda-spec-observers
mailing list