推断通用类型的嵌套静态泛型函数

Question

Java编译器能否从其上下文推断泛型静态函数的类型作为另一个通用静态函数的参数？

例如,我有一个简单的Pair类:

public class Pair<F, S> {

    private final F mFirst;

    private final S mSecond;

    public Pair(F first, S second) {
        mFirst  = checkNotNull(first);
        mSecond = checkNotNull(second);
    }

    public static <F, S, F1 extends F, S1 extends S> Pair<F, S> of(F1 first, S1 second) {
        return new Pair<F, S>(first, second);
    }

    public F first() {
        return mFirst;
    }

    public S second() {
        return mSecond;
    }

    // ...
}

我有以下通用静态函数:

public static <F, P extends Pair<F, ?>> Function<P, F> deferredFirst() {
    return (Function<P, F>)DEFERRED_FIRST;
}

private static final Function<Pair<Object, ?>, Object> DEFERRED_FIRST = 
        new Function<Pair<Object,?>, Object>() {

    @Override
    public Object apply(Pair<Object, ?> input) {
        return input.first();
    }
};

我希望使用如下(Collections2.transform来自Google Guava):

List<Pair<Integer, Double>> values = ...
Collection<Integer> firsts = Collections2.transform(values, 
        Pair.deferredFirst());

编译器抱怨的内容:

The method transform(Collection<F>, Function<? super F,T>) in the type 
Collections2 is not applicable for the arguments 
(List<Pair<Integer,Double>>, Function<Pair<Object,?>,Object>)

因此,似乎编译器无法将为transform()推断的类型传播到deferredFirst(),因为它认为它们是对象.

强制编译器以这两种方式之一理解类型:

Function<Pair<Integer, ?>, Integer> func = Pair.deferredFirst();
Collection<Integer> firsts = Collections2.transform(values, func);


Collection<Integer> firsts = Collections2.transform(values, 
        Pair.<Integer, Pair<Integer, ?>>deferredFirst());

是否可以更改任一函数的签名以允许编译器推断/传播类型？

编辑:对于波西米亚语,这是一个可能的方法,上面的例子可用于:

public static int sumSomeInts(List<Pair<Integer, Double>> values) {
    Collection<Integer> ints = Collections2.transform(values, 
            Pair.deferredFirst());
    int sum = 0;
    for(int i : ints)
        sum += i;
    return sum;
}

Answer 1

类型推断是令人讨厌且复杂的。他们必须在某个地方停下来。考虑

static <T> T foo();

String s = foo();

print( foo() )

在赋值上下文中，程序员的意图很明确， T应该是String

在下一行中，没有那么多。

该print方法不是一个非常公平的示例，它严重过载。假设print没有重载，它的参数类型是固定的，所以T可以清楚地推断出来。编译器不应该足够聪明来解决这个问题吗？

这听起来很合理，直到有人冒险阅读相关的规范文本，15.12 方法调用表达式祝你好运，改变混乱中的任何东西！

它太复杂了，连编译器作者都看不懂。javac 和其他编译器中存在大量源于规范这一部分的错误。