title: How to represent Core Data optional Scalars (Bool/Int/Double/Float) in Swift?
body: <p>(first noticed on: Xcode 8.2.1, iOS 10, Swift 3)
  (still present as of: Xcode 9 beta 3, iOS11, Swift 4)</p>
  
  <p>We all know that the <code>Core Data</code> concept of <code>optionals</code> precedes and is not strictly tied to the <code>Swift</code> concept of <code>optionals</code>.</p>
  
  <p>And we have accepted that even if a <code>Core Data</code> attribute is marked as <code>Non-optional</code>, the auto-generated <code>NSManagedObject</code> subclass has an <code>optional</code> type:</p>
  
  <p><a href="https://i.stack.imgur.com/9fSAh.png" rel="noreferrer"><img src="https://i.stack.imgur.com/9fSAh.png" alt=""></a>
  (some people manually remove the <code>?</code> with no adverse effects, some don't, but that's beside the point)</p>
  
  <p>(From here on the example and screenshots are for <code>Bool</code> properties, but same goes for <code>Int16/32/64</code>, <code>Double</code>, <code>Float</code>)</p>
  
  <p>Now I noticed the reverse - when a <code>Core Data</code> attribute of type <code>Bool</code> is marked as <code>Optional</code> (and <code>Use Scalar Type</code> is chosen, which Xcode does by default), the auto-generated class has a variable of a <code>non-optional</code> type.</p>
  
  <p><a href="https://i.stack.imgur.com/Jg2cd.png" rel="noreferrer"><img src="https://i.stack.imgur.com/Jg2cd.png" alt=""></a></p>
  
  <p>Does this make sense? Is it a bug? Is the behaviour documented anywhere?</p>
  
  <p>And most importantly - how do I actually represent an optional <code>Bool</code>?</p>
  
  <p>I can think of some work-arounds, but they don't seem ideal (e.g. not using scalars, but going back to <code>NSNumber</code> representation of the <code>Bool</code>. Or (even worse) having a separate <code>Bool</code> called something like <code>isVerified_isSet</code>)</p>
  
  <hr>
  
  <p>Note: I did a couple more tests and if the <code>Default Value</code> is set to <code>None</code> or to <code>NO</code>, then the variable gets saved as <code>false</code> (even if I never actually assign it in my code). If the <code>Default Value</code> is set to <code>YES</code>, then the variable gets saved as <code>true</code>. Still, this means that (apparently) there is no way to logically represent this variable as not having been set yet.</p>