Overload resolution simplification

[Ali Ebrahimi]

Hi,


On Mon, Aug 19, 2013 at 7:46 PM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>  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> 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.
>
What about if type error does not occur, and lambda body satisfy all
targets. In this case we only do most specific selection as we do in
overload resolution phase. So I think with this reduced problem space
Brittleness problem doesn't occur.
if we have same input for lambda against all overloads, in that case
problem mostly (not sure 100%, help me) would be equivalent to when we
don't have any input.(nilary lambdas: () -> ...).

Regards,
Ali Ebrahimi