Handling multiple error types.

[inamiy]

This pull request will fix #37 by:

• improving type-inference for overloaded then()/success()/failure() to not use the wrong one
• using then() to promote Task type from Task<P1, V1, E1> to Task<P2, V2, E2> (including E1 -> E2 Error type change)

For more information, please see MultipleErrorTypesTests.swift.

Caveat

let task1: Task1 = self.request1()
task1.success { _ -> Task2 in
    return self.request2() // let's say, this task will fail
}.then { value, errorInfo -> Void in
    // NOTE:
    // Though `errorInfo` will still be non-nil, `errorInfo!.error` will become as `nil`
    // if Task1 and Task2 have different Error types.
}

If Task1 and Task2 have different Error types and request2 fails,
you will still receive errorInfo as non-nil, but now errorInfo!.error will become as nil.

• MultipleErrorTypesTests.swift#L114-L150

This is because there is no way to convert request2's error back to task1's Error type (which is required in success() task-flow).

To avoid this default behavior, it is user's job to add error-conversion logic to maintain same Error type throughout the task-flow, by adding another type-promotable then()/success()/failure().

• MultipleErrorTypesTests.swift#L152-L190

[tokorom]

@inamiy LGTM 💯

SwiftTask became stronger and I love deepened it :)

[inamiy]

@tokorom
Thank you for catching this nasty bug!
Error mapping was really a needed feature, so I appreciate your reporting issue 😉

I will add a bit more comments and tests before bumping to 3.3.0.

[inamiy]

I added fac9ff6 to demonstrate how to avoid trappy Error conversion.
Please check updated top comment as well.

Ready to