<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=""><blockquote type="cite" class="">On May 2, 2016, at 4:48 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="">On May 2, 2016, at 3:45 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><p class="" style="box-sizing: border-box; margin: 0px 0px 16px; color: rgb(51, 51, 51); font-family: helvetica, arial, freesans, clean, sans-serif; font-size: 16px; background-color: rgb(255, 255, 255);"><code class="" 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;">NSError</code> bridging can also be extracted from the runtime, and the same functionality exposed as a factory initializer on <code class="" 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;">NSError</code>:</p></div></blockquote></div><div class="">I think that this proposal is overall really great, but what does it do to the “catch let x as NSError” pattern? What is the replacement? If the result is ugly, we may have to subset out NSError out of this pass, and handle it specifically with improvements to the error bridging story.</div></div></div></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></div><div class="">Grant me the serenity to accept the `NSError` I cannot change and the courage to change the bridging conversions I should. Grant me the wisdom to know the difference between a partial solution that offers a cleaner more predictable interface set now and a full solution that cannot be achieved in a reasonable timeframe.</div><div class=""><br class=""></div><div class="">-- E</div></div></div></blockquote></div><br class=""><div class="">Among the things that Billy Pilgrim could not change were the past, the present, and the future. Hopefully we have better luck, because the ErrorType to NSError bridging is currently a bit buggy.</div><div class=""><br class=""></div><div class="">Have a look at this code, and take a guess at what the results should be:</div><div class=""><br class=""></div><div class=""><div class="">import Foundation</div><div class=""><br class=""></div><div class="">extension ErrorType {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>public func toNSError() -> NSError {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>return self as NSError</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="">}</div><div class=""><br class=""></div><div class="">let error = NSError(domain: "Foo", code: -1, userInfo: [NSLocalizedFailureReasonErrorKey : "Something went wrong"])</div><div class=""><br class=""></div><div class="">let ns = error.toNSError()</div><div class=""><br class=""></div><div class="">print("Type of error was \(error.dynamicType), type of ns is \(ns.dynamicType)")</div><div class=""><br class=""></div><div class="">print("error's user info: \(error.userInfo)")</div><div class="">print("ns user info: \(ns.userInfo)”)</div></div><div class=""><br class=""></div><div class="">--</div><div class=""><br class=""></div><div class="">The results are a bit surprising:</div><div class=""><br class=""></div><div class=""><div class="">Type of error was NSError, type of ns is _SwiftNativeNSError</div><div class="">error's user info: [NSLocalizedFailureReason: Something went wrong]</div><div class="">ns user info: [:]</div></div><div class=""><br class=""></div><div class="">What happened was:</div><div class=""><br class=""></div><div class="">1. The toNSError() method showed up for our NSError, since NSError is presented to Swift as conforming to ErrorType. </div><div class=""><br class=""></div><div class="">2. However, due to a lack of dynamism, the code in the extension assumes that we have a Swift native error and *not* an NSError, so it goes ahead and wraps the NSError inside another NSError.</div><div class=""><br class=""></div><div class="">3. And since Swift doesn’t currently do anything to address the userInfo field, the userInfo that our error had gets chopped off.</div><div class=""><br class=""></div><div class="">Whoops.</div><div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></body></html>