[swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Kevin Ballard]

It did not eliminate that ability at all. You just need to say
`Swift.Error` instead of `Error` when referring to the protocol if a
nested `Error` type is in scope. For example:

class MyClass {
    enum Error: Swift.Error {
        case somethingWentWrong
    }
}

-Kevin Ballard

On Tue, Aug 2, 2016, at 10:30 AM, Jon Shier via swift-evolution wrote:
> I’m not sure where to put such feedback, but the ErrorProtocol to
> Error rename that accompanied the implementation of this proposal is
> very, very painful. It completely eliminates the very useful ability
> to embed an associated Error type inside other types, as those types
> now conflict with the protocol. Also, was this rename accompanied by
> an evolution proposal? It seems like the change was just made when
> this proposal was implemented.
> Also, the adoption of this proposal by the Cocoa(Touch) frameworks as
> seen in Xcode 8 beta 4 has made asynchronous error handling quite a
> bit more arduous. For example, the CKDatabase method
> fetch(withRecordID recordID: CKRecordID, completionHandler:
> (CKRecord?, Error?) -> Void) returns an `Error` now, meaning I have to
> cast to the specific `CKError` type to get useful information out of
> it. Is this just an unfortunate first effort that will be fixed, or is
> this the expected form of these sorts of APIs after this proposal?
>
>
>
> Jon Shier
>
>
>> On Jul 12, 2016, at 8:44 AM, Shawn Erickson via swift-evolution <swift-
>> evolution at swift.org> wrote:
>>
>> Thanks for the effort on the proposal and discussion and thanks to
>> those working in the implementation.
>>
>> -Shawn
>> On Tue, Jul 12, 2016 at 12:25 AM Charles Srstka via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>> Wow, thanks! I’m delighted that Apple found this improvement to be
>>> worth inclusion in Swift 3. This will truly make the language much
>>> nicer to use with the Cocoa frameworks.
>>>
>>>  Thanks!
>>>
>>>  Charles
>>>
>>>  > On Jul 11, 2016, at 11:19 PM, Chris Lattner via swift-evolution
>>>  > <swift-evolution at swift.org> wrote:
>>>  >
>>>  > Proposal Link:
>>>  > https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md
>>>  >
>>>  > The review of "SE-0112: Improved NSError Bridging" ran from June
>>>  > 30 ... July 4, 2016. The proposal has been *accepted*:
>>>  >
>>>  > The community and core team agree that this proposal is a huge
>>>  > step forward that enriches the experience working with and
>>>  > extending the Cocoa NSError model in Swift.  The core team
>>>  > requests one minor renaming of
>>>  > "attemptRecovery(optionIndex:andThen:)" to
>>>  > "attemptRecovery(optionIndex:resultHandler:)”.  It also discussed
>>>  > renaming CustomNSError and RecoverableError, but decided to stay
>>>  > with those names.
>>>  >
>>>  > Thank you to Doug Gregor and Charles Srstka for driving this
>>>  > discussion forward, and for Doug Gregor taking the charge on the
>>>  > implementation effort to make this happen for Swift 3!
>>>  >
>>>  > -Chris Lattner
>>>  > Review Manager
>>>  >
>>>  > _______________________________________________
>>>  > swift-evolution mailing list
>>>  > swift-evolution at swift.org
>>>  > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>  _______________________________________________
>>>  swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _________________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160802/bcdebf45/attachment.html>