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.
Jordan > On Apr 30, 2016, at 12:44, Jean-Daniel Dupas <[email protected]> wrote: > > 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 ? > > > let userInfo: [NSString: AnyObject] = [ > kSomeStandardKey: self.name, // a String > kAnotherKey: self.childNames // an Array of Strings > ] > NSNotificationCenter.default().postNotificationName(MyNotification, self, > userInfo) > > >> Le 30 avr. 2016 à 02:32, Jordan Rose via swift-evolution >> <[email protected] <mailto:[email protected]>> a écrit : >> >> [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? >> >> 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 >>> <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] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
