Renaming the variadic maps to zip

[John-Connolly]

Just a thought, it would be more inline with rx

public func map<A, B, Result>(
    to result: Result.Type,
    _ futureA: Future<A>,
    _ futureB: Future<B>,
    _ callback: @escaping (A, B) throws -> (Result)
) -> Future<Result> {
    return futureA.flatMap(to: Result.self) { a in
        return futureB.map(to: Result.self) { b in
            return try callback(a, b)
        }
    }
}

vs

public func zip<A, B, Result>(
    to result: Result.Type,
    _ futureA: Future<A>,
    _ futureB: Future<B>,
    _ callback: @escaping (A, B) throws -> (Result)
) -> Future<Result> {
    return futureA.flatMap(to: Result.self) { a in
        return futureB.map(to: Result.self) { b in
            return try callback(a, b)
        }
    }
}

[calebkleveter]

+ 1 to this. Not only would it match Rx better (I'm taking your word for that 😄), but that matches the standard Swift API better with their zip method for sequences.

[tanner0101]

I kind of prefer Swift NIO's solution to this:

futureA.and(futureB).and(futureC).then { ((a, b), c) in ... }

It doesn't have the same restrictions as map / zip.

[John-Connolly]

Yeah true thats better saves a bunch of code.

[calebkleveter]

@tanner0101 One thing I don't like about .and is that you end up with deep nesting and it's a pain to deconstruct:

future1.and(future2).and(future3).and(future4).map { futures in
    let four = futures.1.1.1
}

I wish you could deconstruct tuples in closure arguments, but you can't and it sounds like it was a conscious decision not to. Maybe someone could propose and implement it though.

[tanner0101]

@calebkleveter i agree. It's annoying. This is definitely Swift's fault IMO. I still think the trade off of not polluting the source code with a ton of variadic overloads is worth it though.

Maybe someone from the Swift or NIO team has an idea on how to get an API better than futures.1.1.1?