> On Sep 3, 2016, at 3:01 AM, Pyry Jahkola <[email protected]> wrote: > >> On 03 Sep 2016, at 03:17, Charles Srstka via swift-evolution >> <[email protected] <mailto:[email protected]>> 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:
The difference is that with the existing behavior, any call to *any* object in the array will throw an exception, whether the original was an NSNull or not. This will alert you right away to the fact that you accidentally sent an optional array to an Objective-C API. With this proposal, if the objects in the array are usually non-nil, you might never realize that you accidentally made the array optional, and you won’t find out until some weird edge case results in a nil getting stuck in there and then *surprise!* your users are reporting random crashes in your app that are really hard to track down! Optional arrays are pretty easy to make by accident. I know that I’ve done it far more than I’ve used anything that required an NSNull. The thing is, if you’ve made one, you usually find out about it pretty quickly because you get compiler errors when passing it to other Swift APIs, and, in the worst case, instant and obvious runtime errors when passing it to Objective-C APIs. With the proposal, accidental optional arrays will suddenly become silent and deadly in Objective-C. Charles
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
