目标类型具有通配符时的泛型方法类型推断

Question

我知道编译器使用目标类型来确定使泛型方法调用适用的类型参数。例如，在以下声明中：

List<String> listOne = Collections.emptyList();

其中集合。emptyList的签名中有一个类型参数T

public static final <T> List<T> emptyList() {

在本例中，T的推断类型参数是String。

现在考虑以下几点：

List<?> listTwo = Collections.emptyList();

这种情况下的推断类型是什么？它是对象吗？或者因为通配符告诉编译器任何类型都是可能的，所以这并不重要？




Answer 1

在这种情况下，推断的类型是什么？是Object吗？还是因为通配符告诉编译器任何类型都是可能的，所以这并不重要？

在某种程度上，这是一个哲学问题，因为类型参数对编译的字节码没有任何影响，所以具体是什么并不重要。唯一重要的是它是否不可能满足边界和上下文。只要编译器能够证明存在某种可以工作的类型，那么在我看来，它应该能够继续编译，而不需要拿出实际的类型。

Answer 2

通配符的每次使用都有一个与之关联的独特类型。（通常JLS称之为“新鲜型”。）例如，这样的编译器错误就是这样工作的：

List<?> list0 = ... ;
List<?> list1 = ... ;
list0.add(list1.get(0)); // error

因为在这种情况下，编译器会给list0和list1单独的类型

reference_type_of(List<?>) != reference_type_of(List<?>)

如果您尝试以下方法，您可以开始了解这如何适用于类型推断

{
    List<?> list0 = ... ;
    List<?> list1 = ... ;
    test(list0, list1);
}
static <T> void test(List<T> list0, List<T> list1) {}

其中，编译器发出一个错误，实际上告诉我们一点它为list0和list1生成的类型。

error: method test in class Ideone cannot be applied to given types;
    test(list0, list1);
    ^
  required: List<T>,List<T>
  found: List<CAP#1>,List<CAP#2>
  reason: no instance(s) of type variable(s) T exist so that
          argument type List<CAP#2> conforms to formal parameter type List<T>
  where T is a type-variable:
    T extends Object declared in method <T>test(List<T>,List<T>)
  where CAP#1,CAP#2 are fresh type-variables:
    CAP#1 extends Object from capture of ?
    CAP#2 extends Object from capture of ?

（我用粗体强调。）这些CAP# 类型是在捕获转换期间生成的。它向我们展示的是，当检查方法调用表达式时，list0和list1被赋予了彼此不同的类型。（对于那些需要解释错误的人：这是因为test声明声明两个列表必须具有相同的T）

既然我们现在知道一个通配符与一个引用类型相关联，我们可以在下面的例子中看到

List<?> empty = Collections.emptyList();

调用将被推断为“一个上限为Object的新类型”。或者象征性地说，编译器可能会看到

// target type       -->       inferred invocation type
//     v                           v
List<CAP#1> empty = Collections.<CAP#1>emptyList();

虽然：当然，我们总是有点猜测，因为这取决于编译器如何实现它。理论上，对于像上面的emptyList（）的琐碎赋值这样的情况，它不需要做工作来生成正确的字节码。

还有，对不起，我今天不想去。本质上，这里的类型推断是通过生成一组约束来证明方法调用应该编译还是不应该编译。18.5.2中描述的算法以这种方式合并了一个通配符