The issue is that when the method doesn't immediately use the values of the array (e.g. stores it for later, or even worse passes them on to another object), the crash appears much later in the program with a message that NSNull doesn't respond to some selector - and that's often hard to debug.
On the other hand, I agree that it's better to use NSNull than how it currently works since this is a valid Swift 3 code: let arr: [String?] = ["Hello", nil] NSArray(array: arr) that will not crash and will produce a valid NSArray. As Douglas Gregor mentioned earlier: > […] because any Swift type can be placed in an Any, and anything can be > bridged to Objective-C. Nearly all of the concerns in this thread are about > this aspect of the already-accepted-and-implemented SE-0116: that an optional > can get passed through to an Objective-C ‘id’ without being explicitly > unwrapped. That behavior exists, and the type of the object seen in > Objective-C is an opaque Swift wrapper type. Playground will show the NSArray as two NSObjects (which are in fact _SwiftValue), which means that the ObjC will crash as well, but with even a more obscure message: Attempted to dereference an invalid ObjC Object or send it an unrecognized selector. So, choosing between two evils, I personally vote +1 for adding the NSNull bridging... > On Sep 3, 2016, at 10:01 AM, Pyry Jahkola via swift-evolution > <swift-evolution@swift.org> wrote: > > I don't feel confident enough about the Swift–Obj-C interop to cast my own > vote but I'd like to question this sentiment: > >> On 03 Sep 2016, at 03:17, Charles Srstka via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> 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. > > How is this different with NSNull though? If the callee expects an array of > NSNumbers for example and uses them (for anything more specific than > NSObject), the first NSNull instance will throw an NSInvalidArgumentException > basically crashing the program as well: > > $ cat example.m > @import Foundation; > > int main() { > id number = NSNull.null; > NSLog(@"%ld", [number integerValue]); > } > > $ clang -fmodules example.m -o example && ./example > 2016-09-03 10:47:21.822 example[31488:151700] -[NSNull integerValue]: > unrecognized selector sent to instance 0x7fff78561780 > (snip...) > libc++abi.dylib: terminating with uncaught exception of type NSException > Abort trap: 6 > > OTOH, if the only thing the Obj-C code planned to do was immediately convert > the NSArray into JSON, then a previously crashing example would now start > producing a JSON array with mixed numbers and nulls. But is that kind of code > likely in practice? > > It would be different though if NSNull just swallowed any messages it > receives like `nil` does. There are 3rd party examples > <https://github.com/jspahrsummers/libextobjc/blob/master/extobjc/EXTNil.h> of > that behaviour, and that would be detrimental to code quality in the case of > Swift interop. > > — Pyry > > _______________________________________________ > 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
