3.x Create Combinatorial Function, Consumer interfaces for correct nullability

Thanks for using RxJava but before you post an issue, please consider the following points:

• Please include the library version number, including the minor and patch version, in the issue text. In addition, if you’d include the major version in the title (such as 3.x) that would be great.

• If you think you found a bug, please include a code sample that reproduces the problem. Dumping a stacktrace is usually not enough for us.

• RxJava has more than 150 operators, we recommend searching the javadoc for keywords of what you try to accomplish.

• If you have a question/issue about a library/technology built on top of RxJava (such as Retrofit, RxNetty, etc.), please consider asking a question on StackOverflow first (then maybe on their issue list).

• Questions like “how do I X with RxJava” are generally better suited for StackOverflow (where it may already have an answer).

• Please avoid cross-posting questions on StackOverflow, this issue list, the Gitter room or the mailing list.

As outlined in https://github.com/ReactiveX/RxJava/issues/5216 and https://github.com/ReactiveX/RxJava/issues/5442 (2.x issues), Function, Consumer, etc have varying nullability requirements, and thus can’t have nullability annotations. Unfortunately, this requires consumers to move their nullability checks to runtime instead of compile time.

I propose that you include the following combinations of your existing functions package. The naming scheme is not important. For reference, I used R (or required) for @NonNull and O (or optional) for @Nullable.

interface BiConsumerRR<T1, T2> {
  void apply(@NonNull T1 t1, @NonNull T2 t2);
}
interface BiConsumerRO<T1, T2> {
  void apply(@NonNull T1 t1, @Nullable T2 t2);
}
interface BiConsumerOO<T1, T2> {
  void apply(@Nullable T1 t1, @Nullable T2 t2);
}
interface BiConsumerOR<T1, T2> {
  void apply(@Nullable T1 t1, @NonNull T2 t2);
}
interface ConsumerR<T> {
  void accept(@NonNull T t) throws Throwable;
}
interface ConsumerO<T> {
  void accept(@Nullable T t) throws Throwable;
}
interface FunctionR<T, R> {
  @NonNull R apply(@NonNull T t);
}
interface FunctionO<T, R> {
  @Nullable R apply(@NonNull T t);
}
interface SupplierR<T> {
  @NonNull T get() throws Throwable;
}
interface SupplierO<T> {
  @Nullable T get() throws Throwable;
}

BiFunction, BiPredicate, Function3, Function4, Function5, Function6, Function7, Function8, Function9, IntFunction, and Predicate already have complete nullability definitions, so I assume they wouldn’t need any combinations.

Then, Maybe could have:

@NonNull 
public static <T> Maybe<T> fromSupplier(@NonNull SupplierO<? extends T> supplier);

And Single could have:

@NonNull
public static <T> Single<T> fromSupplier(final SupplierR<? extends T> supplier);

This is only a cost of 10 extra interfaces to ensure compile-time nullability correctness, and provide better guidance to developers. I hope you’ll consider it. If you’re interested in this, I’m happy to contribute a PR and track down the various ambiguities.

[akarnokd]

We may just wait out AGP 4, a couple of months.

[JakeWharton]

I haven’t experienced those problems on other libraries with the same setup.