在诸如Stream.reduce（）之类的API中选择不变性的充分理由是什么？

Question

回顾Java 8
StreamAPI设计，我对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
)

与建议的设计相比，现有设计有哪些优势（可能还有进行EG决策的原因）？

或者，以不同的方式询问，我可能会忽略建议的设计的警告（例如，类型推断困难，并行化约束或约简操作的特定约束，例如，关联性，对Java未来声明位置的预期BiFunction<in T, in U, out R>， …）？

Answer 1

仔细浏览lambda开发的历史并找出做出该决定的“ THE”原因很困难-因此，最终，人们将不得不等待其中一名开发者回答此问题。

一些提示可能如下：

• 流接口经历了多次迭代和重构。在最早的Stream接口版本之一中，有专用的reduce方法，而reduce在问题中最接近该方法的方法仍被调用Stream#fold。这个已经收到一个BinaryOperator作为combiner参数。

• 有趣的是，很长一段时间以来，lambda建议包括一个专用接口Combiner<T,U,R>。违反直觉的是，此功能未在combiner中使用Stream#reduce。取而代之的是，它被用作reducer，这似乎是当今称为的accumulator。但是，该Combiner接口在以后的版本中被替换BiFunction。

• 与问题最相似的地方是在邮件列表中有关Stream#flatMap签名的线程中，然后将其转变为有关流方法签名差异的一般问题。他们将它们固定在某些地方，例如

正如Brian纠正我的那样：

<R> Stream<R> flatMap(Function<? super T, ? extends Stream<? extends R>> mapper);

代替：

<R> Stream<R> flatMap(Function<T, Stream<? extends R>> mapper);

但是请注意，在某些地方这是不可能的：

T reduce(T identity, BinaryOperator<T> accumulator);

和

Optional<T> reduce(BinaryOperator<T> accumulator);

由于使用了“ BinaryOperator”，因此无法修复，但是如果使用“ BiFunction”，则我们具有更大的灵活性

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

代替：

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

关于“ BinaryOperator”的相同评论

（我强调）。

我发现 不 替换为BinaryOperatora
的唯一理由BiFunction最终是在同一线程中对此语句的响应中给出的：

正如您所说，即使BinaryOperator引入了更大的灵活性，它也不会被BiFunction取代，BinaryOperator要求两个参数和返回类型相同，因此从概念上讲它的权重更大（EG已经对此进行了投票）。

也许有人可以从中得出决定这一决定的专家组投票的具体参考，但也许这句话已经充分回答了为什么是这样的问题。