<div dir="ltr">In reply to:<div><p style="font-size:13px">Why would you want to add all of these different formats where only one could serve them all. This is redundant in my opinion. </p><p style="font-size:13px">`struct&lt;&gt;` and `enum&lt;&gt;` would have same rules, only the first element would be a different value-type. I might consider this as an alternative.</p><p style="font-size:13px">Correct me if I’m wrong with the redundancy.</p><p style="font-size:13px"><br></p><p style="font-size:13px">&#39;enum&lt;&gt;&#39; might be valid, unless their functions (e.g. for &#39;init(rawValue: Int)&#39; or &#39;allCases&#39;) are declared in explicit protocols which would implicitly cover enums and which other types could declare conformance to.</p><p style="font-size:13px">&#39;struct&lt;&gt;&#39; does seem redundant unless it becomes subtypeable. If you want a struct which conforms to several protocols, protocol&lt;&gt; already covers this. I know there&#39;s a discussion at the moment regarding the equivalent of an &#39;AnyObject&#39; for value types, which might apply to this discussion, but I&#39;m not sure how.</p><p style="font-size:13px">A class in general would also a protocol&lt;AnyObject, ...&gt;. The benefit of &#39;type&lt;&gt;&#39; is in its ability to extend the behaviours of several subclasses at once, e.g. type&lt;UIViewController, UIScrollViewDelegate&gt; covers all view controllers with scroll views, not just UITableViewController, UICollectionViewController, etc..</p><p style="font-size:13px"><br></p><p style="font-size:13px"><br></p></div>​</div>