<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 4, 2016, at 10:15 PM, Ben Rimmington <<a href="mailto:me@benrimmington.com" class="">me@benrimmington.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md</a>><br class=""><br class="">If <Foundation/NSError.h> uses NS_EXTENSIBLE_STRING_ENUM for `domain` names and `userInfo` keys, would a generic type (cf. DispatchSpecificKey) also be possible?<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>FOUNDATION_EXPORT NSErrorUserInfoKey<NSNumber> const NSStringEncodingErrorKey;<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>FOUNDATION_EXPORT NSErrorUserInfoKey<NSURL> const NSURLErrorKey;<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>FOUNDATION_EXPORT NSErrorUserInfoKey<NSString> const NSFilePathErrorKey;<br class=""><br class="">This could provide a more typesafe API, without the need for typed accessors in each SDK overlay.<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func userInfoValue<Value>(forKey: NSError.UserInfoKey<Value>) -> Value?<br class=""></div></div></blockquote><div><br class=""></div><div>This is complicated by the fact that userInfo keys don’t have to be strings, so making the type stronger may not be possible. </div><div><br class=""></div><div>That technicality aside, why? While NSError itself is centered around userInfo, Swift errors are not: they’re strongly-typed values for which one would expect to have accessors to get additional information about the errors. One would not define new userInfo keys in Swift nor (directly) define new error domain strings, except to refer to those errors from Objective-C code. In many ways, that’s the goal of this proposal: to take away the need for Swift programmers to think about NSError’s domain/code/userInfo by providing type-safe, easy-to-use APIs. In that context, it seems unfortunate to restyle something that Swift programmers shouldn’t have to use.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">The following comment is incorrect, AFAIK. The `helpAnchor` is the name attribute of a HTML anchor element.<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>/// A localized message providing "help" text if the user requests help.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>var helpAnchor: String? { get }<br class=""></div></div></blockquote><div><br class=""></div>Apple’s documentation says:</div><div><br class=""></div><div><p class="Objective-C para" style="border: 0px; font-size: 1.4em; margin: 0px 0px 15px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(65, 65, 65); line-height: 20.299999237060547px; display: inline-block; font-family: Helvetica, Arial, sans-serif;"><code class="code-voice" style="border: 0px; font-size: 0.85em; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word; position: relative;">NSHelpAnchorErrorKey</code></p><span style="font-family: Helvetica, Arial, sans-serif; font-size: 10px; background-color: rgb(249, 249, 249);" class=""></span><div class="definition" style="border: 0px; font-size: 10px; margin: 0px 0px 15px; outline: 0px; padding: 0px; vertical-align: baseline; font-family: Helvetica, Arial, sans-serif;"><p class="para" style="border: 0px; font-size: 1.4em; margin: 0px 0px 15px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(65, 65, 65); line-height: 20.299999237060547px;">The corresponding value is an <code class="code-voice" style="border: 0px; font-size: 0.85em; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;">NSString</code> containing the localized help corresponding to the help button. See <code class="code-voice" style="border: 0px; font-size: 0.85em; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(128, 128, 128); font-family: Menlo, monospace; word-wrap: break-word;"><a href="https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Classes/NSError_Class/#//apple_ref/occ/instp/NSError/helpAnchor" data-renderer-version="2" style="border: 0px; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(0, 136, 204); text-decoration: none;" class="">helpAnchor</a></code> for more information.</p></div><div style="border: 0px; font-size: 1.4em; margin: 0px; outline: 0px; padding: 0px; vertical-align: baseline; color: rgb(65, 65, 65); line-height: 20.299999237060547px; font-family: Helvetica, Arial, sans-serif;" class="">Available in OS X v10.6 and later.</div></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Also in the LocalizedError protocol, should the `errorDescription` property return a non-optional String, to match the NSError API?<br class=""></div></div></blockquote><div><br class=""></div><div>No; one can omit the errorDescription property (which is tantamount to omitting the NSLocalizedDescriptionKey value in NSError’s userInfo) and Cocoa will create a default.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Should there be an API for non-localized errors? This is currently available in <CoreFoundation/CFError.h> using kCFErrorDescriptionKey.<br class=""></div></div></blockquote><div><br class=""></div><div>IMO, no. Leave it at the defaults or do it correctly.</div></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">If error recovery and help anchors are only available in macOS, should there be conditional #if os(macOS) blocks?<br class=""></div></div></blockquote><div><br class=""></div>Practically speaking, this </div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">Is the `errorDomain` property of CustomNSError allowed to vary its result? For example:<br class="">* an SQLite error <<a href="https://www.sqlite.org/rescode.html" class="">https://www.sqlite.org/rescode.html</a>> could return the "primary result code" name.<br class="">* an HRESULT <<a href="https://en.wikipedia.org/wiki/HRESULT" class="">https://en.wikipedia.org/wiki/HRESULT</a>> wrapper could return the FACILITY name.<br class="">Would a varying domain affect the registered setUserInfoValueProvider(forDomain:provider:) callback?</div></div></blockquote><br class=""></div><div>‘errorDomain’ must not vary, because it effectively identifies the Swift type.</div><div><br class=""></div><div>In fact, it should be ‘static’. I’ll fix that, thanks!</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""></div></body></html>