<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 May 23, 2016, at 5:26 PM, Jordan Rose 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="">I am way late, but I share Brent’s concerns. I don’t think this addresses the very common case of “getting a String out of a heterogeneous dictionary”.</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">let name = plist[“name”] as! String</blockquote><div class=""><br class=""></div>becomes one of these:<div class=""><br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">let name = plist[“name”] as! NSString as String</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">let name = String(plist[“name”] as! NSString)</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">let name = String(forceBridging: plist[“name”]) // not in the proposal</blockquote><div class=""><br class=""></div>none of which I’m particularly happy with. <br class=""></div></div></div></blockquote><div><br class=""></div><div>I am also way, way late, here, but this ties into a philosophical concern I have. The bridging that we have in place was designed to put Swift’s value types front-and-center in the Swift experience, even when interoperating with Objective-C APIs using reference-semantic types. It was a specific goal that one should not have to juggle between Swift.Array and NSArray—NSArray is bridged away in imported APIs, Swift arrays implicitly convert to AnyObject when working an AnyObject-based API, dynamic bridging conversions would pass through NSArray to get to Swift arrays, etc. So while one can certainly reach for NS(Mutable)Array in Swift, one should not *have* to do so in Swift.</div><div><br class=""></div><div>This proposal and SE-0072 are chipping away at that bridging story, making the explicit use of NSArray/NSString/etc. required for interoperability with Objective-C APIs. While it does make the language more explicit and predictable (and dynamic casting more efficient!), it makes the use of these bridged reference-semantic more prevalent, which may lead to more overall confusion about which set of types to use. There might even be a portability argument: the current scheme lets you gloss over Any vs. AnyObject (which is a current difference we see in ObjC Foundation vs. corelibs Foundation).</div><div><br class=""></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=""><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On May 19, 2016, at 02:31, Brent Royal-Gordon 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=""><div class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* What is your evaluation of the proposal?<br class=""></blockquote><br class="">The review is technically over, but I don't believe a decision has been announced yet, so...<br class=""><br class="">I am generally in favor, but I have a serious concern about the readability of certain conversions with this change. To wit, conversions like these:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>myArray as! [NSView]<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>myDictionary as! [String: NSView]<br class=""><br class="">Are about to become something more like these:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>[NSView](forcedLazyBridging: myArray)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>[String: NSView](forcedLazyBridging: myDictionary)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><br class="">Or these:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Array<NSView>(forcedLazyBridging: myArray)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Dictionary<String, NSView>(forcedLazyBridging: myDictionary)<br class=""><br class="">Either option is a significant regression in code readability compared to the status quo.<br class=""><br class="">It's enough to make me wonder if we shouldn't have special-cased conversion methods for NSArray, NSDictionary, and NSSet:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>myArray.of(NSView)<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>// returns [NSView]<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>myDictionary.of(NSView, for: String) <span class="Apple-tab-span" style="white-space:pre"> </span>// returns [String: NSView]<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>mySet.of(NSView)<span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span><span class="Apple-tab-span" style="white-space:pre"> </span>// returns Set<NSView><br class=""><br class="">On the other hand, if you *don't* have to specify an element type, these aren't so bad:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Array(forcedLazyBridging: myArray)<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>Dictionary(forcedLazyBridging: myDictionary)<br class=""><br class="">And it gets even better if you use something a little saner than `forcedLazyBridging` for the label.<br class=""><br class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></blockquote><br class="">Yes. Conversions are a mess, and it'll be nice to clean them up.<br class=""><br class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Does this proposal fit well with the feel and direction of Swift?<br class=""></blockquote><br class="">Yes.<br class=""><br class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></blockquote><br class="">Most languages I've used have had much simpler cast systems with nothing particularly close to Swift's bridging casts.<br class=""><br class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""></blockquote><br class="">Quick reading.<br class=""><br class="">-- <br class="">Brent Royal-Gordon<br class="">Architechies<br class=""><br class="">_______________________________________________<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></div></blockquote></div><br class=""></div></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>