{"id":314,"date":"2014-06-29T08:58:41","date_gmt":"2014-06-29T14:58:41","guid":{"rendered":"http:\/\/dev.iachieved.it\/iachievedit\/?p=314"},"modified":"2015-12-30T12:34:59","modified_gmt":"2015-12-30T18:34:59","slug":"a-morning-with-swift-optionals","status":"publish","type":"post","link":"https:\/\/dev.iachieved.it\/iachievedit\/a-morning-with-swift-optionals\/","title":{"rendered":"A Morning with Swift Optionals"},"content":{"rendered":"

Swift optionals come off as a bit weird. There, we said it. Those familiar with Scala, F#, Haskell, or Rust might disagree, but then again, how many people do you know that actually program in Haskell? And we can guarantee you that 90% of Objective-C programmers out there are not working with these functional programming languages. At any rate, optional types<\/a> have been introduced to the programming language that will be the flagship for iOS and OS X development in the future. It’s time to get on the bandwagon.<\/p>\n

At the core optionals are conceptually easy to understand. An optional type is simply a way of saying that this object here might<\/i> be of type X<\/b>. Or it might not. In Swift there are two concrete possibilities (or options<\/i>): it is either the type it was declared as, or nil<\/code>. It cannot be some other type. An illustration:<\/p>\n

\r\nvar currentTemperature:Double?\r\n<\/pre>\n
In this example the object to which the currentTemperature<\/code> variable refers can either be a Double<\/code>, or nil<\/code>.  So, let’s say in our code we use some API to go retrieve the current temperature, and that API has declared a function like this:<\/p>\n
\r\nfunc currentTemperature() -> Double?\r\n<\/pre>\n
The Double?<\/code> again signifies that the return value will either be a Double<\/code> or nil<\/code>.  How would you interact with this function?  What if we just did:<\/p>\n
\r\nvar temperature:Double\r\ntemperature = currentTemperature()\r\n<\/pre>\n
Swift complains and says “Value of optional type ‘Double?’ not unwrapped; did you mean to use ‘!’ or ‘?’?”  Now don’t tell us that the first impression of someone with a Ruby, Python, or even Objective-C background wouldn’t be to look at that and say, huh, what?  Unwrapped?  Like a Chipotle burrito or Snickers bar?  I don’t get it.<\/p>\n
What Swift is saying is “Hey pal<\/i>, look here.  You presented me with a Double<\/code> variable to capture the return value from a function that may return a Double<\/code> or nothing.  If you really mean it you are going to have to decide whether you want to insist that you will receive a Double<\/code> or you’ll have to change your variable type.”  <\/p>\n
The first option, using !<\/code>, forces what is known as unwrapping<\/i>, which we liken to casting (but it’s not really).  It’s sort of like a declaration that “we know this a Double<\/code> so use it as one.”  If it isn’t actually a Double<\/code> and is truly nil<\/code> you’re going to get a crash.  Which is actually good if you think about it… we want errors in logic to crash and burn so we can catch them before we ship our software.   <\/p>\n
Typically however you would not code by throwing exclamation marks around (well, sometimes we do if we’re chasing down an elusive bug).  In practice we’ve found ourself only using !<\/code> when the application logic is (supposedly) guaranteeing a certain condition, but we prefer the defensive programming<\/i> approach which substitutes “trust but verify”<\/a> with “verify”.  Swift provides a syntactical construct called optional binding<\/i> that is done like this:<\/p>\n
\r\nif let temperature = currentTemperature() {\r\n  println(\"The temperature is \\(temperature)\")\r\n} else {\r\n  println(\"Unable to obtain current temperature\")\r\n}\r\n<\/pre>\n
This is logically equivalent to the following Objective-C code:<\/p>\n
\r\nNSNumber* temperature = [Weather currentTemperature];\r\nif (temperature != nil) {\r\n} else {\r\n}\r\n<\/pre>\n
Just keep in mind that a Swift nil<\/code> is not the same as Objective-C’s nil<\/code>.  Quoting Apple, “Swift’s nil is not the same as nil in Objective-C. In Objective-C, nil is a pointer to a non-existent object. In Swift, nil is not a pointer\u2014it is the absence of a value of a certain type. Optionals of any type can be set to nil, not just object types.”<\/p>\n
In working with Swift we’ve found that deferred initialization of object members require you declare them as optional types.  For example:<\/p>\n
\r\nclass Circle {\r\n  \r\n  var radius:Double\r\n  \r\n  init() {\r\n  }\r\n  \r\n}\r\n<\/pre>\n
The Swift compiler responds, error: property 'self.radius' not initialized<\/code>.  Now it might not make much sense to have a Circle<\/code> with no radius, but let’s use our weather example.  We could<\/i> reasonably have nothing<\/i> for our temperature.  Zero as a value won’t suffice to signify such a situation (alliteration is fun), nor will negative values.  We really do want to be able to declare a variable that could have no temperature.  Here we have created a Weather<\/code> class that has a temperature of type Double?<\/code>.  This allows those obtaining the temperature to understand that it might<\/i> be undefined.<\/p>\n
\r\nclass Weather {\r\n  \r\n  var temperature:Double?\r\n  \r\n  init() {\r\n  }\r\n  \r\n  func currentTemperature() -> Double? {\r\n    return temperature\r\n  }\r\n  \r\n}\r\n\r\nvar weather = Weather()\r\n\r\nif let temperature = weather.currentTemperature() {\r\n  println(\"The current temperature is \\(temperature)\")\r\n} else {\r\n  println(\"Could not obtain temperature\")\r\n}\r\n<\/pre>\n
Before we wrap up this little exposition on Swift optionals, let us say this:  you will be well served by spending time with Swift optionals and what unwrapping is and what the !<\/code> and ?<\/code> symbols mean.  Our time with iOS 8 and Swift has shown that usage of optionals is significant and that failure to understand them will be a hindrance.  And we haven’t even done a deep-dive on optional chaining<\/a> (next post perhaps), but it too will be a significant part of iOS and OS X programming.  <\/p>\n","protected":false},"excerpt":{"rendered":"
Swift optionals come off as a bit weird. There, we said it. Those familiar with Scala, F#, Haskell, or Rust might disagree, but then again, how many people do you know that actually program in Haskell? And we can guarantee you that 90% of Objective-C programmers out there are not working with these functional programming […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-314","post","type-post","status-publish","format-standard","hentry","category-swift"],"_links":{"self":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts\/314"}],"collection":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/comments?post=314"}],"version-history":[{"count":23,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts\/314\/revisions"}],"predecessor-version":[{"id":2371,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/posts\/314\/revisions\/2371"}],"wp:attachment":[{"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/media?parent=314"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/categories?post=314"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dev.iachieved.it\/iachievedit\/wp-json\/wp\/v2\/tags?post=314"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}