Overload resolution simplification

[Ali Ebrahimi]

Hi,


On Mon, Aug 19, 2013 at 4:59 PM, 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?

yes,
Add to list:
Only lambdas that don't have nested implicit lambdas.

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

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