Overload resolution simplification

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Tue Aug 20 02:41:52 PDT 2013

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)


More information about the lambda-spec-observers mailing list