title: Swift: confused about nullable/optional types
body: <p>I'm new to Swift and iOS coding and have been working on writing my first app. While my programming background is pretty significant, I come from a Python and C# background where pretty much anything can be <code>None</code> or <code>null</code> and it's up to the user to check at runtime for a null. I'm finding this whole concept of "nullable vs. non-nullable types" or "optional types" in Swift to be confusing.</p>
  
  <p>I understand that the core concept is that a variable declared as a type like <code>myObject</code> cannot be set to <code>nil</code>. However, if I define it as type <code>myObject?</code> then the value can be set to <code>nil</code>.</p>
  
  <p>The problem is that, when I look at my code designs, it feels like <strong>everything</strong> will have to be "nullable" in my code. It feels like this either means I'm not thinking correctly with how my code should run, or that I'm missing some crucial piece of understanding.</p>
  
  <p>Let's take the simplest example of something I am confused about. Suppose I have two classes - one that stores and manages some sort of data, and another that provides access to that data. (An example of this might be something like a database connection, or a file handle, or something similar.) Let's call the class containing data <code>myData</code> and the class that works with that data <code>myObject</code>.</p>
  
  <p><code>myObject</code> will need a class-level reference to <code>myData</code> because many of its methods depend on a local reference to the class. So, the first thing the constructor does is to generate a data connection and then store it in the local variable <code>dataConnection</code>. The variable needs to be defined at the class level so other methods can access it, but it will be assigned to in the constructor. Failure to obtain the connection will result in some sort of exception that will interfere with the very creation of the class.</p>
  
  <p>I know that Swift has two ways to define a variable: <code>var</code> and <code>let</code>, with <code>let</code> being analogous to some languages' <code>const</code> directive. Since the data connection will persist throughout the entire life of the class, <code>let</code> seems an obvious choice. However, I do not know how to define a class-level variable via <code>let</code> which will be assigned at runtime. Therefore, I use something like </p>
  
  <pre><code>var dataConnection: myData?
  </code></pre>
  
  <p>in the class outside any functions. </p>
  
  <p>But now I have to deal with the nullable data type, and do explicit unwrapping <strong>every time</strong> I use it anywhere. It is frustrating to say the least and quite confusing.</p>
  
  <pre><code>func dealWithData() { 
      self.dataConnection.someFunctionToGetData()  &lt;- results in an unwrapping error.
      self.dataConnection!.someFunctionToGetData() &lt;- works.
      let someOtherObjectUsingData: otherObject = self.getOtherObject() &lt;- may result in error unless type includes ?
      someOtherObjectUsingData.someMethod(self.dataConnection) &lt;- unwrap error if type included ?
      var myData = self.dataConnection! 
      someOtherObjectUsingData.someMethod(myData) &lt;- works
  }
  
  func somethingNeedingDataObject(dataObject: myData?) {
      // now have to explicitly unwrap
      let myDataUnwrapped = myData!
      ...
  }
  </code></pre>
  
  <p>This just seems to be an extremely verbose way to deal with the issue. If an object is <code>nil</code>, won't the explicit unwrap in and of itself cause a runtime error (which could be caught and handled)? This tends to be a nightmare when stringing things together. I've had to do something like:</p>
  
  <pre><code>self.dataConnection!.somethingReturningAnObject!.thatObjectsVariable!.someMethod()
  
  var myData? = self.dataConnection
  var anotherObject? = myData!.somethingReturningAnObject
  ...
  </code></pre>
  
  <p>The way I'm used to doing this is that you simply define a variable, and if it is set to null and you try to do something with it, an exception (that you can catch and handle) is thrown. Is this simply not the way things work anymore in Swift? This has confused me sufficiently that just about every time I try to compile an app, I get tons of errors about this (and I just let Xcode fix them). But this can't be the best way to deal with it.</p>
  
  <p>Do I have to consistently deal with wrapping and unwrapping variables - even those which are expected to never be null in the first place but simply can't be assigned at compile time? </p>