1.x: Change the signature of ignoreElements is also an implicit cast to whatever type you want.

[abersnaze]

to remove the need for mergeWithEmpty and concatWithEmpty in #3430. I'm pretty sure that this doesn't count as a breaking change because of type erasure.

[akarnokd]

Actually, there is no need to add more type parameters but just do an unchecked cast or raw type cast:

@SuppressWarnings("unchecked")
//...
return (Observable)lift(OperatorIgnoreElements.<T>instance());

Note that instance() does this re-cast as well since the operator is stateless.

[davidmoten]

ah that's great @abersnaze, so simple!

[zsxwing]

Doesn't it prove this breaks the source compatibility?

[abersnaze]

Yes, but it doesn't prove if it breaks binary compatibility?

[artem-zinnatullin]

Would be nice to check binary compatibility as part of CI, there are some checker tools that we can include into the build process. Probably, it deserves a separate issue.

[abersnaze]

I came across a semver for Java library awhile ago that could take two jars and hint if it was major, minor or patch change.

[zsxwing]

I just realized we don't have a guidance on source compatibility explicitly. We only discussed backward compatibility in #1917. But I'm supposed backward compatibility should include both binary and source backward compatibility.

[davidmoten]

So we need a decision on the importance of source compatibility specifically in the category of generic types, right?

I'm happy to add a generic type to ignoreElements where necessary to my codebases when I update to the next release because for a Java only codebase static typing will show me where things went wrong at compile time. Does anyone know if this change would bring about runtime grief for one of the dynamic languages that use RxJava?

[stealthcode]

Could this changed be done in a minor release?

[abersnaze]

closing in favor of #3567