为什么类型参数比方法参数强
Why is a type parameter stronger then a method parameter
为什么是
public <R, F extends Function<T, R>> Builder<T> withX(F getter, R returnValue) {...}
比
更严格
public <R> Builder<T> with(Function<T, R> getter, R returnValue) {...}
这是 的跟进。
我发现使用方法 withX() like
.withX(MyInterface::getLength, "I am not a Long")
产生所需的编译时错误：
The type of getLength() from the type BuilderExample.MyInterface is long, this is incompatible with the descriptor's return type: String
使用方法 with() 则不会。
完整示例：
import java.util.function.Function;
public class SO58376589 {
public static class Builder<T> {
public <R, F extends Function<T, R>> Builder<T> withX(F getter, R returnValue) {
return this;
}
public <R> Builder<T> with(Function<T, R> getter, R returnValue) {
return this;
}
}
static interface MyInterface {
public Long getLength();
}
public static void main(String[] args) {
Builder<MyInterface> b = new Builder<MyInterface>();
Function<MyInterface, Long> getter = MyInterface::getLength;
b.with(getter, 2L);
b.with(MyInterface::getLength, 2L);
b.withX(getter, 2L);
b.withX(MyInterface::getLength, 2L);
b.with(getter, "No NUMBER"); // error
b.with(MyInterface::getLength, "No NUMBER"); // NO ERROR !!
b.withX(getter, "No NUMBER"); // error
b.withX(MyInterface::getLength, "No NUMBER"); // error !!!
}
}
javac SO58376589.java
SO58376589.java:32: error: method with in class Builder<T> cannot be applied to given types;
b.with(getter, "No NUMBER"); // error
^
required: Function<MyInterface,R>,R
found: Function<MyInterface,Long>,String
reason: inference variable R has incompatible bounds
equality constraints: Long
lower bounds: String
where R,T are type-variables:
R extends Object declared in method <R>with(Function<T,R>,R)
T extends Object declared in class Builder
SO58376589.java:34: error: method withX in class Builder<T> cannot be applied to given types;
b.withX(getter, "No NUMBER"); // error
^
required: F,R
found: Function<MyInterface,Long>,String
reason: inference variable R has incompatible bounds
equality constraints: Long
lower bounds: String
where F,R,T are type-variables:
F extends Function<MyInterface,R> declared in method <R,F>withX(F,R)
R extends Object declared in method <R,F>withX(F,R)
T extends Object declared in class Builder
SO58376589.java:35: error: incompatible types: cannot infer type-variable(s) R,F
b.withX(MyInterface::getLength, "No NUMBER"); // error
^
(argument mismatch; bad return type in method reference
Long cannot be converted to String)
where R,F,T are type-variables:
R extends Object declared in method <R,F>withX(F,R)
F extends Function<T,R> declared in method <R,F>withX(F,R)
T extends Object declared in class Builder
3 errors
扩展示例
以下示例显示归结为供应商的方法和类型参数的不同行为。此外，它还显示了类型参数与消费者行为的区别。它表明无论是方法参数的消费者还是供应商都没有区别。
import java.util.function.Consumer;
import java.util.function.Supplier;
interface TypeInference {
Number getNumber();
void setNumber(Number n);
@FunctionalInterface
interface Method<R> {
TypeInference be(R r);
}
//Supplier:
<R> R letBe(Supplier<R> supplier, R value);
<R, F extends Supplier<R>> R letBeX(F supplier, R value);
<R> Method<R> let(Supplier<R> supplier); // return (x) -> this;
//Consumer:
<R> R lettBe(Consumer<R> supplier, R value);
<R, F extends Consumer<R>> R lettBeX(F supplier, R value);
<R> Method<R> lett(Consumer<R> consumer);
public static void main(TypeInference t) {
t.letBe(t::getNumber, (Number) 2); // Compiles :-)
t.lettBe(t::setNumber, (Number) 2); // Compiles :-)
t.letBe(t::getNumber, 2); // Compiles :-)
t.lettBe(t::setNumber, 2); // Compiles :-)
t.letBe(t::getNumber, "NaN"); // !!!! Compiles :-(
t.lettBe(t::setNumber, "NaN"); // Does not compile :-)
t.letBeX(t::getNumber, (Number) 2); // Compiles :-)
t.lettBeX(t::setNumber, (Number) 2); // Compiles :-)
t.letBeX(t::getNumber, 2); // !!! Does not compile :-(
t.lettBeX(t::setNumber, 2); // Compiles :-)
t.letBeX(t::getNumber, "NaN"); // Does not compile :-)
t.lettBeX(t::setNumber, "NaN"); // Does not compile :-)
t.let(t::getNumber).be(2); // Compiles :-)
t.lett(t::setNumber).be(2); // Compiles :-)
t.let(t::getNumber).be("NaN"); // Does not compile :-)
t.lett(t::setNumber).be("NaN"); // Does not compile :-)
}
}
这是一个非常有趣的问题。恐怕答案很复杂。
tl;博士
找出差异需要深入阅读 Java 的 type inference specification，但基本上可以归结为：
- 所有其他条件相同，编译器会推断出它可以最具体的类型。
- 但是，如果它能找到a替换满足所有要求的类型参数，那么编译就会成功，但是模糊替换结果是。
- 对于
with 有一个（公认的模糊的）替代满足 R 的所有要求：Serializable
- 对于
withX，额外类型参数F的引入强制编译器首先解析R，而不考虑约束F extends Function<T,R>。 R 解析为（更具体的）String，这意味着 F 的推理失败。
这最后一个要点是最重要的，但也是最复杂的。我想不出更简洁的措辞方式，所以如果您想了解更多详细信息，我建议您阅读下面的完整解释。
这是有意为之的行为吗？
我要在这里冒险，然后说不。
我并不是说规范中存在错误，更多的是（在 withX 的情况下）语言设计者举手说 "there are some situations where type inference gets too hard, so we'll just fail" 。尽管编译器关于 withX 的行为似乎是您想要的，但我认为这是当前规范的附带副作用，而不是一个积极的设计决策。
这很重要，因为它提出了问题我应该在我的应用程序设计中依赖这种行为吗？我认为你不应该，因为你不能保证该语言的未来版本将继续以这种方式运行。
虽然语言设计者在更新 spec/design/compiler 时确实非常努力地尝试不破坏现有应用程序，但问题是您想要依赖的行为是编译器当前 失败（即不是现有应用程序）。语言更新始终将非编译代码转换为编译代码。例如，下面的代码可以 保证 不会在 Java 7 中编译，但 会 在 Java 8 中编译:
static Runnable x = () -> System.out.println();
您的用例也不例外。
我对使用您的 withX 方法持谨慎态度的另一个原因是 F 参数本身。通常， 方法 上的泛型类型参数（未出现在 return 类型中）用于将签名的多个部分的类型绑定在一起。它在说：
我不关心 T 是什么，但我想确保无论我在哪里使用 T 它都是同一类型。
那么从逻辑上讲，我们希望每个类型参数在方法签名中至少出现两次，否则 "it's not doing anything"。 F 在你的 withX 中只在签名中出现一次，这向我建议使用不与语言此功能的 intent 内联的类型参数.
另一种实现方式
一种以稍微 "intended behaviour" 的方式实现它的方法是将您的 with 方法分成 2 个链：
public class Builder<T> {
public final class With<R> {
private final Function<T,R> method;
private With(Function<T,R> method) {
this.method = method;
}
public Builder<T> of(R value) {
// TODO: Body of your old 'with' method goes here
return Builder.this;
}
}
public <R> With<R> with(Function<T,R> method) {
return new With<>(method);
}
}
然后可以按如下方式使用：
b.with(MyInterface::getLong).of(1L); // Compiles
b.with(MyInterface::getLong).of("Not a long"); // Compiler error
这不像您的 withX 那样包含无关的类型参数。通过将方法分解为两个签名，从类型安全的角度来看，它还可以更好地表达您要执行的操作的意图：
- 第一个方法设置一个 class (
With)，定义 基于方法引用的类型。
- 第二种方法 (
of) 约束 value 的类型与您之前设置的兼容。
该语言的未来版本能够编译它的唯一方法是实现完整的鸭子类型，这似乎不太可能。
最后一点让整个事情变得无关紧要： 我认为 Mockito（尤其是它的存根功能）可能基本上已经做了什么您正在尝试通过 "type safe generic builder" 实现。也许你可以用那个代替？
完整（大概）解释
我将完成 with 和 withX 的 type inference procedure。这篇很长，慢慢来吧。尽管很长，但我仍然遗漏了很多细节。您可能希望参考规范以获取更多详细信息（点击链接）以说服自己我是对的（我很可能犯了一个错误）。
此外，为了稍微简化一下，我将使用更精简的代码示例。主要区别在于它将 Function 换成了 Supplier，因此使用的类型和参数更少。这是重现您描述的行为的完整代码段：
public class TypeInference {
static long getLong() { return 1L; }
static <R> void with(Supplier<R> supplier, R value) {}
static <R, F extends Supplier<R>> void withX(F supplier, R value) {}
public static void main(String[] args) {
with(TypeInference::getLong, "Not a long"); // Compiles
withX(TypeInference::getLong, "Also not a long"); // Does not compile
}
}
让我们依次完成每个方法调用的类型 applicability inference and type inference 过程：
with
我们有：
with(TypeInference::getLong, "Not a long");
初始边界集，B0，是：
R <: Object
所有参数表达式都是pertinent to applicability.
因此，applicability inference、C的初始约束集为：
TypeInference::getLong 兼容 Supplier<R>"Not a long" 兼容 R
此 reduces 绑定集合 B2 of:
R <: Object（来自B0）Long <: R（来自第一个约束）String <: R（来自第二个约束）
因为这不包含绑定 'false'，并且（我假设）R 的 resolution 成功（给出 Serializable )，则调用适用。
所以，我们继续invocation type inference。
新的约束集，C，以及关联的 input 和 output 变量，是:
TypeInference::getLong 兼容 Supplier<R>
- 输入变量：none
- 输出变量：
R
这不包含 输入 和 输出 变量之间的相互依赖性，因此可以 减少一步完成，最终的边界集B4与[=255相同=]B2。于是，resolution照样成功，编译器松了一口气！
withX
我们有：
withX(TypeInference::getLong, "Also not a long");
初始边界集，B0，是：
R <: ObjectF <: Supplier<R>
只有第二个参数表达式是pertinent to applicability。第一个（TypeInference::getLong）不是，因为它满足以下条件：
If m is a generic method and the method invocation does not provide explicit type arguments, an explicitly typed lambda expression or an exact method reference expression for which the corresponding target type (as derived from the signature of m) is a type parameter of m.
因此，applicability inference、C的初始约束集为：
"Also not a long" 兼容 R
此 reduces 绑定集合 B2 of:
R <: Object（来自B0）F <: Supplier<R>（来自B0）String <: R（来自约束）
同样，由于这不包含绑定 'false'，并且 R 的 resolution 成功（给出 String），那么调用是适用的。
Invocation type inference 再一次...
这一次，新的约束集，C，以及关联的输入和输出变量，是：
TypeInference::getLong 兼容 F
- 输入变量：
F
- 输出变量：none
同样，我们在 input 和 output 变量之间没有相互依赖关系。然而这次，是一个输入变量（F），所以我们必须resolve this before attempting reduction。因此，我们从边界集 B2.
开始
我们确定一个子集V如下：
Given a set of inference variables to resolve, let V be the union of this set and all variables upon which the resolution of at least one variable in this set depends.
由B2中的第二个边界，F的分辨率取决于R，所以V := {F, R}.
我们根据规则选取V的一个子集：
let { α1, ..., αn } be a non-empty subset of uninstantiated variables in V such that i) for all i (1 ≤ i ≤ n), if αi depends on the resolution of a variable β, then either β has an instantiation or there is some j such that β = αj; and ii) there exists no non-empty proper subset of { α1, ..., αn } with this property.
满足此 属性 的 V 的唯一子集是 {R}。
我们使用第三个边界 (String <: R) 实例化 R = String 并将其合并到我们的边界集中。 R 现在已解决，第二个边界实际上变为 F <: Supplier<String>.
使用（修改后的）第二个边界，我们实例化 F = Supplier<String>。 F现已解决。
现在F已经解决了，我们可以继续reduction，使用新的约束：
TypeInference::getLong 兼容 Supplier<String>- ...减少到
Long 兼容 String
- ...减少到 false
...我们得到一个编译器错误！
关于 'Extended Example'
的补充说明
问题中的 扩展示例 着眼于一些有趣的案例，这些案例没有直接包含在上面的工作中：
- 其中值类型是方法return类型的子类型 (
Integer <: Number)
- 其中功能接口在推断类型中是逆变的（即
Consumer 而不是 Supplier）
特别是，3 个给定的调用脱颖而出，可能暗示 'different' 解释中描述的编译器行为：
t.lettBe(t::setNumber, "NaN"); // Does not compile :-)
t.letBeX(t::getNumber, 2); // !!! Does not compile :-(
t.lettBeX(t::setNumber, 2); // Compiles :-)
这 3 个中的第二个将经历与上面 withX 完全相同的推理过程（只需将 Long 替换为 Number 并将 String 替换为 Integer).这说明了为什么你不应该在你的 class 设计中依赖这种失败的类型推断行为的另一个原因，因为这里的编译失败可能 不是 一个理想的行为。
对于其他 2 个（实际上任何其他涉及您希望完成的 Consumer 的调用），如果您完成为其中一个设置的类型推断过程，则行为应该是显而易见的上面的方法（即第一个 with，第三个 withX）。您只需要注意一个小变化：
- 第一个参数的约束（
t::setNumber 兼容 Consumer<R>）将reduce改为R <: Number而不是Number <: R 就像 Supplier<R> 一样。这在有关减少的链接文档中进行了描述。
我把它作为 reader 的练习留给 reader 来仔细完成上述过程之一，并利用这些额外的知识向自己证明特定调用执行或不执行的确切原因编译.
为什么是
public <R, F extends Function<T, R>> Builder<T> withX(F getter, R returnValue) {...}
比
更严格public <R> Builder<T> with(Function<T, R> getter, R returnValue) {...}
这是 withX() like
.withX(MyInterface::getLength, "I am not a Long")
产生所需的编译时错误：
The type of getLength() from the type BuilderExample.MyInterface is long, this is incompatible with the descriptor's return type: String
使用方法 with() 则不会。
完整示例：
import java.util.function.Function;
public class SO58376589 {
public static class Builder<T> {
public <R, F extends Function<T, R>> Builder<T> withX(F getter, R returnValue) {
return this;
}
public <R> Builder<T> with(Function<T, R> getter, R returnValue) {
return this;
}
}
static interface MyInterface {
public Long getLength();
}
public static void main(String[] args) {
Builder<MyInterface> b = new Builder<MyInterface>();
Function<MyInterface, Long> getter = MyInterface::getLength;
b.with(getter, 2L);
b.with(MyInterface::getLength, 2L);
b.withX(getter, 2L);
b.withX(MyInterface::getLength, 2L);
b.with(getter, "No NUMBER"); // error
b.with(MyInterface::getLength, "No NUMBER"); // NO ERROR !!
b.withX(getter, "No NUMBER"); // error
b.withX(MyInterface::getLength, "No NUMBER"); // error !!!
}
}
javac SO58376589.java
SO58376589.java:32: error: method with in class Builder<T> cannot be applied to given types;
b.with(getter, "No NUMBER"); // error
^
required: Function<MyInterface,R>,R
found: Function<MyInterface,Long>,String
reason: inference variable R has incompatible bounds
equality constraints: Long
lower bounds: String
where R,T are type-variables:
R extends Object declared in method <R>with(Function<T,R>,R)
T extends Object declared in class Builder
SO58376589.java:34: error: method withX in class Builder<T> cannot be applied to given types;
b.withX(getter, "No NUMBER"); // error
^
required: F,R
found: Function<MyInterface,Long>,String
reason: inference variable R has incompatible bounds
equality constraints: Long
lower bounds: String
where F,R,T are type-variables:
F extends Function<MyInterface,R> declared in method <R,F>withX(F,R)
R extends Object declared in method <R,F>withX(F,R)
T extends Object declared in class Builder
SO58376589.java:35: error: incompatible types: cannot infer type-variable(s) R,F
b.withX(MyInterface::getLength, "No NUMBER"); // error
^
(argument mismatch; bad return type in method reference
Long cannot be converted to String)
where R,F,T are type-variables:
R extends Object declared in method <R,F>withX(F,R)
F extends Function<T,R> declared in method <R,F>withX(F,R)
T extends Object declared in class Builder
3 errors
扩展示例
以下示例显示归结为供应商的方法和类型参数的不同行为。此外，它还显示了类型参数与消费者行为的区别。它表明无论是方法参数的消费者还是供应商都没有区别。
import java.util.function.Consumer;
import java.util.function.Supplier;
interface TypeInference {
Number getNumber();
void setNumber(Number n);
@FunctionalInterface
interface Method<R> {
TypeInference be(R r);
}
//Supplier:
<R> R letBe(Supplier<R> supplier, R value);
<R, F extends Supplier<R>> R letBeX(F supplier, R value);
<R> Method<R> let(Supplier<R> supplier); // return (x) -> this;
//Consumer:
<R> R lettBe(Consumer<R> supplier, R value);
<R, F extends Consumer<R>> R lettBeX(F supplier, R value);
<R> Method<R> lett(Consumer<R> consumer);
public static void main(TypeInference t) {
t.letBe(t::getNumber, (Number) 2); // Compiles :-)
t.lettBe(t::setNumber, (Number) 2); // Compiles :-)
t.letBe(t::getNumber, 2); // Compiles :-)
t.lettBe(t::setNumber, 2); // Compiles :-)
t.letBe(t::getNumber, "NaN"); // !!!! Compiles :-(
t.lettBe(t::setNumber, "NaN"); // Does not compile :-)
t.letBeX(t::getNumber, (Number) 2); // Compiles :-)
t.lettBeX(t::setNumber, (Number) 2); // Compiles :-)
t.letBeX(t::getNumber, 2); // !!! Does not compile :-(
t.lettBeX(t::setNumber, 2); // Compiles :-)
t.letBeX(t::getNumber, "NaN"); // Does not compile :-)
t.lettBeX(t::setNumber, "NaN"); // Does not compile :-)
t.let(t::getNumber).be(2); // Compiles :-)
t.lett(t::setNumber).be(2); // Compiles :-)
t.let(t::getNumber).be("NaN"); // Does not compile :-)
t.lett(t::setNumber).be("NaN"); // Does not compile :-)
}
}
这是一个非常有趣的问题。恐怕答案很复杂。
tl;博士
找出差异需要深入阅读 Java 的 type inference specification，但基本上可以归结为：
- 所有其他条件相同，编译器会推断出它可以最具体的类型。
- 但是，如果它能找到a替换满足所有要求的类型参数，那么编译就会成功，但是模糊替换结果是。
- 对于
with有一个（公认的模糊的）替代满足R的所有要求：Serializable - 对于
withX，额外类型参数F的引入强制编译器首先解析R，而不考虑约束F extends Function<T,R>。R解析为（更具体的）String，这意味着F的推理失败。
这最后一个要点是最重要的，但也是最复杂的。我想不出更简洁的措辞方式，所以如果您想了解更多详细信息，我建议您阅读下面的完整解释。
这是有意为之的行为吗？
我要在这里冒险，然后说不。
我并不是说规范中存在错误，更多的是（在 withX 的情况下）语言设计者举手说 "there are some situations where type inference gets too hard, so we'll just fail" 。尽管编译器关于 withX 的行为似乎是您想要的，但我认为这是当前规范的附带副作用，而不是一个积极的设计决策。
这很重要，因为它提出了问题我应该在我的应用程序设计中依赖这种行为吗？我认为你不应该，因为你不能保证该语言的未来版本将继续以这种方式运行。
虽然语言设计者在更新 spec/design/compiler 时确实非常努力地尝试不破坏现有应用程序，但问题是您想要依赖的行为是编译器当前 失败（即不是现有应用程序）。语言更新始终将非编译代码转换为编译代码。例如，下面的代码可以 保证 不会在 Java 7 中编译，但 会 在 Java 8 中编译:
static Runnable x = () -> System.out.println();
您的用例也不例外。
我对使用您的 withX 方法持谨慎态度的另一个原因是 F 参数本身。通常， 方法 上的泛型类型参数（未出现在 return 类型中）用于将签名的多个部分的类型绑定在一起。它在说：
我不关心 T 是什么，但我想确保无论我在哪里使用 T 它都是同一类型。
那么从逻辑上讲，我们希望每个类型参数在方法签名中至少出现两次，否则 "it's not doing anything"。 F 在你的 withX 中只在签名中出现一次，这向我建议使用不与语言此功能的 intent 内联的类型参数.
另一种实现方式
一种以稍微 "intended behaviour" 的方式实现它的方法是将您的 with 方法分成 2 个链：
public class Builder<T> {
public final class With<R> {
private final Function<T,R> method;
private With(Function<T,R> method) {
this.method = method;
}
public Builder<T> of(R value) {
// TODO: Body of your old 'with' method goes here
return Builder.this;
}
}
public <R> With<R> with(Function<T,R> method) {
return new With<>(method);
}
}
然后可以按如下方式使用：
b.with(MyInterface::getLong).of(1L); // Compiles
b.with(MyInterface::getLong).of("Not a long"); // Compiler error
这不像您的 withX 那样包含无关的类型参数。通过将方法分解为两个签名，从类型安全的角度来看，它还可以更好地表达您要执行的操作的意图：
- 第一个方法设置一个 class (
With)，定义 基于方法引用的类型。 - 第二种方法 (
of) 约束value的类型与您之前设置的兼容。
该语言的未来版本能够编译它的唯一方法是实现完整的鸭子类型，这似乎不太可能。
最后一点让整个事情变得无关紧要： 我认为 Mockito（尤其是它的存根功能）可能基本上已经做了什么您正在尝试通过 "type safe generic builder" 实现。也许你可以用那个代替？
完整（大概）解释
我将完成 with 和 withX 的 type inference procedure。这篇很长，慢慢来吧。尽管很长，但我仍然遗漏了很多细节。您可能希望参考规范以获取更多详细信息（点击链接）以说服自己我是对的（我很可能犯了一个错误）。
此外，为了稍微简化一下，我将使用更精简的代码示例。主要区别在于它将 Function 换成了 Supplier，因此使用的类型和参数更少。这是重现您描述的行为的完整代码段：
public class TypeInference {
static long getLong() { return 1L; }
static <R> void with(Supplier<R> supplier, R value) {}
static <R, F extends Supplier<R>> void withX(F supplier, R value) {}
public static void main(String[] args) {
with(TypeInference::getLong, "Not a long"); // Compiles
withX(TypeInference::getLong, "Also not a long"); // Does not compile
}
}
让我们依次完成每个方法调用的类型 applicability inference and type inference 过程：
with
我们有：
with(TypeInference::getLong, "Not a long");
初始边界集，B0，是：
R <: Object
所有参数表达式都是pertinent to applicability.
因此，applicability inference、C的初始约束集为：
TypeInference::getLong兼容Supplier<R>"Not a long"兼容R
此 reduces 绑定集合 B2 of:
R <: Object（来自B0）Long <: R（来自第一个约束）String <: R（来自第二个约束）
因为这不包含绑定 'false'，并且（我假设）R 的 resolution 成功（给出 Serializable )，则调用适用。
所以，我们继续invocation type inference。
新的约束集，C，以及关联的 input 和 output 变量，是:
TypeInference::getLong兼容Supplier<R>- 输入变量：none
- 输出变量：
R
这不包含 输入 和 输出 变量之间的相互依赖性，因此可以 减少一步完成，最终的边界集B4与[=255相同=]B2。于是，resolution照样成功，编译器松了一口气！
withX
我们有：
withX(TypeInference::getLong, "Also not a long");
初始边界集，B0，是：
R <: ObjectF <: Supplier<R>
只有第二个参数表达式是pertinent to applicability。第一个（TypeInference::getLong）不是，因为它满足以下条件：
If
mis a generic method and the method invocation does not provide explicit type arguments, an explicitly typed lambda expression or an exact method reference expression for which the corresponding target type (as derived from the signature ofm) is a type parameter ofm.
因此，applicability inference、C的初始约束集为：
"Also not a long"兼容R
此 reduces 绑定集合 B2 of:
R <: Object（来自B0）F <: Supplier<R>（来自B0）String <: R（来自约束）
同样，由于这不包含绑定 'false'，并且 R 的 resolution 成功（给出 String），那么调用是适用的。
Invocation type inference 再一次...
这一次，新的约束集，C，以及关联的输入和输出变量，是：
TypeInference::getLong兼容F- 输入变量：
F - 输出变量：none
- 输入变量：
同样，我们在 input 和 output 变量之间没有相互依赖关系。然而这次，是一个输入变量（F），所以我们必须resolve this before attempting reduction。因此，我们从边界集 B2.
我们确定一个子集
V如下：Given a set of inference variables to resolve, let
Vbe the union of this set and all variables upon which the resolution of at least one variable in this set depends.由B2中的第二个边界，
F的分辨率取决于R，所以V := {F, R}.我们根据规则选取
V的一个子集：let
{ α1, ..., αn }be a non-empty subset of uninstantiated variables inVsuch that i) for alli (1 ≤ i ≤ n), ifαidepends on the resolution of a variableβ, then eitherβhas an instantiation or there is somejsuch thatβ = αj; and ii) there exists no non-empty proper subset of{ α1, ..., αn }with this property.满足此 属性 的
V的唯一子集是{R}。我们使用第三个边界 (
String <: R) 实例化R = String并将其合并到我们的边界集中。R现在已解决，第二个边界实际上变为F <: Supplier<String>.使用（修改后的）第二个边界，我们实例化
F = Supplier<String>。F现已解决。
现在F已经解决了，我们可以继续reduction，使用新的约束：
TypeInference::getLong兼容Supplier<String>- ...减少到
Long兼容String - ...减少到 false
...我们得到一个编译器错误！
关于 'Extended Example'
的补充说明问题中的 扩展示例 着眼于一些有趣的案例，这些案例没有直接包含在上面的工作中：
- 其中值类型是方法return类型的子类型 (
Integer <: Number) - 其中功能接口在推断类型中是逆变的（即
Consumer而不是Supplier）
特别是，3 个给定的调用脱颖而出，可能暗示 'different' 解释中描述的编译器行为：
t.lettBe(t::setNumber, "NaN"); // Does not compile :-)
t.letBeX(t::getNumber, 2); // !!! Does not compile :-(
t.lettBeX(t::setNumber, 2); // Compiles :-)
这 3 个中的第二个将经历与上面 withX 完全相同的推理过程（只需将 Long 替换为 Number 并将 String 替换为 Integer).这说明了为什么你不应该在你的 class 设计中依赖这种失败的类型推断行为的另一个原因，因为这里的编译失败可能 不是 一个理想的行为。
对于其他 2 个（实际上任何其他涉及您希望完成的 Consumer 的调用），如果您完成为其中一个设置的类型推断过程，则行为应该是显而易见的上面的方法（即第一个 with，第三个 withX）。您只需要注意一个小变化：
- 第一个参数的约束（
t::setNumber兼容Consumer<R>）将reduce改为R <: Number而不是Number <: R就像Supplier<R>一样。这在有关减少的链接文档中进行了描述。
我把它作为 reader 的练习留给 reader 来仔细完成上述过程之一，并利用这些额外的知识向自己证明特定调用执行或不执行的确切原因编译.