* What is your evaluation of the proposal? I support this proposal. I work on a framework, and I was actually able to track down a user-reported crash to the lack of this sort of bridging. An engineer overlooked that an `Optional` value passed into an `Any` parameter, would be forwarded to the Objective-C API as an opaque object. Since we had not tested that particular type, we were unable to detect this issue. Adding this sort of bridging behavior (explicitly in the implementation of our function) is how we were able to fix this issue since the Objective-C API did accept `NSNull`.
Others on the mailing list have brought up concerns that this sort of bridging will defer the detection of API misuse in the case of `NSArray`. I think that, while that is a fair concern, it ignores other cases where this sort of bridging will actually fix crashes that would otherwise occur. Further, I think these concerns forget that fact that `Any` is only used for dynamic APIs. If you'd like a strongly typed `NSArray`, you would use Objective-C lightweight generics. I would actually argue that dynamically bridging `NSNull` to `nil` is most consistent with the current behavior of Swift. For example, the following cast succeeds since `Int?` is [kinda sorta] a subtype of `Int`. ``` Optional<Int>.Some(3) as Any as! Int ``` Thus, in Swift you can treat an `Optional<T>` stored inside an `Any` as if it were simply a `T`. In Objective-C though, this is not the case since there's no equivalent to this sort of dynamic `as!` cast. As such, it would be reasonable to bridge `Optional<T>` to `T | NSNull` such that we can similarly treat `T?` as if it were an `T` in Objective-C. Given that `Any` is used in dynamic APIs that can be passed *any* type, I don't think it is worrisome that this will convert to `NSNull`. If the API is designed to only accept certain types, this should be annotated with generics. * Is the problem being addressed significant enough to warrant a change to Swift? I think so. I definitely don't think this issue is as important as fixing numeric bridging, but this seems like a logical improvement to the current bridging behavior. * Does this proposal fit well with the feel and direction of Swift? Definitely. In my understanding, Objective-C interop is a major feature of Swift. The Swift team has done a fantastic job improving this since the first release of Swift, and this seems like a logical, incremental step in the same direction. * If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? I'm not familiar with other languages with such comprehensive bridging features as Swift. Objective-C is built atop C, and thus has multiple concepts of null (NSNull and NULL), but it has never made sense to bridge between these because Objective-C is a superset of C, not an unrelated language that interops with C (and in this case, these separate types were necessary, something that has been avoided in Swift). * How much effort did you put into your review? A glance, a quick reading, or an in-depth study? I've spent a significant number of hours dealings with issues causes by the lack of bridging, both with `Int8` and friends and here. The lack of bridging of `NSNull` and `nil` is definitely less expected than the lack of numeric bridging, but still problematic for those building Swift wrappers for a dynamic API on top of an Objective-C APIs. > On Sep 2, 2016, at 3:50 PM, Douglas Gregor via swift-evolution > <swift-evolution@swift.org> wrote: > > Hello Swift community, > > The review of SE-0140 "Bridge Optional As Its Payload Or NSNull" begins now > and runs through September 8, 2016. The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.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. When replying, please try to keep the proposal link at the top of > the message: > > Proposal link: > > https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.md> > Reply text > > Other replies > <https://github.com/apple/swift-evolution#what-goes-into-a-review-1>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 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 > <https://github.com/apple/swift-evolution/blob/master/process.md> > Thank you, > > -Doug > > 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
