3 ms·
> A small example are force-unwrapped optionals that you get out of a lot of the library calls (because nil ptrs. are OK in ObjC and Cocoa), which will blow up
by ninkendo 12y ago
> A small example are force-unwrapped optionals that you get out of a lot of the library calls (because nil ptrs. are OK in ObjC and Cocoa), which will blow up when you use them, without the compiler warning you! (So much for safety).
Care to elaborate? I get that an ObjC method potentionally returning nil would result in an optional on the swift side, but I don't really get how the compiler doesn't warn you the same way it would with anything else with Optional semantics. (ie. it's nullable.)
- mpweiher 12y agoWell, they're not mapping them to optionals, but to "forced unwrapped". This is how the superview property of NSView is declared: var superview: NSView! { get } In a workspace: var view = NSView( frame: NSRect(x: 10, y: 10, width: 300, height: 100)) -> NSView view.superview -> nil So now I have a nil in Swift that is not wrapped in an optional. No compiler warnings, boom! And of course, no way to catch exceptions, so BOOM!