Overload resolution simplification

[Ali Ebrahimi]

Hi Maurizio,
This is my current updated proposal, I think this makes things more clear.
Updated proposal:

Step 1: type argument inference
for all overloads infer type arguments
if all overloads agree on same type for type args goto step 2, otherwise
ERROR.

Step 2: Scan lambda body for implicit nested lambdas
if does not exist any implicit nested lambdas goto step 3, otherwise ERROR.

Step 3: Lambda body type checking
Type check lambda body with provided input params. If type checking is
successful, goto step 4, otherwise ERROR.
Do this step only once for all overloads, since you have same input types.
Note: In this step we only type checks lambda body for body errors not type
mismatch in return type, since we don't do this step against any target.
Suppose we have function types in language and try to compute function type
(type descriptor) of lambda. We don't do SAM comversion in this step.

I think this step would be an forward compatible step if we one day add
function types to language.

Step 4: Overload Selection (Most specific applicable overload selection)
We have obtained one function type or type descriptor for lambda from step
3, and do structural type checking against each overload's target.
We do this process in four phase or mode

1) Without Boxing, Unboxing, Widening and Upcasting(can not do boxing,
unboxing, widening and upcasting)
2) Without Boxing, Unboxing and Upcasting but with Widening (can not do
boxing, unboxing and upcasting but can do widening)
3) With Boxing, Unboxing and Widening but without Upcasting(can do boxing,
unboxing and widening but can not do upcasting)
4) With Boxing, Unboxing, Widening and Upcasting(can do boxing, unboxing,
widening and upcasting)


for each mode x (1..4) do:
    for each overload's target t
            1) Verify type descriptor of lambda with t's type based on
constraints of mode x, if                lambda is compatible with target
t, add t's corresponding overload method m to
               mode  x's applicable overload list.
    //end for t
    if x's applicable overload list is empty continue x's for loop
    if x's applicable overload list have only one element, you have succeed
and that is most
    specific overload.
    if x's applicable overload list have more than one element, you have
failed and you got
    ambiguity ERROR
//end for x

You have not fund any applicable overload So ERORR.

END


Best Regards,
Ali Ebrahimi



On Tue, Aug 20, 2013 at 2:11 PM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> On 19/08/13 20:42, Ali Ebrahimi wrote:
>
>> 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: () -> ...).
>>
> I guess I still don't get what happens if, for a given target you get an
> type-checking error - how is your logic supposed to handle that? Note that
> we tried both flavours and they both weren't good enough - for different
> reasons:
>
> *) making a method not applicable because of a type-checking error in a
> lambda is brittle (see my previous email)
> *) making a method applicable because of a type-checking error leads to
> can of worms spec-wise (as now you'll have to specify how all the
> type-checking routines are supposed to be working in the face of errors -
> uuugh)
>
> Maurizio
>
>
>
>
>