Will this be part of the Core Libraries or Standard library?
Why didn't it go beyond what existing Rx libraries provide?
To the last point: We introduced the Result type so that we don't have to deal with 2 entry points (success and failure) in callbacks. Combine has separate entry points for success, failure and finished events. Why not consolidate this using the Result type?
Also, I would have hoped that Swifts version of Rx is more approachable - by using better namings. People new to reactive programming will be irritated by names like Subject, CurrentValueSubject. Maybe something like Signal and Property are more accessible to a broader audience.
There already is an open source Swift version of Rx (GitHub - ReactiveX/RxSwift: Reactive Programming in Swift). I guess combine is similar but does not follow the ReactiveX API.
For now, it is closed source and not cross-platform. Let's hope that Apple will open source it at some point and make it work on all Swift supported platforms.
I for one, am tremendously excited for the acknowledgement and solution (in Combine) of the need of asynchronous back-pressure in streaming -- it shows up in many many places after all
I haven't had a chance to look in to it in much detail yet, but broadly-speaking, I quite like the design of Combine.
I definitely think it is a good candidate for inclusion in the open-source project in some form (either as a corelib or as part of the standard library). There is nothing really magical about it - there are already plenty of reactive-stream libraries - but there would be a lot of value in standardising around a blessed library and common currency types.
It all depends if Apple is open to it or not (pun intended). Otherwise I suspect existing libraries like ReactiveX will continue to be preferred for cross-platform code with some kind of wrapper for when their streams end up in Apple-land. It would benefit all Swift code on all platforms if we could avoid that bifurcation.
We don't even need their implementation, just permission to use the API (since APIs are copyrightable).