On Jun 14, 2014, at 2:45 PM, Roland King wrote: > 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?
For convenience. > You still have to test them so what do you gain? You don't have to test them if you're sure they aren't nil. The automatic generation of Swift interfaces from Objective-C interfaces don't know about the full semantics of the Objective-C methods. So, they must assume that any method which returns an object pointer could return nil. We know that some methods never will. (One example, although it's not great because you won't use NSArray much in Swift, is -[NSArray objectAtIndex:].) For those, you can just go ahead and use the implicitly unwrapped optional without testing it. > 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? Not sure. Should be easy enough to test in a playground. > I assume the former in which case how do you use an implicitly unwrapped > optional bool in an if? Well, you can do 'if let b = bbb'. You might also be able to do 'if bbb && bbb!'. Regards, Ken _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
