There seems to be an issue while converting Promise to FBLPromise. Completly blocked.

2. While generating Objective-C header
3. While printing 'Connection' at /Volumes/Official/WorkingCopy/native/Classes/Swift/Connection/Connection.swift:11:1
4. While printing type 'Promise.ObjCPromise'
5. While printing type 'Value' error: Segmentation fault: 11

I'm a little confused about what FBLPromises.framework is, and whether I need to link & embed it. I'm using Carthage and Swift, no objc.

When I link and embed the Carthage-built Promises.framework, everything builds fine but it crashes on launch with:

dyld: Library not loaded: @rpath/FBLPromises.framework/Versions/A/FBLPromises
  Referenced from: /Users/jeffh/Library/Developer/Xcode/DerivedData/CMShell_Demo-byxhplkbtqxauhejbrbnapbkhdgi/Build/Products/Debug/CMShell Demo.app/Contents/Frameworks/Promises.framework/Versions/A/Promises
  Reason: image not found

If I also embed and include the Carthage-built FBLPromises.framework then everything works just fine, but I don't want to be including stuff I shouldn't / don't need.

Sorry if I'm doing something stupid. And thanks for this beautiful library, it really is a joy to use.

Getting this error when updating to PromisesSwift 1.2.9 (cocoapods 1.9.3 and 1.10.0.beta.1):

[!] Unable to determine Swift version for the following pods:

- `PromisesSwift` does not specify a Swift version and none of the targets (`Dummy`) integrating it have the `SWIFT_VERSION` attribute set. Please contact the author or set the `SWIFT_VERSION` attribute in at least one of the targets that integrate this pod.

Promises should have ability to remove registered fulfillment/rejection callbacks(blocks) WITHOUT influencing underlying operation that promise corresponds to.

Such CancelToken (often also called InvalidationToken) should also allow cancellation of callback scheduled on some queue from within the same queue, just in earlier block. In other words, cancellation of callback should work even if its block is already scheduled on the queue (but not yet started to execute).

waitForPromises() should be removed because it is an abstraction leak: you never know in the test what other promises tested code will use in it internal implementation.

"So waiting for a bunch of async tasks to finish in a test can be tricky." (from docs) — no, it is tricky on Android that doesn't have any SDK support for it.

On iOS, we have XCTestExpectation exactly for that, without false hope for tested code to move into predictable state by leaking its implementation details into the test.

https://github.com/google/promises/blob/46c1e6b5ac09d8f82c991061c659f67e573d425d/Sources/Promises/Promise%2BAsync.swift#L28 String can convert to NSError in iOS 16. This most likely is a bug in iOS 16. Hope Apple could fix this soon.

I am trying to install this with cocoapods

I first set (as per doc) in my podfile,

pod 'PromisesObjC', '~> 1.2.3'

it gave me following error

Unable to find a specification for PromisesObjC (~> 1.2.3)

Then I tried with pod 'PromisesObjC'

it gave me following error

Unable to find a specification for PromisesObjC

I am using xcode 9.4

Hi, while writing some code I start noticing that a catch block was called even if the promise was fulfil. The catch was called in a complex chain so in the attempt to find the problem I reduced my code to:

    public func test() -> Promise<String> {
        return Promise<String> { fulfil, _ in
            fulfil("String")
        }
    }

called as follow:

        controller.test().then { (string) in
            print("result: \(string)")
        }.catch { (error) in
            print("Error: \(error.localizedDescription)")
        }

Running the above I get Error: The operation couldn’t be completed. (Swift.String error 1.)

I tracked down where promises decides that the above is an error to: Promise+Asynch.swift:28 where for some reason I truly don't understand if let error = value as? NSError generate a cast from String to NSError

While changing the code above to

    public func test() -> Promise<NSString> {
        return Promise<NSString> { fulfil, _ in
            let string = String("12")
            fulfil(string as NSString)
        }
    }

then the fulfil goes well and the .then is called

I tried to reproduce the behaviour I see in my project in the Promises test suite without success.

I don't understand what is going on here, any help is appreciated.

for this method:

  @objc
  public func allFoo() -> Promise<NSArray>.ObjCPromise<NSArray>
  {
    return promiseSwiftArrayOfFoo().then { $0 as NSArray }.asObjCPromise()
  }

Crashes swiftc with:

Showing All Messages

1.	While generating Objective-C header [redacted]
2.	While printing 'TheClass' at [redacted]/TheClass.swift:14:8
3.	While printing type 'Promise<NSArray>.ObjCPromise<NSArray>'
4.	While printing type 'Value'

Update, the original code which also crashes (I thought the above might be simpler for the type mangler to resolve):

  @objc
  public func allFoo() -> Promise<[Foo]>.ObjCPromise<NSArray>
  {
    return promiseSwiftArrayOfFoo().asObjCPromise()
  }

On the readme is says that using promises makes it easier to retry asynchronous operations. I couldn't find a retry method or anything of the sort, so what would be the simplest way to retry an operation using promises?

Thanks.

After the update to Swift 5 the swift_version was deleted from PromisesSwift.podspec (70c337e196c81f795eedb5d7a42cf966f07cdc3d). But now, Xcode keeps showing the "Conversion to Swift 5 is available" warning:

Putting it back will make the warning disappear.

Is there any way to completely ignore an Error? For example, when I reject a Promise with something like PromiseCancelledError, I don't want the downstream catches to handle this error. I want the Promise to be terminated and produce no output at all. Both catch and recover are not working for this case.

Hi I have looked through the code and was wondering about some parts of it, I would really appreciate if you could share some light when creating a promise with the following code: link

+ (instancetype)onQueue:(dispatch_queue_t)queue async:(FBLPromiseAsyncWorkBlock)work {
  NSParameterAssert(queue);
  NSParameterAssert(work);

  FBLPromise *promise = [[self alloc] initPending];
  dispatch_group_async(FBLPromise.dispatchGroup, queue, ^{
  work(
        ^(id __nullable value) {
          if ([value isKindOfClass:[FBLPromise class]]) {
            [(FBLPromise *)value observeOnQueue:queue
                fulfill:^(id __nullable value) {
                  [promise fulfill:value];
                }
                reject:^(NSError *error) {
                  [promise reject:error];
                }];
          } else {
            [promise fulfill:value];
          }
        },
        ^(NSError *error) {
          [promise reject:error];
        });
  });
  return promise;
}

1. What is the purpose of dispatch_group_async(FBLPromise.dispatchGroup? I mean why dispatch_group_async what the purpose of groupes (I feel it like synchronizes the calls )
2. if the queue was asynchronous (not serial by default) what guarantee that work will be executed after the calling code

With the example in the doc, https://github.com/google/promises/blob/master/g3doc/index.md#retry

retry method wraps a method that always returns a new Promise, so when the Promise of the first time method failed, retry will call the fetch method again and create a new Promise, and all work perfectly.

But if retry a Promise variable, things get wired.

let p = Promise<Int> { resolve, reject in
    print("promise")
    reject(NSError(domain: "promise", code: 1, userInfo: nil))
}

retry {
    p
}.then { _ in
    print("then")
}.catch { _ in
    print("catch")
}

code wrapped by Promise p will only run once, not twice, does this is a bug or feature?

In iOS 16 string are convertible to NSError and because of this promises are getting rejected. Kindly check the line number 28 in below URL where issue is occurring .

https://github.com/google/promises/blob/46c1e6b5ac09d8f82c991061c659f67e573d425d/Sources/Promises/Promise%2BAsync.swift

When statically linked, the Promises categories don't get linked and apps crash in Swift UI previews.

A workaround may be to add a symbol to the category implementation files that is referenced from a non-category file.

See https://github.com/firebase/firebase-ios-sdk/issues/8005 and https://github.com/firebase/firebase-ios-sdk/issues/9916