Promisekit: Make Promise generic to its Error type too?

Created on 9 Sep 2019  路  4Comments  路  Source: mxcl/PromiseKit

As development of v7 is well underway, and I just ran into this limitation, I thought I'd make the request: Promise should be generic to its Error type.

This was previously, and extensively, discussed in #135. However, it's been over 4 years and much has changed, including the addition of Result to the language and the fact that Error now conforms to itself, making possible a fully type-safe error pipeline. We recently made this change in Alamofire, making our Response types generic to the Failure type as well as the Success type. However, for projects using Alamofire (or any API that produces typed errors) and PromiseKit, this creates a rather tedious developer experience of having to cast back out to the known error type before processing. Personally, I don't see much in the way of a downside.

What do you think?

Most helpful comment

Yeah, given this thought. Seems like the right choice.

All 4 comments

I think it鈥檚 notable that Swift NIO鈥檚 Future type doesn鈥檛 do this.

Not to say I鈥檓 against it, but it seems like this change could cascade into quite an end-user burden, perhaps your experience with Alamofire here is proof?

So I'm all for it, provided it never becomes a PITA for our end-users. I've always cared that this library is the most pleasant futures library for Swift/ObjC, so, you know.

The last major update to NIO was released just after the release of Swift 5, so it's likely there wasn't time to make such a significant change, if it was even considered. In a quick search I can't find any issues discussing making the type doubly generic at all, so it's also likely it hasn't been suggested since it became possible in the language with Error self conformance.

We'll see how the change in Alamofire works out, as it's a very recent change between the betas and RCs. In most usage, the doubly generic type and the standardization of AFError as the default error type should make things easier for users, as they no longer need to cast to AFError in some cases and other system error types in others, and can exhaustively switch on all of the errors produced by Alamofire.

Yeah, given this thought. Seems like the right choice.

One example is the function from RequestInterceptor that comes from _Alamofire_.

Example of function that uses Result

public func adapt(_ urlRequest: URLRequest, for session: Session, completion: @escaping (Result<URLRequest, Error>) -> Void)

Was this page helpful?
0 / 5 - 0 ratings