Strictly I’d feel better to test all configurations, but PromiseKit only uses Foundation, so the chance that for some reason there is an API break or worse some kind of runtime issue is pretty low and I feel that we have to be kinder to Travis’s free infrastructure.
Tag 6.0.2
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.
I just ended up using the `attempt` example in some code, but had to make some syntactical fix-ups to get it to work and figured I'd send them back your way:
- `after` takes a `TimeInterval`, not a `DispatchTimeInterval`
- The signature referred to `source` instead of `body` (which needed to be marked `@escaping`)
- Missing `{`
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.
