WebAssembly support for atomics and multi-threading isn't fully standardized yet, and it not supported in SwiftWasm at the moment. Because of this Dispatch is unavailable, and all Combine-related Foundation stuff is unavailable too. Tests related to this are disabled. Locking functions are replaced with no-op shims.

Hi there

So I am on the home stretch, but I have a few issues. Firstly: I am getting

error: value of type 'URLSession' has no member 'dataTaskPublisher'
            self.urlSession.dataTaskPublisher(for: request)

Is there an OpenCombine equivalent to use dataTaskPublisher?

Secondly, I am also getting:

error: value of type 'Any' has no member 'tryMap'
                .tryMap { (data, response) -> Data in

Is this also functional in OpenCombine?

Thanks once again 🙏🏻

I'm taking a stab at FlatMap. In support of operators that need serialization of sending values from multiple upstream/child subscriptions, I've implemented a simple/fast SerializedWorkQueue that adheres to the Combine threading rules and avoids unnecessary context switches.

Remaining work:

• [x] Clean up and ensure all completion/failures paths are correct.
  • [x] Clean up and complete with .failed if either upstream or any children fail.
  • [x] Complete with .finished only after upstream and all children have completed (i.e. add refcounting of active subscriptions) AND all buffer values have been sent.
• [x] Figure out and add support for maxPublishers
• [x] Figure out non-trivial handling of demand for child subscriptions and implement it.
  • [x] Basic child demand scenarios work
  • [x] Add support for downstream demand going from .unlimited to .max(x)
  • [x] Add support for downstream demand going from .max(x) to .unlimited
• [x] Add unit tests
• [x] Factor out common base class from Inner class to be shared with all merge like operators.

I'm currently maintaining a few forks of open-source libraries that make those compatible with OpenCombine: GRDBOpenCombine and its dependency OpenCombineExpectations. I'd appreciate any input and contributions to these forks, and maybe some coordinated effort to push a more sane support for "polyfill" libraries in future versions of Swift. If the latter happens, we probably even could upstream changes from these forks to their origin repositories.

Either way, it would make sense to maintain these forks, proposals, and related helper projects under one umbrella OpenCombine organization with an open list of maintainers. This would make the project more visible and I hope attract more attention and contributors. I'm not sure if existing OpenCombine organization is the one previously created for this purpose, if not maybe something like OpenCombineHQ could work as a name just as well.

Adding support for CocoaPods. This required to add three separate podspecs, one for the C++ helpers, one for OpenCombine and one for OpenCombineDispatch. Created a local example project and tested that it build with both dynamic frameworks and static libraries. ✅

As os_unfair_lock is only available on versions above the minimum deployment target, warnings are produced. There is a check in place that they're actually not used when they're not available. Therefore passing --allow-warnings to pod lib lint should be fine.

This PR does not expose the tests via a test_spec as this would've required adding a podspec to GottaGoFast. As this dependency was recently dropped, let's tackle this in a future PR.

Fixes #48

Hello! I've implemented this interface. That allows use construction like this: @Published var value: String? And bind and subscribe: $value.assign(to: \.text, on: textLabel) I hope that will be helpful.

• [x] Update tests to pass in Combine compatibility mode
• [x] Fix OpenCombine so all tests pass
• [x] Implement the new APIs
• [x] Write tests for the new APIs
• [x] Enable testing with Swift 5.5 on Ubuntu (when Swift 5.5 docker image is released)

(picking up #93)

• [x] Make it work with generic classes.
• [x] Add tests for NSObject subclasses.
• [x] Add tests where a class contains a field of resilient struct type
• [x] Add CI jobs for Apple platforms without Swift runtime (before iOS 12.2/macOS 10.14.4).
• [x] Add CI jobs for Apple platforms that support Swift 5.1.
• [x] Ideally, test on a 32 bit Apple platform.
• [ ] Remove unneeded C++ code.
• [ ] Resolve FIXMEs

Hello! I've done some work for "Delay" feature. It's not complete yet because I need advice for some troubles. First: It can't be completed until "FlatMap" is done. Second: I can't finish tests for "Delay" because we don't have RunLoop in OpenCombine. But I've tested all functionality on iOS and all works as expected with this implementation (all existed tests pass).

Best regards!

This should fix #38 but I think it breaks the synchronisation test. I tried fixing it and from what I can see everything is locked properly but apparently I am missing something since that test is flaky for me locally. Would be great if you can have a look and tell me what you think about this implementation.

I implemented most of this a few days back, mostly reusing what's currently in the repo.

There is a bug with max operator with custom comparison closure, hence the test fail, but I thought I'd open up a PR and see if you guys have any ideas

The bug itself is probably pretty straight-forward to fix, I'm just having a hard time reasoning what min and max operators with custom comparison closures are supposed to do in the first place. I assume it's just a matter of somehow "inverting" the logic for min and max operators, after the custom closure is executed. The test that's failing is called testCustomMaxSendsCorrectValue.

Let me know how all of this looks, and I can address any feedback asap.

On a side note -- one thing that slowed me down quite a bit was trying to squeeze in some of the code with lengthy generic names into single lines. Is there a reason with went for 90 char/line limit? It seems pretty strict, leaving basically half of my laptop screen empty. On projects I previously worked on, the number was usually in 130-150 range. Just curious if it's open for debate or not :)

Building for debugging... */OpenCombine/Sources/COpenCombineHelpers/COpenCombineHelpers.cpp:10:10: fatal error: 'atomic' file not found #include ^~~~~~~~ 1 error generated. [1/10] Compiling COpenCombineHelpers COpenCombineHelpers.cpp

When Swift released 5.7 in Xcode 14.0, Combine framework has updated its protocol interface to support primary associated type support.

eg.

// Latest Combine
public protocol Publisher<Output, Failure>

// Current OpenCombine and old Combine(iOS 15-)
public protocol Publisher

Adding such feature support enable us to use some Publisher<Int, Error> without needing to convert it to AnyPublisher.

func loadUser(
    withID id: User.ID
) -> some Publisher<User, Error> {
    urlSession
        .dataTaskPublisher(for: urlForLoadingUser(withID: id))
        .map(\.data)
        .decode(type: User.self, decoder: decoder)
}

See more info at Combining opaque return types with primary associated types

Apple's official Combine framework also implemented primary associated types feature introduced in swift 5.7.

https://developer.apple.com/documentation/combine/connectablepublisher https://developer.apple.com/documentation/combine/publisher https://developer.apple.com/documentation/combine/subscriber https://developer.apple.com/documentation/combine/subject https://developer.apple.com/documentation/combine/scheduler

so I changed ConnectablePublisher, Publisher, Subscriber, Subject, Scheduler to support primary associated types as well.

while trying to implement OpenCombine to mimic missing Combine Framework in example in Xcode 11.3.1 projects where Swift does also not support @Published directive (nor @Bind , @StateObject or @ObservedObject) one could do something like..

@propertyWrapper
struct Published<T> {
    var wrappedValue: T {
        willSet { /*...*/ }
        didSet { /*...*/ }
    }
    init(wrappedValue: T) {
        
        // * -- maybe magic here! -- */
        
        /* or do more specific stuff.. ^^
        switch (wrappedValue) {
        //case is Optional<Any>.Type :
            //break
        case is Bool :
            break
        case is Error :
            break
        case is Optional<Error>.Type :
            break
        default: break
        }
        */
        self.wrappedValue = wrappedValue
    }
}

to implement such feature in Swift version prior .. where @propertyWrapper directive is available. So the question is what should such wrapper look like in its inner logic?

opened a question in StackOverflow

it could be wrapped also in preprocessor directives like #if !canImport(Combine) or similar to limit where it would be applied in projects

also see: swiftbysundell.com/accessing-a-swift-property-wrappers

For Future type publisher, it send signal then send completion to the Publishers.ReceiveOn.

In Publishers.ReceiveOn:

for signal:

scheduler.schedule(options: options) {
   self.scheduledReceive(input)
}

for completion:

scheduler.schedule(options: options) {
   self.scheduledReceive(completion: completion)
}

but the scheduler may execute the completion command before signal, in this case, the state.subscription is nil then returned.

private func scheduledReceive(_ input: Input) {
  lock.lock()
  guard state.subscription != nil else {
    lock.unlock()
    return
  }
   
   // ...
}

This result is not match expectations.

And the Apple's Combine has the same bug yet 😂.

We should promise the subscriber will always receive the signal?

Some solution code:

// for signal.
lockedActions.write().safeRun({
    $0.pointee.insert({ [weak self] in self?.scheduledReceive(input) }, at: 0)
})
scheduler.schedule(options: options) {
    self.lockedActions.write().safeRun({ $0.pointee.popLast()?() })
}

// for complection.
lockedActions.write().safeRun({
    $0.pointee.insert({ [weak self] in self?.scheduledReceive(completion: completion) }, at: 0)
})
scheduler.schedule(options: options) {
    self.lockedActions.write().safeRun({ $0.pointee.popLast()?() })
}