title: How to downcast / cast a struct's generic type in Swift
body: <p>I've refactored my work with UICollectionViewCells into the following </p>
  
  <pre><code>struct CollectionViewCellModel&lt;T: UICollectionViewCell&gt; {
      let reuseIdentifier: NSString
      let allowsSelection: Bool
  
      // Optional callbacks
      var onCreate: ((T) -&gt; Void)?            = nil
      var onSelection: ((T) -&gt; Void)?         = nil
      var onWillBeDisplayed: ((T) -&gt; Void)?   = nil
      var onDelete: ((T) -&gt; Void)?            = nil
  
      // Create cell
      func toCell(collectionView: UICollectionView, indexPath: NSIndexPath) -&gt; T {
          let cell = collectionView.dequeueReusableCellWithReuseIdentifier(reuseIdentifier, forIndexPath: indexPath) as T
          if let onCreate = onCreate { onCreate(cell) }
          return cell
      }
  }
  </code></pre>
  
  <p>This has made it easier for me to create a list of specific cells (For things like forms) and then work with them.</p>
  
  <p>However, I keep getting tripped up in how to store these objects. I can't downcast them to <code>CollectionViewCellModel&lt;UICollectionViewCell&gt;</code> and therefore can't store a list of <code>[CollectionViewCellModel&lt;UICollectionViewCell&gt;</code> </p>
  
  <p>I thought Swift supported down-casting, but apparently not for generic types? </p>
  
  <pre><code>let cell = CollectionViewCellModel&lt;A&gt;(...)
  let genericCell = cell as CollectionViewCellModel&lt;UICollectionViewCell&gt;
  // ERROR: UICollectionViewCell is not identical to A
  let genericMaybeCell = cell as? CollectionViewCellModel&lt;UICollectionViewCell&gt;
  // ERROR: UICollectionViewCell is not identical to A
  </code></pre>
  
  <p>Do I have to store these as an array of <code>Any</code> and then cast them every time or am I just misunderstanding something (or both)?</p>
  
  <hr>
  
  <p>Update: I've done some work in the playground to clearly illustrate what I mean:</p>
  
  <pre><code>protocol IA {
      func name() -&gt; String
  }
  
  class A:IA { func name() -&gt; String { return "A (Base)" } }
  class B: A { override func name() -&gt; String { return "B (Child of A)" } }
  class C: B { override func name() -&gt; String { return "C (Child of B)" } }
  
  struct SA&lt;T: A&gt; {
  }
  
  let struct0: Any = SA&lt;B&gt;()
  // OK: yes, the struct of B is an Any! 
  // but since B inherits from A, isn't it safe to 
  // say that SA&lt;B&gt; is also of type SA&lt;A&gt;?
  let struct1: SA&lt;A&gt; = SA&lt;B&gt;() as SA&lt;A&gt;
  // NO
  // ERROR: 'B' is not identical to 'A'
  let struct1Optional: SA&lt;A&gt; = SA&lt;B&gt;() as? SA&lt;A&gt;
  // not even optionally? NO
  // ERROR: 'B' is not identical to 'A'
  </code></pre>
  
  <p>I guess it's not possible. Maybe in Swift 1.3. See thread in comments.</p>
  
  <p>Update (2/17/15)</p>
  
  <hr>
  
  <p>For those of you interested in why I'm even doing this in the first place, you have to understand how I'm working with my CollectionViewControllers (CVCs). I've abstracted a base CVC to perform the common methods every screen needs. This CVC has a protocol that expects a <code>Factory</code> that creates CVC models. These models know how to transform themselves, respond to actions, and very much act like a controller. They're fat &amp; active. My views on the other hand are all dumb. All they know how to do is move stuff around on the screen or go into different display states. When configuring a cell from a CVC, you end up doing these big switch statements that really don't tell you much from a readability perspective expect "route this". It gets worse you start to configure your view in there. It's not horrible, but generally speaking -- to me -- a view controller controls the <em>view</em> it's responsible for. While this VC might be the parent VC of the cell, this does not give it proper access to manipulate it heavily. This now makes your VC do things like <code>cell.changeDisplayToActiveState()</code>; in short, it now bears the burden of controlling its children cells. This is what contributes to all the "fat" VCs out there. I first chose to deviate from this path by adopting the <code>VIPER</code> pattern, but I found it overkill -- especially for a new project. I scrapped it and began to work with a base CVC. This is currently how my project works:</p>
  
  <ul>
  <li>A base CVC expects a factory &amp; factory expects a CVC (thus facilitating two way binding for the cells)</li>
  <li>This factory produces cell &amp; header models <strong>for THE CVC</strong>. </li>
  <li>These models have callback &amp; data &amp; configuration functionality embedded within them. </li>
  <li>They can call PUBLIC functions of the view controller from these callbacks (thus strictly separating responsibilities) such as <code>vc.changeDisplayState(...)</code> or <code>changeToVc(...)</code> </li>
  </ul>