Overload resolution simplification

Zhong Yu zhong.j.yu at gmail.com
Mon Aug 19 07:59:00 PDT 2013


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->...)`.

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.

> 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