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

[Pyry Jahkola]

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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160903/d81af58e/attachment.html>