Overload resolution simplification

[Maurizio Cimadamore]

On 19/08/13 15:59, Zhong Yu wrote:
> 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.
>>
>> 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
> Programmers don't need to look at all overloads, correct? For the code
> writer, he knows javac will check that for him. For a code reader, he
> knows that javac has checked that. Therefore they can just look at one
> method to figure out the lambda parameter type. Often they don't even
> need to do that; the lambda parameter type is usually self evident
> given the nature of the method, e.g. `streamOfString.map(s->...)`,
> `stringComparator.thenComparing(s->...)`.
In reality you will have to look at overloads to understand whether the 
compiler will be able to look at the lambda body and do most specific 
using information from the body (i.e. when things go wrong).
>
> If javac allows this kind of overloads, I think we can trust most API
> authors to be responsible in not abusing it; most APIs using such
> overload strategy will be quite simple and won't create more cognitive
> hurdle to API users than having several different method names.
>
>> 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
> These difficulties exist even for non-overloaded methods, correct? If
> the method is overloaded N times, the difficulties becomes N fold.
> However if the user can trust javac to ensure that all N methods agree
> on the lambda parameter type, he does not need to worry about
> overloads; the difficulties do not become N fold for him.
See above. There will need to be some reasoning about 'can I safely use 
an implicit lambda here?' and that reasoning is hard. It would only be 
simple if javac would give _errors_ for such overloads - but that's 
clearly out of the discussion.

Maurizio
>
>> 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
>>
>>