[Proposal:
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]> 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
>
> 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]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
