<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">On Dec 24, 2015, at 2:56 AM, Colin Cornaby &lt;<a href="mailto:colin.cornaby@mac.com" class="">colin.cornaby@mac.com</a>&gt; wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">And my two cents is:</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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.</div></div></div></blockquote><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div><br class=""></div><div>That’s a bit of a non-sequitur, though. Since ErrorType is a protocol, it can be anything. It can be an enum, a struct, a class, whatever you want. No one’s forcing enums, or anything really; enum just happens to be, in my opinion, the nicest of these to use. Someone else in the thread disagreed and preferred structs. That’s all fine; the whole point of ErrorType is that you can use what you want; there should just be a nicer way to bridge these things, in whatever form you prefer them, to NSError, so that we’re not forcing anyone into an NSError-shaped box.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">The code could then become:</div><div class="">enum&nbsp;MyError:&nbsp;NSError&nbsp;{<br class="">&nbsp; &nbsp;&nbsp;case&nbsp;JustFouledUp(domain: .., code: .., userInfo: ..)<br class="">&nbsp; &nbsp;&nbsp;case&nbsp;CouldntDealWithFile(domain: .., code: .., userInfo: ..)<br class="">&nbsp; &nbsp;&nbsp;case&nbsp;CouldntDealWithSomeValue(domain: .., code: .., userInfo: ..)<br class="">}</div></div></div></blockquote><div><br class=""></div><div>This is impossible, because enums with raw values can’t have cases with arguments. Try it: it won’t compile.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">…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.</div><div class=""><br class=""></div><div class="">This seems cleanest to me, and would carry going forward with Error in OSS Foundation.</div></div></div></blockquote></div><br class=""><div class="">Honestly, I can’t imagine anyone *not* finding the NSError initializers awful. It’s a truly cringe-worthy API. Beyond that, forcing every error object, even ones that are never touching Obj-C code at all, to be backed by a bulky NSError object is pretty unreasonable, IMO. I’d much prefer to store the error data using lean and mean Swift-native constructs, and bridge to NSError only when it’s needed to interact with AppKit/UIKit.</div><div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></body></html>