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.
One of the tests was crashing later due to pending promises continuing to resolve and somehow the array of values contained a `nil`. I rewrote the specific when to not depend on optionals.
Since ErrorType is not (necessarily) an NSObject we needed to handle the unhandled tokens differently.
Instead we keep an ErrorConsumptionToken with the ErrorType and ensure we pass it around with subsequent promises.
This appears to work for all possible Swift paths and thus I think it will work for all ObjC paths too and it may be worth switching to this system.
The reason the other system was used (add a runtime iVar) is so that errors that are consumed but then end up going back into the a chain are known to already be consumed. However with further realization it is apparent that any error that goes back into a chain is unconsumed and thus the new system should be work well in all cases.
Because Little Bites of Cococa featured PromiseKit using this unavailable function we should provide any users that try to use it with a helpful pointer to when.
We cannot elegantly provide join for Swift, and frankly I’m not convinced it should have been added to our API at all: it breaks the first rule of promises: that errors propogate!
If you don’t want this feature you can compile defining PMKDisableProgress. You’ll want to ensure this flag is added for objc and Swift compilation units.
Closes#127
