-
Notifications
You must be signed in to change notification settings - Fork 7.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove covariance of scan/reduce #369
Remove covariance of scan/reduce #369
Conversation
RxJava-pull-requests #263 SUCCESS |
This method and friends T2 should remain "? super T" because it is only consumed. |
I didn't change those yet as I wasn't sure if they behave differently because they consume and produce different types. I wasn't able to get an example that proved or disproved anything so left it until I can. Do you have example code that shows that method doesn't benefit from And what T2 are you referring to? There isn't anything with a type T2 in |
Func2<T1, T2, R> |
(George and I chatted in person) We looked at JDK 8 to try and get a final representation of others doing this and it does it like this: <U> U reduce(U identity,
BiFunction<U,? super T,U> accumulator,
BinaryOperator<U> combiner) Optional<T> reduce(BinaryOperator<T> accumulator) The public interface BinaryOperator<T>
extends BiFunction<T,T,T> Thus this seems to confirm the decision to remove reduce(R initialValue, Func2<R, ? super T, R> accumulator) |
Updates based on discussion at ReactiveX#369 (comment)
Remove covariance of scan/reduce
RxJava-pull-requests #267 SUCCESS |
Updates based on discussion at ReactiveX#369 (comment)
…-covariance Remove covariance of scan/reduce
Remove covariance of scan/reduce since consumer/producer are the same <T, T, T>
See #360 (comment)