{"id":34903,"date":"2022-02-03T16:11:16","date_gmt":"2022-02-03T21:11:16","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=34903"},"modified":"2022-02-03T16:11:16","modified_gmt":"2022-02-03T21:11:16","slug":"optionals-in-swift-objective-c-interoperability-2","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2022\/02\/03\/optionals-in-swift-objective-c-interoperability-2\/","title":{"rendered":"Optionals in Swift Objective-C Interoperability"},"content":{"rendered":"

Fabián Cañas<\/a> (via Zev Eisenberg<\/a>):<\/p>\n

\n

The scroll view property, which should be nonnull<\/code>, or in Swift, not optional, is never given a value on initialization. So what happens when we use if from Swift?<\/p>\n

[…]<\/p>\n

Any Objective-C things we want to do with these objects succeeds, which is nearly everything since they’re Objective-C objects. We’ve entered the territory of undefined behavior. It’s a sort of “Objective-C mode”.<\/p>\n

There are things we can do to detect this non-optional nil condition. […] The problem is that since Swift doesn’t think this value can be nil, it’s not trivial to check.<\/p>\n

[…]<\/p>\n

If you make a Swift extension to the Objective-C class and call them on one of these nil<\/code> things that aren’t supposed to exist, those methods still get called.<\/p><\/blockquote>\n

I guess this is because methods defined in Swift are by default not dynamic.<\/p>\n

\n

Nonnull array properties in Objective-C get bridged to Swift in a very strange way. […] This situation doesn’t look self-consistent. Under some conditions, Swift will create an Array if it doesn’t find one where it’s expected.<\/p>\n<\/blockquote>\n

Previously:<\/p>\n