I am having issues with creating an archive when using PromiseKit with the newest Xcode. When trying to run an archive task I get a following error:

1. While emitting IR SIL function @_TZFE10PromiseKitCSo20NSNotificationCenter4oncefSSCS_19NotificationPromise for 'once' at /Users/mpigulski/Development/PromiseKitArchiveTest/Pods/PromiseKit/Categories/Foundation/NSNotificationCenter+Promise.swift:22:12 Segmentation fault: 11

I have attached a test project that allows to reproduce this: PromiseKitArchiveTest.zip

So to reproduce use Xcode Version 7.3.1 (7D1014):

• open the project using PromiseKitArchiveTest.xcworkspace
• go for Product -> Archive

Archive will fail. Help.

These are the diffs for option 1 of Proposal for PromiseKit cancellation support #896. With option 1 the new cancellation code is included with CorePromise.

The repositories involved with the pull request for option 1 are:

Repositories | ------------- | mxcl/PromiseKit | PromiseKit/Alamofire- | PromiseKit/Bolts | PromiseKit/CoreLocation | PromiseKit/Foundation | PromiseKit/HealthKit | PromiseKit/HomeKit | PromiseKit/MapKit | PromiseKit/StoreKit | PromiseKit/SystemConfiguration | PromiseKit/UIKit |

Result:

I am wrapping the internals of many asynchronous method's with

    return [PMKPromise new:^(PMKPromiseFulfiller fulfiller, PMKPromiseRejecter rejecter) {

and am now finding that EXC_BAD_ACCSS issue, as mentioned on the website:

2. EXC_BAD_ACCESS
ARC is pretty good, but in some cases it is possible for your Promise chain to be partially deallocated. Usually when wrapping delegate systems. PromiseKit itself has macros that force additional retains and releases to avoid this.

I have been "debugging" this for hours, however I can find little helpful information or correlation except that it stops if I flatten the Promise chain a little and then occurs later on.

I am hoping that you may know what I am talking about / seen this before / have a solution. I have been up all night working on this and implemented PromiseKit everywhere and not am a little discouraged to see I have nothing to show for my nights work because of a strange error that I cannot debug.

Please let me know if there is anything I can do to help you diagnose. Thank you!

• PromiseKit 6.5.2
• Xcode 10.0 (10A255)
• Swift 4.2
• Carthage for dependency management
• A 3rd party framework whose Cartfile contains:

github "mxcl/PromiseKit" ~> 6.0
github "PromiseKit/Foundation" ~> 3.0

And my project's resulting Cartfile.resolved file contains:

github "PromiseKit/Foundation" "3.3.0"
github "mxcl/PromiseKit" "6.5.2"
github "realm/realm-cocoa" "v3.11.1"
# ... (some other stuff)

My app compiles fine, but immediately crashes with the error below. If I read the error right, then the 3rd party framework is expecting to find the URLRequest extension method in PromiseKit.framework rather than in PMKFoundation.framework?

dyld: Symbol not found: _$S10Foundation10URLRequestV10PromiseKit0B11ConvertibleADWP
  Referenced from: /Users/XXXX/Library/Developer/CoreSimulator/Devices/37D783DD*/data/Containers/Bundle/Application/4073D393*/XXXXX.app/Frameworks/XXXXX.framework/XXXXX
  Expected in: /Users/XXXXX/Library/Developer/CoreSimulator/Devices/37D783DD*/data/Containers/Bundle/Application/4073D393*/XXXXX.app/Frameworks/PromiseKit.framework/PromiseKit
 in /Users/XXXXX/Library/Developer/CoreSimulator/Devices/37D783DD*/data/Containers/Bundle/Application/4073D393*/XXXX.app/Frameworks/XXXXX.framework/XXXXX

Thanks

• PromiseKit version: 6.0.0

I know we're in maintenance mode here, but I was wondering if you'd be open to a small discussion on the flatMap introductions in the most recent version, since Swift's long overloaded the term and made it more confusing than it needs to be (and again, recently, with compactMap), and I'm afraid the naming here may continue to bewilder folks both new to and familiar with functional programming.

The concepts of map and flatMap in programming at large have this shape:

// map
[A]  => ((A) ->   B ) ->  [B]
 A?  => ((A) ->   B ) ->   B?
F<A> => ((A) ->   B ) -> F<B>

// flatMap
[A]  => ((A) ->  [B]) ->  [B]
 A?  => ((A) ->   B?) ->   B?
M<A> => ((A) -> M<B>) -> M<B>

For PromiseKit to behave as one familiar these shapes expects, map and flatMap should look like this:

Promise<A> => ((A) ->         B ) -> Promise<B>
Promise<A> => ((A) -> Promise<B>) -> Promise<B>

These are the two behaviors of then! The Promises/A+ spec decided to combine map and flatMap behaviors for ergonomics. Overloads in JavaScript don't have the compiler error issues you've been trying to solve, but having predictable map and flatMap would help!

The flatMap additions to PromiseKit run counter to these intuitions. Maybe some qualifiers would help.

https://github.com/mxcl/PromiseKit/blob/0e150f87e895d849287e8fc5053e6dfe7919577d/Sources/Thenable.swift#L57

This looks like it's a compactMap of sorts, swallowing up optional return values.

https://github.com/mxcl/PromiseKit/blob/0e150f87e895d849287e8fc5053e6dfe7919577d/Sources/Thenable.swift#L176

This is performing a flatMap operation on the inner sequence, not the promise, so maybe flatMapInner would be a more appropriate name.

Lemme know if I've been unclear or need to make any clarifications!

This is just an idea....

As we know, in Swift, enums allow us to create very succinct and rich types, which is great for describing errors. Also, keeping error application logic in this domain as error propagate through the layers of an application is beneficial, only converting them into NSErrors when they need to be presented to the user.

To this end, it would be good if PromiseKit accepted errors using a generic type. So, usage could be something like this...

public protocol ErrorType {
    var code: Int { get }
    var domain: String { get }
    var localizedDescription: String? { get }
    var userInfo: Dictionary<NSObject, AnyObject>? { get }
}

extension NSError: ErrorType {
    public convenience init(_ error: ErrorType) {
        self.init(domain: error.domain, code: error.code, userInfo: error.userInfo)
    }
}

public class Promise<T, E: ErrorType> {

public var error: E?

}

Then, an application can define its own Error type, which can be used to reject promises, for example:

public enum NetworkError: ErrorType {
    case NotAuthenticated
}

public enum Error: ErrorType {

   case Network(NetworkError)
    // etc


    public var code: Int { 
        // etc
    }
    public var domain: String { 
        // etc
    }
}

Then, a promise can be rejected like this...

return Promise(error: .Network(.NotAuthenticated))

Using this pattern allows us to transform our custom Error type from a potentially vague error which lacks critical detail, to a specific error which can be recovered from with greater ease and clarity. At the moment, at the point I wish to reject the promise, I have to initialise an NSError, and lose the rich type detail.

Thoughts?

I thought that swift incorrectly define type of a closure, but casting doesn't help. Example from README.md doesn't work for me as well. Is it bug, or i'm doing something wrong?

let promise: Promise<Int> = Promise({ success, failure in
    success(10)
})

promise.then { number in
    self.remainingTimeLabel.text = "int is \(number)"
}.catch { error in
    self.remainingTimeLabel.text = "erorr is \(error)"
}

Consider an asynchronous HTTP GET method request that returns a promise:

- (Promise*)GET:(NSString*)path;

Users of this API may want to cancel the underlying asynchronous work, the HTTP request. Currently PromiseKit does not allow cancelable promises.

I've been looking into javascript promises and cancelation. There is some discussion in the A+ spec https://github.com/promises-aplus/cancellation-spec/issues

Any thoughts on cancelation?

• Please specify the PromiseKit major version you are using 6

• Please specify how you installed PromiseKit, ie. Carthage, CocoaPods, SwiftPM or other. If other provide DETAILED information about how you are integrating PromiseKit. CocoaPods and indirectly with SPM (see text)

AnyPromise is not available when using Swift PackageManager. But why? I read in another issue that this is documented but I can't find anything regarding this fact.

My Problem:

I'm using PromiseKit in a mixed Swift/ObjC project. I'm including PromiseKit using CocoaPods but trying to successively switch to SPM. Since I need AnyPromise, I wasn't able to move PromiseKit from CocoaPods to SPM so far.

But now I ran into another Problem: I'm using a SwiftPackage, which itself has a dependency to PromiseKit. Now my main project is complaining that AnyPromise isn't available, because the SPM (internal) dependency to PromiseKit is "overriding" the CocoaPods dependency. As far as I know, there is no way, to create something like a "private" dependency within a Swift Package. All dependencies are automatically "re-exported" and visible to the main project.

I was searching through the Swift Forums already but there currently seems to be no way to avoid re-exporting SPM package dependencies. Maybe if I understand why AnyPromise isn't available when using SPM I might be able to find a workaround.

Intro

Currently all errors in a promise chain propagate down to a single catch handler at the end. Therein, the identity of the error must often be reasoned out with comparative statements and then handled according to its identity. This can lead to otherwise clean chains becoming bottom-heavy with logic in the catch.

Swift's do-catch provides for error pattern matching in its catch handlers, raising the error identification logic up one level. This PR provides an implementation to introduce this pattern into PromiseKit, allowing for separate catch handlers for specific errors.

refs #639

Usage

The new catchOnly method included in this PR works the same as the current catch method, except that it takes a required Error parameter, and only executes its handler if the promise chain rejects with that error.

firstly {
    API.findUser(named: "Taylor")
}.done { user in
    //…
}.catchOnly(API.Error.noResults) {
    //Let the user know there's no results for their query
}.catch { error in
    //Handle other errors like timeouts
}

In the above, the catchOnly handler would only execute if the API request rejected with a noResults error. The final catch handler would then no longer execute since the error was already handled. Likewise, if some other error occurred, the catchOnly handler would be skipped and only the final catch handler would be executed.

An arbitrary number of catchOnly calls may be chained, but the chain must still be terminated with a final catch. An overload for catchOnly which takes a type instead of an object is also provided for matching on a family of errors.

Implementation

The new functions work similarly to the current catch function, only instead of returning a PMKFinalizer they return a void promise which is fulfilled if the error is handled (or if the promise was fulfilled), and rejected with the unhandled error otherwise to allow it to propagate to successive catch handlers.

Since no changes were made to existing API or implementations, a major version rev should not be necessary. I have included some trivial tests in the PR as evidence that the new functions behave as intended, but I am happy to flesh these out or strip them entirely upon request.

I've not included any implementation for the Objective-C interface (not sure if it's necessary or even desired). But I am happy to do so if requested.

Ideally, I would have preferred a simple catch(Error.someError) signature both for succinctness and keeping in line with Swift's do-catch, but it surfaced the usual compiler confusion that PMK's overloads have dealt with in the past. I settled on catchOnly to get around this, but I actually rather like it now, and its visual distinctness in code from the base catch is probably for the best. Still, open to name changes, of course.

Limitations

Since the new catchOnly functions return a promise, it is possible to chain off of them with functions other than catchOnly and catch. This isn't desirable, but is also unlikely to to be utilized, I believe, since the underlying value from the promise would have been consumed by catchOnly. A chained then or done for instance would have no context. I had originally intended to return a PMKFinalizer to avoid this, but that solution quickly proved to have too many issues.

Error objects with associated values, while technically supported, make little sense in the usage of catchOnly since concrete associated values would need to be supplied in order to pattern match. However, the type-accepting overload of catchOnly can still prove useful in these cases.

Errors passed in must conform to Equatable, but this is given for free in most situations in Swift 4 now.

Alternatives

recover may already be used in a similar manner to catchOnly (as described in #639). And this doesn't appear to be a hotly requested or needed feature by any means. So, leaving it out of PromiseKit probably isn't going to cause any friction.

• Please specify the PromiseKit major version you are using 6.5.2
• Please format your code in triple backticks and ensure readable indentation

I am currently working on an Apple Watch app extension that uses PromiseKit. I installed the project by following the instructions: Dragging the project into my project folder in xcode, then adding the embedded binary to both the iOS and Watchkit Extension project.

After a long time fumbling around, trying to figure out why it says, No such module "PromiseKit", I was finally able to deploy it to a simulator after running a build for PromiseKit on that same device before deploying the WatchKit Extension.

Unfortunately, there appears to be no solution to solving this problem when running on the actual Apple Watch device, as it is not an option in the build configuration to build it on the device first.

Is this supposed to be expected behavior? That it must be built on the device first? Is there something that might be going wrong?

I am using XCode 10.1 beta 3 BTW

Thank you very much,

Bumps decode-uri-component from 0.2.0 to 0.2.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps qs from 6.4.0 to 6.4.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps loader-utils from 1.1.0 to 1.4.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

I've just built and uploaded a version of an app to the AppStore and received a warning indicating that PromiseKit is using non-public selectors from the upload process - I've submitted the build for TestFlight review (haven't submitted for a full review yet) but haven't gotten an approval/rejection at the time of writing

I assume it's actually just a naming collision rather than using non-public APIs but wanted to raise the issue ASAP to try and get a jump on a potential review rejection

XCode: 14.0.1 PromiseKit: 6.18.1 Installation: CocoaPods

it will crash on iOS11/12 because of this code:

version: 6.18.0 #if swift(>=5.5) @available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *) public extension Guarantee { func async() async -> T { await withCheckedContinuation { continuation in done { value in continuation.resume(returning: value) } } } }

@available(iOS 13.0, macOS 10.15, tvOS 13.0, watchOS 6.0, *) public extension Promise { func async() async throws -> T { try await withCheckedThrowingContinuation { continuation in done { value in continuation.resume(returning: value) }.catch { error in continuation.resume(throwing: error) } } } } #endif

Bumps codecov from 3.0.0 to 3.8.3.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.