> On Apr 29, 2016, at 5:32 PM, Jordan Rose <[email protected]> wrote: > > [Proposal: > https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md] > > <https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md]> > > I’m a little concerned about the affect this has on “plist literals”. > Specifically, I can no longer construct a dictionary like this: > > let userInfo: [String: AnyObject] = [ > kSomeStandardKey: self.name, // a String > kAnotherKey: self.childNames // an Array of Strings > ] > NSNotificationCenter.default().postNotificationName(MyNotification, self, > userInfo) > > The fix isn’t that 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. > > The CFString issue Jacob brought up is also a little unfortunate, although > that’s about the direction that already 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. > > 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?
As part of the initial RFC, I pushed the inhibit-implicit-conversions branch, which folks should feel free to experiment with on their own codebases. In the meantime, I’m gathering some data on the outward-facing impact of these changes. Thanks, - Joe > > Jordan > > >> On Apr 26, 2016, at 13:54, Chris Lattner via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> Hello Swift community, >> >> The review of "SE-0072: Fully eliminate implicit bridging conversions from >> Swift" begins now and runs through May 2. The proposal is available here: >> >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md >> >> <https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md> >> >> Reviews are an important part of the Swift evolution process. All reviews >> should be sent to the swift-evolution mailing list at: >> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> or, if you would like to keep your feedback private, directly to the review >> manager. >> >> >> What goes into a review? >> >> 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: >> >> * What is your evaluation of the proposal? >> * Is the problem being addressed significant enough to warrant a change >> to Swift? >> * Does this proposal fit well with the feel and direction of Swift? >> * If you have you used other languages or libraries with a similar >> feature, how do you feel that this proposal compares to those? >> * How much effort did you put into your review? A glance, a quick >> reading, or an in-depth study? >> >> More information about the Swift evolution process is available at >> >> https://github.com/apple/swift-evolution/blob/master/process.md >> >> Thank you, >> >> -Chris Lattner >> Review Manager >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
