eclipse-archived/ceylon

infer type argument to Collectors.toList()

Closed this issue · 3 comments

It's a little irritating that I have to explicitly write in the type argument String in this code:

    value evenCubes =
            LongStream.iterate(1, (x)=>x+1)
                .parallel()
                .map((i) => i^3)
                .filter(2.divides)
                .mapToObj((i) => i)
                .limit(20)
                .collect(Collectors.toList<Integer>());

Currently we do a similar sort of type inference on:

  • parameter types of anonymous functions, and
  • type arguments of function references.

The reason we don't also do it for invocations of toplevel functions, static methods, and class instantiations is that there are already well-defined rules for inferring type arguments in invocations (we look at the argument types).

However, it's clear that in an invocation like this, where no argument is ever assigned to the type parameter, that our type argument inference algorithm is useless.

So perhaps we could adjust it to take usage into account, at least in the case of an invariant type parameter.

Need to think this through properly.

So my solution is to basically treat nullary function invocation like fun() or Foo.bar() more like how I treat a reference like fun or Foo.bar for the purposes of type inference. The intuition behind this is that the arguments of a nullary invocation are "useless" for the purposes of type inference (because there aren't any of them)!

For now this only goes one level deep (i.e. it works for fun() but not for fun()()) which seems perfectly fine to me.

Also it is only for function invocations, not for class instantiations, but that might be wrong.

Note that this is really only useful for Java interop, since I don't really know of any very good reason to use this pattern in Ceylon.

Also it is only for function invocations, not for class instantiations, but that might be wrong.

I suppose one place this could be useful is here:

whatever.setMutableStringList(ArrayList())

I'll give that some consideration.

Alright, done, at least well enough for now. Closing.