Java 8 erneut anzeigenStream API-Design, ich war überrascht von der generischen Invarianz auf demStream.reduce() Argumente

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

Eine anscheinend vielseitigere Version derselben API hat möglicherweise Kovarianz / Kontravarianz auf einzelne Verweise auf @ angewendeU, sowie

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

Dies würde Folgendes ermöglichen, was derzeit nicht möglich ist:

// 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);

Umgehung: Verwenden Sie Methodenverweise, um die Typen in den Zieltyp zu "zwingen":

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

C # hat dieses spezielle Problem nicht, daFunc(T1, T2, TResult) wird wie folgt definiert, wobei die Abweichung von der Deklarationssite verwendet wird. Dies bedeutet, dass alle APIs, die @ verwendeFunc bekommt dieses Verhalten kostenlos:

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

Was sind die Vorteile (und möglicherweise die Gründe für EG-Entscheidungen) des vorhandenen Designs gegenüber dem vorgeschlagenen Design?

Oder anders gefragt, was sind die Vorbehalte des vorgeschlagenen Entwurfs, die ich übersehen könnte (z. B. Schwierigkeiten bei der Typinferenz, Parallelisierungsbeschränkungen oder Einschränkungen, die für die Reduktionsoperation spezifisch sind, wie z. B. Assoziativität, Vorwegnahme einer zukünftigen Abweichung der Java-Deklarationsstelle vonBiFunction<in T, in U, out R>, ...)?