<https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md>
If <Foundation/NSError.h> uses NS_EXTENSIBLE_STRING_ENUM for `domain` names and
`userInfo` keys, would a generic type (cf. DispatchSpecificKey) also be
possible?
FOUNDATION_EXPORT NSErrorUserInfoKey<NSNumber> const
NSStringEncodingErrorKey;
FOUNDATION_EXPORT NSErrorUserInfoKey<NSURL> const NSURLErrorKey;
FOUNDATION_EXPORT NSErrorUserInfoKey<NSString> const NSFilePathErrorKey;
This could provide a more typesafe API, without the need for typed accessors in
each SDK overlay.
func userInfoValue<Value>(forKey: NSError.UserInfoKey<Value>) -> Value?
The following comment is incorrect, AFAIK. The `helpAnchor` is the name
attribute of a HTML anchor element.
/// A localized message providing "help" text if the user requests help.
var helpAnchor: String? { get }
Also in the LocalizedError protocol, should the `errorDescription` property
return a non-optional String, to match the NSError API?
Should there be an API for non-localized errors? This is currently available in
<CoreFoundation/CFError.h> using kCFErrorDescriptionKey.
I agree with Brent's feedback of the RecoverableError protocol.
<http://thread.gmane.org/gmane.comp.lang.swift.evolution/22485/focus=22793>
* It reminds me of the deprecated UIActionSheetDelegate, which also used an Int
index to identify an action.
* The newer UIAlertController uses UIAlertAction objects, similar to Brent's
ErrorRecoveryOption protocol.
If error recovery and help anchors are only available in macOS, should there be
conditional #if os(macOS) blocks?
Is the `errorDomain` property of CustomNSError allowed to vary its result? For
example:
* an SQLite error <https://www.sqlite.org/rescode.html> could return the
"primary result code" name.
* an HRESULT <https://en.wikipedia.org/wiki/HRESULT> wrapper could return the
FACILITY name.
Would a varying domain affect the registered
setUserInfoValueProvider(forDomain:provider:) callback?
-- Ben
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
