Parametrized method and cyclic inference

[Sam Pullara]

I've run into this case a lot when building things. I would love it if it
were fixed.

Sam

On Fri, Nov 2, 2012 at 9:48 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> Hi guys,
> I've tried to take a big corpus of code and to refactor all inner-classes
> to use lambda instead.
>
> The good news is that on 23 uses of inner classes, 20 can be retrofited to
> use lambdas
> because the target type is a SAM and they don't require a strong identity
> (this is not used).
> The bad news is that among the 20 that can be retrofited, 17 can not be
> retrofited using
> the syntax that doesn't specified the type of the formal parameter i.e.
> the natural syntax
> because the compiler complains that there is a cyclic inference.
>
> The 17 snippets of code can be covered by 3 cases:
>   static <T> void m(T t1, T t2) {
>     // empty
>   }
>
>   public static void main(String[] args) {
>     m(x -> 3, x -> 4);   // case 1
>     Set<Mapper<Integer, Object>> set = Collections.singleton(x -> 3);   //
> case 2
>     List<Mapper<Integer, Object>> list = Arrays.asList(x -> 1);  // case 3
>   }
>
> To sumarrize, it's currently impossible to call a parametrized method with
> an untyped lambda,
> the inference will just choke.
>
> I think instead that if there is a cyclic inference,
> the return type should be used to try to infer the formal parameter type
> of the lambda,
> at least, it will solve case 2 and 3.
>
> regards,
> Rémi
>
>