Parametrized method and cyclic inference

[Brian Goetz]

We're working on that!

On 11/2/2012 4:19 PM, Sam Pullara wrote:
> 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
> <mailto: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
>
>