[swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

[Colin Cornaby]

> And my two cents is:
> 
> NSError is antiquated, and enums conforming to ErrorType, with associated types on the case values, are much better. They are cleaner, they are easier to use, and they are nicer to look at.

And I still think that’s a platform choice. If a platform wants to define it’s errors as a Swift enum, or if a developer is defining their own independent platform, that’s a semi-reasonable thing to do. But I think trying to force all the platforms (Apple and non-Apple) into an enum shaped box for cross platform Swift is going to be problematic. If the authors of Cocoa want to begin defining all their errors as enums, the ball is certainly in their court, but it doesn’t feel right to me to promote that up to a language concern.

Before multiplatform Swift, I was totally onboard with the idea of supercharging ErrorType, but the more I think about it, and the more I look at lower level stuff that we could begin using Swift for on other platforms, the more I think having larger error types needs to be a decision made by the host platform API on a case by case basis. And I’m not convinced an enum is an appropriate error tool for all cases, even though it is certainly appropriate for a lot of cases.

I do think there are some weird sharp edges around NSError/ErrorType that aren’t specific to NSError, and will continue cutting people’s fingers on other platforms (for example, if I had a C API that defined it’s own error type as a struct, I’d be having a lot of the same problems.) I haven’t been able to come up with any reasonable ideas though that would fix everything.

One thing I think could be done is that NSError could somehow be made to conform to RawRepresentable, which would then take care of a lot of this.

The code could then become:
enum MyError: NSError {
    case JustFouledUp(domain: .., code: .., userInfo: ..)
    case CouldntDealWithFile(domain: .., code: .., userInfo: ..)
    case CouldntDealWithSomeValue(domain: .., code: .., userInfo: ..)
}

…with no need for the functions to implement to provide out the other usual data. I know some consider the NSError initializers kind of awful, that’s something that could be dealt with at the NSError API level. I actually think the above looks a lot cleaner, although I know I skipped over some of the mess with ellipsis. And API developers don’t have to implement manual, hand rolled bridging.

This seems cleanest to me, and would carry going forward with Error in OSS Foundation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151224/3c83641a/attachment.html>