[Review] SE-0072: Fully eliminate implicit bridging conversions from Swift


(Chris Lattner) #1

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


(Brent Royal-Gordon) #2

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

The problem with removing things that are implicit is that it's really hard to know when you're depending on them. :^) Is there a feature flag or branch we can turn on to disable them, or some way we can discover where code depends on implicit conversions? Without that, it's really hard to assess the effects of this proposal.

···

--
Brent Royal-Gordon
Architechies


(Jordan Rose) #3

[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 <swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Chris Lattner) #4

Fair point. I believe that Joe has this implemented already somewhere. Joe, is it possible to make your branch public?

-Chris

···

On Apr 26, 2016, at 2:55 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

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

The problem with removing things that are implicit is that it's really hard to know when you're depending on them. :^) Is there a feature flag or branch we can turn on to disable them, or some way we can discover where code depends on implicit conversions? Without that, it's really hard to assess the effects of this proposal.


(Rainer Brockerhoff) #5

[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.

Somewhat naïve question (not currently able to test this) but shouldn't
  `let userInfo: [String: NSObject] = [`...
force NSthingies for all the subsequent lines?

If not, might that be done?

···

On 4/29/16 21:32, Jordan Rose via swift-evolution wrote:

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 <swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Rainer Brockerhoff <rainer@brockerhoff.net>
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/


(Jean-Daniel) #6

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 <swift-evolution@swift.org> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Joe Pamer) #7

[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

···

On Apr 29, 2016, at 5:32 PM, Jordan Rose <jordan_rose@apple.com> wrote:

Jordan

On Apr 26, 2016, at 13:54, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jordan Rose) #8

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 <mailing@xenonium.com> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Joe Pamer) #9

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.

Hey Jordan,

I share your concern, though I’ve spent my day combing through whatever large codebases I could get my hands on, and I’ve encountered very few “plist literals” where removing implicit bridging conversions would be a problem.

Specifically, quickly analyzing 710 swift code bases (a sampling of GitHub projects, plus others I have access to), I encountered 1785 Dictionary values with an AnyObject key. Of those, only 15 appear to make use of implicit bridging conversions when initializing or assigning to the value.

Since the impact appears to be relatively limited, I think the consistency we’ll gain from this change will make it worthwhile.

Thanks,
- Joe

···

On May 2, 2016, at 9:09 AM, Jordan Rose <jordan_rose@apple.com> wrote:

Jordan

On Apr 30, 2016, at 12:44, Jean-Daniel Dupas <mailing@xenonium.com <mailto:mailing@xenonium.com>> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Jordan Rose) #10

Good to know. If it’s relatively rare (both in how much it comes up and how much that code is written) then the few extra explicit coercions won’t be an undue burden. Thanks for looking into this, Joe!

Jordan

···

On May 5, 2016, at 16:32, Joe Pamer <jpamer@apple.com> wrote:

On May 2, 2016, at 9:09 AM, Jordan Rose <jordan_rose@apple.com <mailto:jordan_rose@apple.com>> wrote:

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.

Hey Jordan,

I share your concern, though I’ve spent my day combing through whatever large codebases I could get my hands on, and I’ve encountered very few “plist literals” where removing implicit bridging conversions would be a problem.

Specifically, quickly analyzing 710 swift code bases (a sampling of GitHub projects, plus others I have access to), I encountered 1785 Dictionary values with an AnyObject key. Of those, only 15 appear to make use of implicit bridging conversions when initializing or assigning to the value.

Since the impact appears to be relatively limited, I think the consistency we’ll gain from this change will make it worthwhile.