<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 Aug 2, 2016, at 10:30 AM, Jon Shier via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>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.</div></div></div></blockquote><div><br class=""></div><div>The rename was part of the proposal, in bullet #5 of the proposed solution (which, amusing, pastes as bullet #1 below):</div><div><br class=""></div><div><ol style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(51, 51, 51); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);" class=""><li style="box-sizing: border-box; margin-top: 0.25em;" class=""><p style="box-sizing: border-box; margin-top: 16px; margin-bottom: 16px;" class="">Rename <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">ErrorProtocol</code> to <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">Error</code>: once we've completed the bridging story, <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">Error</code> becomes the primary way to work with error types in Swift, and the value type to which <code style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; padding: 0.2em 0px; margin: 0px; background-color: rgba(0, 0, 0, 0.0392157); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px;" class="">NSError</code> is bridged:</p><div class="highlight highlight-source-swift" style="box-sizing: border-box; margin-bottom: 16px;"><pre style="box-sizing: border-box; font-family: Consolas, 'Liberation Mono', Menlo, Courier, monospace; font-size: 14px; margin-top: 0px; margin-bottom: 0px; line-height: 1.45; word-wrap: normal; padding: 16px; overflow: auto; background-color: rgb(247, 247, 247); border-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal;" class=""><span class="pl-k" style="box-sizing: border-box; color: rgb(167, 29, 93);">func</span> <span class="pl-en" style="box-sizing: border-box; color: rgb(121, 93, 163);">handleError</span>(<span class="pl-en" style="box-sizing: border-box; color: rgb(121, 93, 163);">_</span> <span class="pl-smi" style="box-sizing: border-box;">error</span>: Error, userInteractionPermitted: <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 134, 179);">Bool</span>)</pre></div></li></ol><div class=""><br class=""></div></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>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?</div></div></div></blockquote><div><br class=""></div><div>Prior to this proposal, you would have had to check the domain against CKErrorDomain anyway to determine whether you’re looking at a CloudKit error (vs. some other error that is passing through CloudKit), so error bridging shouldn’t actually be adding any work here—although it might be making explicit work that was already done or should have been done. Once you have casted to CKError, you now have typed accessors for information in the error:</div><div><br class=""></div><div><div>extension CKError {</div><div> /// Retrieve partial error results associated by item ID.</div><div> public var partialErrorsByItemID: [NSObject : Error]? {</div><div> return userInfo[CKPartialErrorsByItemIDKey] as? [NSObject : Error]</div><div> }</div><div><br class=""></div><div> /// The original CKRecord object that you used as the basis for</div><div> /// making your changes.</div><div> public var ancestorRecord: CKRecord? {</div><div> return userInfo[CKRecordChangedErrorAncestorRecordKey] as? CKRecord</div><div> }</div><div><br class=""></div><div> /// The CKRecord object that was found on the server. Use this</div><div> /// record as the basis for merging your changes.</div><div> public var serverRecord: CKRecord? {</div><div> return userInfo[CKRecordChangedErrorServerRecordKey] as? CKRecord</div><div> }</div><div><br class=""></div><div> /// The CKRecord object that you tried to save. This record is based</div><div> /// on the record in the CKRecordChangedErrorAncestorRecordKey key</div><div> /// but contains the additional changes you made.</div><div> public var clientRecord: CKRecord? {</div><div> return userInfo[CKRecordChangedErrorClientRecordKey] as? CKRecord</div><div> }</div><div><br class=""></div><div> /// The number of seconds after which you may retry a request. This</div><div> /// key may be included in an error of type</div><div> /// `CKErrorServiceUnavailable` or `CKErrorRequestRateLimited`.</div><div> public var retryAfterSeconds: Double? {</div><div> return userInfo[CKErrorRetryAfterKey] as? Double</div><div> }</div><div>}</div></div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Jon Shier</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 12, 2016, at 8:44 AM, Shawn Erickson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Thanks for the effort on the proposal and discussion and thanks to those working in the implementation.<br class=""><br class="">-Shawn<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Jul 12, 2016 at 12:25 AM Charles Srstka via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br class="">
<br class="">
Thanks!<br class="">
<br class="">
Charles<br class="">
<br class="">
> On Jul 11, 2016, at 11:19 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
> Proposal Link: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md" rel="noreferrer" target="_blank" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md</a><br class="">
><br class="">
> The review of "SE-0112: Improved NSError Bridging" ran from June 30 ... July 4, 2016. The proposal has been *accepted*:<br class="">
><br class="">
> 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.<br class="">
><br class="">
> 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!<br class="">
><br class="">
> -Chris Lattner<br class="">
> Review Manager<br class="">
><br class="">
> _______________________________________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>