New operators: concatEmptyWith and mergeEmptyWith

[NiteshKant]

As discussed in issue #3037, the primary use of these operators is to be applied to Observable<Void> so that they can be merged and concatenated with an Observable of a different type.

Both these operators raise an error if the source Observable emits any item.

[NiteshKant]

This is a replacement for #3060

[akarnokd]

👍

[akarnokd]

I've been thinking about these operators and it feels odd they have to throw if the source is not empty. Regardless, do you think if it is possible to factor out this error behavior into a separate operator, let's say none and use source.none().concatWith(other) and source.none().mergeWith(other) instead? This would match the pattern with single() which throws if there are too few or too many elements in the source.

[NiteshKant]

The idea for these operators is to combine two streams of different types (Void and T). Since, you can not really combine two different types, it is categorized as an error, if it does so. Why do you think this is odd?

Would .none() change the type of the stream? i.e. would it be like:

public <R> Observable<R> none();

[akarnokd]

It could, although that might not help due to problems with Java type inference in various Java versions (and IDEs); I got surprised a few times. Certainly, I like the inlined nature of this PR so no pressure on none. There is also the proposed Completable which doesn't allow emitting any value and supports endWith(Observable) as a means of continuation. What do you think?

[NiteshKant]

Completable is what I was intending in a contrived way via VoidObservable in the initial issue which led to this PR. The existence of Completable will make these operators redundant and I think that is a better abstraction for this usecase.

[akarnokd]

Great. (If you wish, you can try Completable without juggling with its PR.)

[abersnaze]

Could we also close this PR if we add none() and change ignoreElements() to return <R> Observable<R>?

[akarnokd]

That might not be binary compatible. I've checked it and changing the type parameter creates a compilation error in OperatorIgnoreElementsTest.testDoesNotHangAndProcessesAllUsingBackpressure, which means there could be type-expectancies out there that are require the same type as the source.

[ibaca]

I add 👍 to @akarnokd solution source.none().concatWith(other)/source.none().mergeWith(other) but changing concatWith/mergeWith by then/flat which force cast the ignoreElement (which is safe) to the other type (see #3037 (comment), sorry for commenting on the other thread, but is where @NiteshKant describes its originar problem).

[stealthcode]

Closing this PR in favor of converting an Observable to a Completable

obs.doOnNext(this::blowUp).toCompletable().endsWith(nextObservable);

Note that the operator names in Completable are subject to change as it has not yet been released. See #3570.

If you think this case is not handled then feel free to re-open.