Make Promise generic to its Error type too?

[jshier]

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?

[mxcl]

I think it’s notable that Swift NIO’s Future type doesn’t do this.

Not to say I’m 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.

[jshier]

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.

[mxcl]

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

[CristianCardosoA]

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)

[mxcl]

NIO still doesn’t. How did it work out with Alamofire?

[jshier]

NIO hasn't made a major release since May, 2019, so I don't think that means much.

Alamofire shipped v5 in Feb. 2020 (took a while) and I haven't heard any complaints about the generic error. Just a few cases of v4 -> v5 migration needing to handle AFError specifically in some cases. The RequestInterceptor (really RequestAdaptor) method is actually one of the few places where we still use manual completion handlers (oops) rather than a throwing function. This means we actually have functionality internally to wrap it into an AFError if we need to, which is actually a source of friction for us and users. There are other areas internally where we recover an AFError from the erasure, but none of them intersect with user visible code like this an so are easier to deal with

That said, given Swift hasn't added typed throws yet, and the proliferation of throwing with the new async APIs, it seems likely dealing with Error will be the default for many public APIs for the near future. Alamofire will continue to produced typed output that doesn't throw until the user chooses to do so, even in the async APIs. So ultimately our typed errors aren't going anywhere.

In the end, however, I'm no longer working on the codebase that is using PromiseKit and so no longer have this need. It still seems like a good idea. You can also help a bit by offering typealiases which erase the error for users. Alamofire prefixes them with AF (AFDataResponse<T> = DataResponse<T, Error>) but there may be better names for error-erased promises.