Does not pertinent to applicability mean not used?

[Zhong Yu]

On Tue, Apr 29, 2014 at 3:47 PM, Timo Kinnunen <timo.kinnunen at gmail.com> wrote:
> Hi,
>
>
> This code shows a difference in type inference between ECJ and Javac:
>
>
> package differences.lost.typing;
>
> import java.util.List;
>
> import java.util.Map;
>
> import java.util.stream.Collector;
>
> import java.util.stream.Stream;
>
>
> class DoesNotPertinentMeanNotUsed {
>
> Stream<Stream<String>> s;
>
> Collector<String, ?, Map<String, List<String>>> c;
>
>
> Map<String, List<String>> versionWithError() {
>
> return s.flatMap(t -> t.map(item -> t + item)).collect(c);
>
> }
>
> Map<String, List<String>> versionWithoutError() {
>
> return s.flatMap(t -> t.map((String item) -> t + item)).collect(c);
>
> }
>
> }
>
>
> Javac compiles both versions without error messages, ECJ infers the return type of the .flatMap() method call in the first version to be something like Stream<?> which results in a compile error in the call to .collect().
>
>
> In the versionWithError, the inner lambda expression’s (item -> t + item) type is inexact which means it’s not pertinent to applicability for the call to .map(). I am told this is means it doesn’t affect the inferred return type of .map() method call, leaving it unknown, thus making this code invalid, correctly.

I would expect the code is valid. We expect that something like this
should work:

    Function<Integer, Function<Integer, Integer>> f = x->y->x+y;

i.e. the target type propagates inwards, y is determined to be Integer.

>
>
> In the versionWithoutError, the inner lambda expression ((String) item -> t + item) can be pertinent to applicability so it’s type constraints are considered, leading eventually to the type Stream<String> coming out at the other end, and the code being valid.
>
>
> Which compiler is correct, and why?
>
>
>
>
>
>
>
>
>
> --
> Have a nice day,
> Timo.
>
> Sent from Windows Mail
>