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