> On May 2, 2016, at 5:53 PM, Joe Groff via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> I can't think of any problems that would block us from doing that today. It'd
> be pretty easy to write an ErrorProtocol extension that just forwards
> NSError's interface via bridging, and I bet that'd cover most use cases for
> 'as NSError':
>
> extension ErrorProtocol {
> var domain: String { return NSError(self).domain }
> var code: Int { return NSError(self).code }
> var userInfo: [String: AnyObject] { return NSError(self).userInfo }
> /* etc. */
> }
>
> -Joe
This could be fantastic if it accompanied the addition to ErrorProtocol of an
“userInfo” property (or even _userInfo, although I’d really prefer that all
three of these be de-underscored) that NSError(self) would pick up on when
doing the conversion. Otherwise, we’re just going to have to keep on using
custom .toNSError() methods instead of the official way, so it won’t matter if
the latter is “as NSError” or “NSError(foo)” or something else.
Charles
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
