在像Stream.Reduce（）这样的API中选择不变性有什么好的理由？

Question

回顾Java 8streamAPI设计时，我对stream.reduce()参数的泛型不变性感到惊讶：

<U> U reduce(U identity,
             BiFunction<U,? super T,U> accumulator,
             BinaryOperator<U> combiner)

同一个API的一个看起来更通用的版本可能已经在对u的单独引用上应用了协方差/逆方差，例如：

<U> U reduce(U identity,
             BiFunction<? super U, ? super T, ? extends U> accumulator,
             BiFunction<? super U, ? super U, ? extends U> combiner)

这将允许当前不可能的以下操作：

// Assuming we want to reuse these tools all over the place:
BiFunction<Number, Number, Double> numberAdder =
    (t, u) -> t.doubleValue() + u.doubleValue();

// This currently doesn't work, but would work with the suggestion
Stream<Number> stream = Stream.of(1, 2L, 3.0);
double sum = stream.reduce(0.0, numberAdder, numberAdder);

解决办法是使用方法引用将类型“强制”为目标类型：

double sum = stream.reduce(0.0, numberAdder::apply, numberAdder::apply);

C#没有这个特殊的问题，因为func(T1,T2,TResult)定义如下，使用声明-站点方差，这意味着任何使用func的API都可以免费获得这个行为：

public delegate TResult Func<in T1, in T2, out TResult>(
    T1 arg1,
    T2 arg2
)

与建议的设计相比，现有的设计有什么优势（以及可能的，决策的原因）？

或者，不同的问题是，我可能会忽略的建议设计的注意事项是什么（例如，类型推断困难、并行化约束，或者特定于约简操作的约束，例如，关联性、对双函数 的未来Java声明站点差异的预期，...)？

Answer 1

在lambda开发的历史中爬行并分离出这个决定的“”原因是很困难的--所以最终，我们将不得不等待其中一个开发人员回答这个问题。

一些提示可能如下：

>

流接口经历了几次迭代和重构。在stream接口的最早版本之一中，有专门的reduce方法，而与问题中的reduce方法最接近的那个方法当时仍称为stream#fold。这一个已接收到BinaryOperator作为Combiner参数。

有趣的是，有一段时间，lambda建议包含了一个专用接口组合器 。与直觉相反的是，它没有用作流#reduce函数中的组合器。相反，它被用作reducer，这似乎就是现在所说的accumulator。但是，在后来的版本中，组合器接口被双功能所取代。

与这里的问题最惊人的相似点是在邮件列表中关于stream#flatmap签名的一个线程中发现的，然后这个线程就变成了关于stream方法签名的变化的一般问题。他们把这些固定在一些地方，例如

正如Brian纠正我：

stream flatMap（函数<？super T，？extends stream<？extends r>>映射器）；

而不是：

stream flatMap（函数 >映射器）；

而且

可选 reduce(BinaryOperator accumulator)；

因为他们使用了“binaryoperator”，所以无法修复，但是如果使用了“bifunction”，那么我们就有了更多的灵活性

而不是：

U reduce(U恒等式，bifunction 累加器，binaryoperator 组合器）；

关于“BinaryOperator”的相同注释