Combine Consistency

CombineX is committed to providing identical API and behavior to Apple's Combine. Any inconsistent behavior is considered as a bug. Our test suit also run against Apple's Combine.

However, there's still some behavior that not guaranteed to be consistent with Apple's Combine:

Extensions on Standard Library, Foundation, and Dispatch

It's not possible for technical reason. Currently Swift is not able to disambiguate between two modules that define the same method or property. Directly extending these type introduces ambiguity therefore you can use neither of them. This bug is tracked here.

To solve this problem, we introduced cx namespace. You need to write result.cx.publisher or dispatchQueue.cx.schedule(...). We promise their behavior is identical to Apple's Combine, beside the cx namespace.

The cx namespace, CXWrapper and CXWrappable protocol are exclusive to CombineX. You can import CXCompatible to use them with Apple's Combine.

Description and Mirror

Protocol conformance consistency is our goal. But we decide to treat CustomStringConvertible, CustomDebugStringConvertible, and CustomReflectable as implementation details. Our objects still conforms to these protocol, yet they might return different description, debugDescription, and customMirror from Apple's Combine. Here is the reason:

• They are mostly used in debugging situation.
• It adds a lot of bikeshedding work without obvious benifit.
• The behavior of Apple's Combine is not consistent and actually leak implementation details. e.g: for Publishers.TryMap, Description of Subscription is "TryMap", but for Publishers.Map it's "PassthroughSubject".

Mirror is not part of our public API, obviously.

Utility Module

If you use CombineX as dependency, you may find following modules are also importable. It's not public API, use on your own risk.

• CXUtility
• CXLibc

Others

If you find any other inconsistency, please file an issue. Or even better, create a pull request that either fix it, or add test case about it.