Discuss the roadmap wrt. new operators

[danielcweber]

There has been quite some action going on in this repo for the past weeks due to reformation of a community on the initiative of @ghuntley. Version 4.0 of the library was released, since then, the code has seen improvements and fixes by at the same time keeping the API surface. However, some PRs deal with new LINQ-operators that have been held back so far (#567, #536, #133). This issue intends to start a discussion on the roadmap for new LINQ-operators.

[akarnokd]

The main risk is due to the extension methods nature of Rx.NET. In RxJava, we can relatively safely add methods to the abstract base classes. Subclassing these abstract base classes for adding new methods simply doesn't work as the type will revert back to the base type in standard operators anyway.

In C#, anybody can target IObservable and thus introduce or have already introduced conflicting operators - maybe with the same or completely different behavior. The API was unchanging for a longer period of time so I wouldn't neglect this conflict probability. Also it depends on how typically people use Rx.NET in their apps. Do they recompile for each version or is it just a DLL replacement for them?

The benefits of extending the API is, of course, getting high quality and supported new standard operators. People doing cross-platform and cross-language development also expect some feature parity, especially when RxJava is involved in a way or another.

I've already listed operators and features in #489 from RxJava that could be considered as a standard addition to Rx.NET. For most of them, I have the prototype and tested implementation in my own repository.

Which brings us to option 3: rely on 3rd party extensions and simply keep Rx.NET to a core minimum, with potentially opening up Sink/Producer because without them, the core Rx.NET will likely always apply unnecessary safeguards, thus overhead, around 3rd party extensions.

[quinmars]

I don't think API clashes with external extension methods should be such a great concern. If you have the source under your control, you can rename it and I don't think there are that many libraries providing additional operators. And even then it'd be possible to work around that. The binary compatibility isn't affected at all. Nonetheless I think new operators should be added carefully. There are already many, and not every esoteric problem must be solved with the standard set.

BTW, since @onovotny has merged the RetryWhen and AutoConnect PRs he doesn't seem to be opposed to increase the interface surface.