* Promise.value when T == Void
* Guarantee.value where T == Void
* Replace class with static because Promise is final
* Optimised Guarantee.value where Value == Void
* Add comment
* Implementation with Void()
* Tests for Promise<Void>.value
* Tests for Guarantee<Void>.value
* Added tests for Promise<Void> and Guarantee<Void>
* Fixed bug where pendingPromiseDeallocated event was incorrectly reported as a waitOnMainThread event.
* Now logs if a Guarantee is deallocated before it has been fulfilled.
* Fixed bug where pendingPromiseDeallocated event was incorrectly reported as a waitOnMainThread event. Added test which should have caught this bug in the first place.
* Kick Travis CI
Couldn’t have two variants of `ensure` without the dreaded ambiguity issues.
Sadly Swift cannot infer the type for multiline closures where there are two possible functions for it to match. :(
Well great. This series of fixes, fixes builds failing but looking like they passed, and fixes the issues that were failing.
Fortunately it was just compile issues in the tests, no tests were failing.
For me this proves that YAML sucks, BASH sucks and TRAVIS sucks.
Our existing hack broke the new Xcode build system (see #724).
Also, CocoaPods 1.4 didn’t like it.
So I had to rewrite with composition instead adding additional methods via an objc category.
The cause of the issue was that the framework required that the -Swift.h file be generated before the objc portions were built (since the objc extended the swift portion), and neither build system guarantees this.
All tests pass. However it is not as efficient as before. Could use some optimizations.
This because `Promise(value:)` is selected for PMK-4’s pending initializer due to trailing closure syntax and the fact that `T` could be anything. I guess this isn’t a Swift bug, but geez.
This is a real problem for people migrating to 5 from 4, such that I have decided 5 must be deprecated.
The severity is due to Swift giving a very misleading error diagnostic when it uses `Promise(value:)`, because as you can guess you end up with:
Promise<(T->Void, Error->Void)>
As your inferred type.
Because we no longer have ambiguity between `Promise { seal in` and `Promise(value:` I have removed the `.pending` parameter for that usage which will also aid migration.
In some cases this leads to less nice code, but mostly it’s fine due to being able to do `.value(1)` where `Promise` can be inferred. The trade off is worth it though as PromiseKit should be delightful to use and as it stands, it is a pain due to how Swift is.
While the use of TimeInterval is understandable from the perspective
of maintaining parity with the Objective-C function PMKAfter, it's not
quite as strongly typed as DispatchTimeInterval. Also, what's really
going on is a dispatch after a deadline and so support for both seconds
and DispatchTimeInterval seem warranted.
