What's the benefit of force unwrap for casting NSString to String?

Question

Created May ’17

Replies 2

Boosts 0

Views 1.1k

Participants 2

I got an interesting question during my daily coding. When I define a NSString property in Objective-C and then use it in Swift. It automatically cast it to String!, which is non-nullable.

From my perspective, by default NSString property could be nil in Objective-C, but sometimes we could also declare it as nonnull. Since Swift compiler does not know whether a particular NSSring * is optional or not, the type is brought into Swift as an implicitly unwrapped optional, String!.

The question is what’s the benefits in making so? I encounter the case in our codebase when it crashes my app due to the force unwrap issue. However, it does not give me any warnings or errors in compile time, which means it does not take the advantage of type safety; hence why Swift makes such bridge mechanism like this?

Boost

Answer 1

soapyigu OP

May ’17

Oh, I guess this is pretty similar as the question here: https://forums.developer.apple.com/message/10042#10042

0

Answer 2

QuinceyMorris OP

May ’17

There's a fundamental stylistic difference between Swift and Obj-C regarding the handling of nil references. In Obj-C, it's usual to "carry" nil values through code until it's convenient to check for nil. (Remember that in Obj-C it does nothing to send a message of any kind to a nil receiver, and if there's a return value it comes back as an all-zero-bits representation of whatever type it is, in almost all cases.) Swift turns this around, barring the use of nil except where explicitly allowed (as an optional of some kind). That's why the bridging might seem strange. As well as moving values from one language environment to the other, it's also moving between stylistic universes.

>> It automatically cast it to String!, which is non-nullable.

The IUO isn't non-nullable. It's possible to set it to nil in code, or test it against nil. That makes it almost the exact equivalent of NSString* (with no nullability specifier) because it can be nil, but doesn't need to be explicitly unwrapped. The only difference is that it will crash if you try to dereference nil implicitly, which is because of the stylistic difference mentioned above.

0