Implicitly unwrapped optionals
Implicitly unwrapped optionals
- Subject: Implicitly unwrapped optionals
- From: Roland King <email@hidden>
- Date: Sat, 14 Jun 2014 20:45:35 +0100
I'm a little confused about implicitly unwrapped optionals.
My current understanding is that you can access their value directly, without using the 'if let' syntax or the explicit unwrap (!) operator, but you'll crash if the optional doesn't have a value when you do. You can also treat them like an optional and using 'if' on them tells you if they exist just like an optional does.
I'm watching the Swift Interoperability In Depth talk and that basically says that all object types in ObjC look like implicitly unwrapped optionals in swift. Ie NSDate* date turns up as
var date : NSDate!
First question is why use an implicitly unwrapped optional instead of just an optional? You still have to test them so what do you gain?
One slide says at 5:16 into the talk "Can be explicitly tested for nil". That to me means you can do
If xxx == nil
I assume the slide is being a little sloppy and that really means use the normal "if xxx" syntax for these which returns true if the value exists, as xxx == nil would surely attempt an unwrap and throw if the value didn't exist.
Finally if you have an implicitly optional Bool, bbb, what does
if bbb
do? Does it return whether bbb has a value or does it return the unwrapped value of the Bool used in the if? I assume the former in which case how do you use an implicitly unwrapped optional bool in an if?
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden