[swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

[Joe Groff]

> On Sep 2, 2016, at 5:17 PM, Charles Srstka via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Sep 2, 2016, at 5:50 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 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?
> Strong -1 as is.
> 
>> 	• Is the problem being addressed significant enough to warrant a change to Swift?
> Not only do I not believe the problem is significant, but I believe that the proposal *introduces* a new problem which *is* significant, which is the accidental passage of optional arrays to Objective-C. With the existing behavior, such mistakes are immediately obvious as Objective-C receives an opaque object that it cannot use (and probably soon crashes), so they are unlikely to make it past QA testing. For many other cases, particularly when nil is encountered in an array only rarely, this is likely to cause strange and hard-to-debug problems at runtime when NSNull pops up where code wasn’t expecting it (which I would expect to be most Objective-C code), and it might not be detected until after the product ships. In this way, this proposal creates a problem very similar to the problem that Swift was trying to solve with optionals in the first place.

This is a fundamental problem with `Any` in Swift and `id` in Objective-C. There's no way to statically prevent misuse of such APIs. We can, and IMO should, provide warnings when Optionals are used in unconstrained contexts without either being unwrapped or explicitly annotated somehow. That doesn't conflict with this proposal, though.

-Joe

> Gwynne brings up the interesting idea of being able to declare Objective-C array parameters as NSArray<id _Nullable>. If this were allowed, and the proposed bridging behavior were *only* invoked for an array so declared, I might soften on this proposal, but as is, I feel that it would be a very large mistake.
> 
>> 	• Does this proposal fit well with the feel and direction of Swift?
> 
> A major feature of Swift was the concept of optionals, intended to prevent bugs caused by nil pointers showing up where they were not expected. This proposal flies directly in the face of that, and threatens to make it much easier to create bugs caused by NSNull objects showing up where they are not expected. In this way, I feel that it is an almost 180° contradiction of 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?
> 
> The only Objective-C bridges I have used in other languages have been in AppleScript and JXA, neither of which I would expect Swift to use as a model.
> 
>> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> Read the original discussion, read the proposal, read the comments so far.
> 
> Charles
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution