Closed M0rtyMerr closed 5 years ago
I trust your experience, so if u think we have to leave - let's leave.
But user could use .filterMap
throwing version without changing his code. If you aware that someone will want downgrade RxSwiftExt version from throwing to non-throwing version - I can add throwing version as overload with later deprecation if original one(non-throwing). What do you think? :)
I think it will conflict, can you try? (having a secondary overload with only a throw
difference).
@freak4pc no conflict. Just pushed overload
Thought about it some more - let's not do an overload, just add the throws
property.
Sure, removed overload, change filterMap documentation
@freak4pc I added removal of flatMapSync
here, cause it related to filterMap
implementation
I don't think it's necessarily related - can we remove flatMapSync in a separate PR? I mainly want the commits & PRs to be atomic so people can track down the changes backwards.
@freak4pc ok, reverted, will open separate PR
I'd want @jdisho to confirm he's OK with this as well, as long as he's reviewing here :)
I'm not 100% sure we can make the closure throwing. It breaks backwards compatibility ... we might want to leave it as is until we bump a major version.