Did you mean “implicitly unwrapped”? Then, by the above logic, the type of
the ‘if’ expression is Bool, so it would crash if ‘bbb’ is nil. Otherwise, it
would test the boolean value of ‘bbb’.
Turns out, after a try in a playground, that this is the right way to do it:
var b : Bool! = nil
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
Le 14 juin 2014 à 21:45, Roland King r...@rols.org a écrit :
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
On Jun 14, 2014, at 3:45 PM, Roland King r...@rols.org wrote:
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
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
On Jun 14, 2014, at 13:09 , Ken Thomases k...@codeweavers.com wrote:
For convenience.
Specifically, IIUC, the point is that NSDate? and NSDate are different,
incompatible types. The convenience comes from not having to “cast” NSDate? to
NSDate by using the “!” operation in expressions.
On
