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@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:
> >
> > Proposal Link:
> > https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md
> >
> > <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@swift.org <mailto:swift-evolution@swift.org>
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> > <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
