This is a new feature and improvement on #50 to add side-effects after completion (success or failure) of task.

Please see SwiftTaskTests.swift#L425-L474 for more detail.

Note

Using Self for returning value will fail in Xcode 7.0, but not in 7.1.

would be great to have a zip function that takes two tasks with different progress, value and error types and returns a task that returns a tuple of values.

I've implemented the function with the signature

public class func zip<P1, V1, R1, P2, V2, R2>(task1: Task<P1, V1, R1>, _ task2: Task<P2, V2, R2>) -> Task<(P1, P2), (V1, V2), (R1?, R2?)>

but unfortunately I'm unable to call it without the error:

Cannot invoke 'zip' with an argument list of type '(Task<Void, String, String>, Task<Void, String, String>)'

Maybe I'm completely confused about the way this works, but shouldn't a failureClosure return Void? Currently, it's trying to return the Value type.

The README shows failure returning Void, which makes sense. Why is the failureClosure returning the value? If the task has failed, shouldn't there be no value?

I'm unable to use this, because, for the task I'm trying to create, if the task has failed, I can't return a value, since the value doesn't exist.

Hi, I want conditional retryable feature. In my use case, I want retry failed task with date time predication like this.

task.retry(5) { () -> Bool in
  let now = NSDate()
  return now.compare(expireDate) == .OrderedAscending
}.success { (value) -> Void in
 ...

What do you think about this?

This pull request brings a new retryable feature for future ver 2.1.0.

task.try(n) returns a new task that is retryable for n-1 times, and is conceptually equal to

task.failure(clonedTask1).failure(clonedTask2)...

with n-1 failure-able.

Usage

task.try(3).success { ...
    // this closure will be called even when task is rejected for 1st & 2nd try 
    // but fulfilled in 3rd try.
}

// shorthand
(task ~ 3).then { ... }

I am having problems getting progress events to propagate up the chain of tasks.

I have a lower level String task that will generate progress. Then, upon success I want to convert that String value to in Int if possible or an error otherwise. I expect progress handlers on both tasks to be called whenever progress changes on the lower level task. Is this a valid expectation?

To be clear, consider the following test (using Nimble) that always fails where indicated below:

class ProgressTest: QuickSpec {
    override func spec() {
        var stringTask: Task<Float, String, NSError>!
        var stringTaskProgressHandler: (Float ->Void)?
        var stringTaskProgressValue: Float?

        var intTask: Task<Float, Int, NSError>!
        var intTaskProgressValue: Float?

        beforeEach {
            stringTask = Task<Float, String, NSError> { progress, fulfill, reject, configure in
                stringTaskProgressHandler = progress
            }.progress { oldValue, newValue in
                stringTaskProgressValue = newValue
            }

            intTask = stringTask.success { stringValue -> Task<Float, Int, NSError> in
                if let intValue = Int(stringValue) {
                    return Task(value: intValue)
                } else {
                    return Task(error: NSError(domain: "test", code: 123, userInfo: nil))
                }
            }.progress { oldValue, newValue in
                intTaskProgressValue = newValue
            }
        }

        describe("when string task has progress") {
            beforeEach {
                stringTaskProgressHandler?(0.5)
            }

            it("string task progress should fire") {
                expect(stringTaskProgressValue).toEventually(equal(0.5))
            }
            it("should propagate progress to intTask") {
                // ************ This test fails! ************
                expect(intTaskProgressValue).toEventually(equal(0.5))
            }
        }
    }
}

Thoughts?

When calling Task.all() with many tasks and one of the task was failed, canceling all tasks process will start. But from the current algorithm, it makes recursive call. If the number of tasks is 10000 and the first task is failed, the depth of call is about 10000 and it causes stack overflow. So, the proposal is that prepare flag for limiting the depth of call to be 1.

            }.failure { (errorInfo: ErrorInfo) -> Void in

                    lock.lock()
                    _reject(errorInfo)

                    for task in tasks {
                        task.cancel()  // <- this call invokes ".failure" of another task in the same context
                    }
                    lock.unlock()
            }

Is it possible to retain task while it is executed in one scope? I have found that tasks deinit after creating )) even they are returned from success block of other task. Probably we need something that will retain task while it is executing like in next example:

public class Task<Progress, Value, Error> {

    //...

    class func createTask<Progress, Value, Error>(initClosure: InitClosure) -> Task<Progesss, Value, Error> {
        // Paused
        let task = Task<Progesss, Value, Error>(paused: true, initClosure: initClosure)
        task.onFinish = {
            TasksRegistry.unregister(task) // Release
        }
        TasksRegistry.register(task) // Retain
        return task
    }

    //...
}

Or is there any other ways to do so?

Under the following conditions, last then not called.

• Task.all chain more than once
• all tasks is empty

what would be a good way to do it?

Sample code

final class Image {
  let url: String

  var downloaded: Bool = false
  var converted: Bool = false

  typealias DownloadTask = Task<NSProgress, String, NSError?>
  typealias ConvertTask = Task<NSProgress, String, NSError?>

  init(url: String) {
    self.url = url
  }

  func download() -> DownloadTask {
    return DownloadTask { progress, fulfill, reject, configure in
      // download image and cache
      self.downloaded = true
      return fulfill("path to image")
    }
  }

  func convert() -> ConvertTask {
    return ConvertTask { progress, fulfill, reject, configure in
      // convert image
      self.converted = true
      return fulfill("path to converted image")
    }
  }
}

func downloadAndConvertAll() {
  let images = [
    Image(url: "http://example.com/1.jpg"),
    Image(url: "http://example.com/2.jpg"),
    Image(url: "http://example.com/3.jpg"),
  ]

  // I want to exclude downloaded image
  let downloadTasks = images.filter { !$0.downloaded }.map { $0.download() }

  // downloadTasks.count == 0 and convertTasks.count == 0 => doSomething not called
  Task.all(downloadTasks).then { _ -> Task<Image.ConvertTask.BulkProgress, [String], NSError?> in
    // I want to exclude converted image
    let convertTasks = images.filter { !$0.converted }.map { $0.convert() }
    return Task.all(convertTasks)
  }.then { _ in
    doSomething()
  }
}

func doSomething() {
  print("doSomething")
}

found workaround

Task.all(downloadTasks.count > 0 ? downloadTasks : [Image.DownloadTask(value: "dummy")])

and

Task.all(convertTasks.count > 0 ? convertTasks : [Image.ConvertTask(value: "dummy")])

It will be handy if we could just add event handlers without changing values or types of Tasks (now SwiftTask requires .success / .failure closures to return a new value or Task). In particular, it's painful to use .failure when you just want to add an event handler and don't want to recover from failures, because it still requires successful return value.

This PR adds .success / .failure methods which have closures of returning type Void for their arguments. You pass a closure returns nothing (or Void), and you get a new Task nearly identical to previous one but it keeps the closure as an event handler.

This change disables handling Tasks with Void as the Value type (eg. Task<Progress, Void, Error>), but no one might want to use such creepy Tasks :wink:

This pull request will fix https://github.com/ReactKit/SwiftTask/issues/37 by:

• [x] improving type-inference for overloaded then()/success()/failure() to not use the wrong one
• [x] 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

I see that there is a branch for Swift 3 support open. What is the roadmap for having the Swift 3 branch merged and available publicly via cocoapods?

(Specifically, looking to consume the library in a podspec, where the branch cannot be specified)

Can you help please? Found some case when failure block is called after task is fulfilled. I don't understand how could it be possible but from stacktrace of XCode cancel method is called from task deinit. This cause the task to be handled as canceled in my code, but I has fulfilled it. I don't understand what I made wrong.

I implement "when" method. It corresponds to multiple value type.

Usage

• success pattern

        let task1 = Task<Float, String, NSError?> { fulfill, reject in fulfill("Success") }
        let task2 = Task<Float, Int, NSError?> { fulfill, reject in fulfill(1) }
        let task3 = Task<Float, Double, NSError?> { fulfill, reject in fulfill(1.1) }

        Task<Float, (String, Int, Double), NSError>.when((task1, task2, task3)).success { (string, int, double) -> Void in
            print(string) // -> Success
            print(int) // -> 1
            print(double) // -> 1.1
        }.failure { (error, isCancelled) -> Void in
            fatalError()
        }

*failure pattern

        let task1 = Task<Float, String, String> { fulfill, reject in fulfill("Success") }
        let task2 = Task<Float, Int, String> { fulfill, reject in fulfill(1) }
        let task3 = Task<Float, Double, String> { fulfill, reject in  reject("Rejected") }

        Task<Float, (String, Int, Double), String>.when((task1, task2, task3)).success { (string, int, double) -> Void in
            fatalError()
        }.failure { (error, isCancelled) -> Void in
            print(error) // -> Optional("Rejected")
        }