<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=""><div class="">It’s not the keys that are the problem; it’s the values. String and Array are not AnyObjects. Today they get an implicit conversion because they are known-bridgeable.</div><div class=""><br class=""></div><div class="">Jordan</div><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 30, 2016, at 12:44, Jean-Daniel Dupas &lt;<a href="mailto:mailing@xenonium.com" class="">mailing@xenonium.com</a>&gt; 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="">Is this is a plist like construct, couldn’t it simply be declared as [NSString: AnyObject] ? As we are talking about removing implicit cast, forcing the user to use NSString explicitly for API that need a NSDictionary is probably not a problem ?<div class=""><br class=""><div class=""><br class=""></div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class="">let userInfo: [NSString: AnyObject] = [</div><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>kSomeStandardKey: self.name, // a String</div><div class=""><span class="Apple-tab-span" style="white-space: pre;">        </span>kAnotherKey: self.childNames // an Array of Strings</div><div class="">]</div></blockquote><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class="">NSNotificationCenter.default().postNotificationName(MyNotification, self, userInfo)</div></blockquote></div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 30 avr. 2016 à 02:32, Jordan Rose via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; a écrit :</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="">[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md]" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md]</a></div><div class=""><br class=""></div><div class="">I’m a little concerned about the affect this has on “plist literals”. Specifically, I can no longer construct a dictionary like this:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">let userInfo: [String: AnyObject] = [</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>kSomeStandardKey: self.name, // a String</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>kAnotherKey: self.childNames // an Array of Strings</div><div class="">]</div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">NSNotificationCenter.default().postNotificationName(MyNotification, self, userInfo)</div></blockquote><div class=""><br class=""></div><div class="">The fix isn’t <i class="">that</i>&nbsp;hard—just add “as NSString” or “as NSArray”—but it is a bit of extra noise that we currently don’t have. If the type checker can still offer that fix-it, then I’m not sure we’d actually get any compiler simplification out of it…although I suppose it might make the happy path faster.</div><div class=""><br class=""></div><div class="">The CFString issue Jacob brought up is also a little unfortunate, although that’s about the direction that <i class="">already</i>&nbsp;requires an explicit coercion. But this probably affects calling CF functions that take CFStrings, since IIRC we don’t treat that the same as NSString at the moment, and CFArray will never have generics.</div><div class=""><br class=""></div><div class="">Of course, I’ve been out of the Cocoa community for a while now, so I don’t really have a sense of how often this comes up in practice, and how much the explicit coercion costs (psychologically). So I’m with Brent: do we have information on the changes needed for real-world projects?</div><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 Apr 26, 2016, at 13:54, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hello Swift community,<br class=""><br class="">The review of "SE-0072: Fully eliminate implicit bridging conversions from Swift" begins now and runs through May 2. The proposal is available here:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre">        </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md</a><br class=""><br class="">Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre">        </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""><br class="">or, if you would like to keep your feedback private, directly to the review manager.<br class=""><br class=""><br class="">What goes into a review?<br class=""><br class="">The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>* What is your evaluation of the proposal?<br 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=""><span class="Apple-tab-span" style="white-space:pre">        </span>* Does this proposal fit well with the feel and direction of Swift?<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br 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=""><br class="">More information about the Swift evolution process is available at<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre">        </span><a href="https://github.com/apple/swift-evolution/blob/master/process.md" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a><br class=""><br class="">Thank you,<br class=""><br class="">-Chris Lattner<br class="">Review Manager<br class=""><br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></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=""><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></div></div></div></blockquote></div><br class=""></body></html>