<div dir="ltr">+1 to this. `as` is a hairy beast.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 2, 2016 at 8:45 PM, Charles Srstka via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><blockquote type="cite">On May 2, 2016, at 4:48 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></blockquote><div><blockquote type="cite"><br><div><div style="word-wrap:break-word"><div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div>On May 2, 2016, at 3:45 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><div><div style="word-wrap:break-word"><div><blockquote type="cite"><div style="word-wrap:break-word"><p style="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 style="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 style="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>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 style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div><div>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><br></div><div>-- E</div></div></div></blockquote></div><br></div></div><div>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><br></div><div>Have a look at this code, and take a guess at what the results should be:</div><div><br></div><div><div>import Foundation</div><div><br></div><div>extension ErrorType {</div><div><span style="white-space:pre-wrap"> </span>public func toNSError() -> NSError {</div><div><span style="white-space:pre-wrap"> </span>return self as NSError</div><div><span style="white-space:pre-wrap"> </span>}</div><div>}</div><div><br></div><div>let error = NSError(domain: "Foo", code: -1, userInfo: [NSLocalizedFailureReasonErrorKey : "Something went wrong"])</div><div><br></div><div>let ns = error.toNSError()</div><div><br></div><div>print("Type of error was \(error.dynamicType), type of ns is \(ns.dynamicType)")</div><div><br></div><div>print("error's user info: \(error.userInfo)")</div><div>print("ns user info: \(ns.userInfo)”)</div></div><div><br></div><div>--</div><div><br></div><div>The results are a bit surprising:</div><div><br></div><div><div>Type of error was NSError, type of ns is _SwiftNativeNSError</div><div>error's user info: [NSLocalizedFailureReason: Something went wrong]</div><div>ns user info: [:]</div></div><div><br></div><div>What happened was:</div><div><br></div><div>1. The toNSError() method showed up for our NSError, since NSError is presented to Swift as conforming to ErrorType. </div><div><br></div><div>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><br></div><div>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><br></div><div>Whoops.</div><div><br></div><div>Charles</div><div><br></div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>