Sadface

ItemGenerics.swift

//: Playground - noun: a place where people can play

import UIKit

protocol Item {
  
  var title: String? { get set }
  var value: String? { get set }
  
}

protocol ItemContainerViewDelegate {
  
  func itemContainerView<T: Item>(itemContainerView: ItemContainerView<T>, didSelectItem item: T?)
  
}

class ItemContainerView<T: Item>: UIView {
  
  var delegate: ItemContainerViewDelegate?
  
  func onTap() {
    
    // error: cannot convert value of type ItemContainerView<T> to expected argument type ItemContainerView<_>
    delegate?.itemContainerView(self, didSelectItem: nil)
    
  }
  
}

delegate?.itemContainerView(self, didSelectItem: nil) doesn't have any context of what T is. You want to use an associatedtype on the protocol and then constrain the view to guarantee that the Item types match:

import UIKit

protocol Item {  
  var title: String? { get set }
  var value: String? { get set }
}

protocol ItemContainerViewDelegate {
  associatedtype ItemType: Item

  func itemContainerView(itemContainerView: ItemContainerView<ItemType>, didSelectItem item: ItemType?)  
}

class ItemContainerView<T: Item, Delegate: ItemContainerViewDelegate where Delegate.ItemType == T>: UIView {
  var delegate: Delegate?

  func onTap() {
    delegate?.itemContainerView(self, didSelectItem: nil)
  }
}

@NachoSoto Nice, much better than what I was suggesting. 😶 Does the second generic type mean you have to use ItemContainerView as the (more verbose) ItemContainerView<MyItem, MyDelegate>, or can Swift infer that? Seems like it'd also limit re-assigning the delegate to another type, although that's not too common.

@grp Swift should be able to infer this in most contexts

Seems like it'd also limit re-assigning the delegate to another type, although that's not too common.

Right. I'm not sure why you want a generic delegate in the first place, isn't the whole point to talk to myProtocol only...?

cc: @b3ll

Basically I want to create a suite of views and delegates that are all type constrained to whatever they're associated with. @NachoSoto's suggestion looks more verbose, but it might work! :D

I'm not sure if actually implementing that function on another class will be quite as nice tho… lemme try

Actually it looks like @NachoSoto's suggestion won't work :(

protocol ItemContainerViewDelegate {
  associatedtype ItemType: Item

  // We need to declare ItemContainerView here as ItemContainerView<ItemType, Delegate> but that'd be referencing itself
  func itemContainerView(itemContainerView: ItemContainerView<ItemType>, didSelectItem item: ItemType?)  
}

// We need to declare ItemContainerView here as ItemContainerView<ItemType, Delegate> but that'd be referencing itself

@b3ll Oh yeah, I forgot about that. You could do type erasure, but I don't know if it's worth it. Do you really need to pass the entire ItemContainerView?

@NachoSoto well the cocoa way to do delegates is to pass back the original object that's firing the delegate, so without that it's not as useful. i.e. tableView:deselectRowAtIndexPath:animated:. I suppose I could pass back the index of the object, but that wouldn't be as nice than the object itself.

I'm not sure if type erasure is possible at this point, anything other than this I've tried has just lead to the compiler complaining about associatedtype dependencies :/