```swift struct Container { var element:Element } ``` Previously, we saw how to constrain a generic parameter to a single protocol. Suppose we'd like it to conform to multiple protocols? ```swift protocol AProtocol { } protocol BProtocol { } class Container { var element:Element init(element:Element) { self.element = element } } struct SomeType : BProtocol, AProtocol { } var someInstance = Container(element: SomeType()) //Generic parameter `Element` could not be inferred. ``` We can't just add a comma and a second protocol name, because the compiler thinks it's a second generic parameter. ```swift class Container where Element : BProtocol { var element:Element init(element:Element) { self.element = element } } var someInstance = Container(element: SomeType()) //Ok ``` We need to add a `where` clause. The `where` clause expresses "generic constraints". There are two fundamental kinds of generic constraints. We've looked at "conforming" constraints. There are also "same type" constraints, and we'll more of them next week. Let's use a conformance constraint in an extension. ```swift protocol CProtocol { var specialValue:Int { get } } struct SomeCType : AProtocol, BProtocol, CProtocol { var specialValue:Int = 3 } extension Container where Element : CProtocol { var specialValue:Int { return element.specialValue } } var containedc:Container = Container(element:SomeCType()) containedc.specialValue //3 var containedb:Container = Container(element:SomeType()) containedb.specialValue //compile error ``` We've written a method on a `Container`, which only exists when the elements also conform to `Protocol`. Just imagine all the contextual code we can write now! ### No Conditional Conformances ```swift class Container : BProtocol where Element : BProtocol { //compile fail var element:Element init(element:Element) { self.element = element } } ``` What we'd love to do at this point, is declare that `Container` also conform to `BProtocol`, only when its `Element` type does. That's called a conditional conformance. Swift 3 does not support conditional conformances. In Swift 3, a generic type either does or does not conform to a protocol regardless of which types are used as its parameters. Protocol conformance is explicitly declared by we developers, and enforced at compile time. I know what you're saying, "Why not? If the compiler can figure out that the instance conforms enough to call the method, why can't it also decide that the protocol is conformed to?" Technically, it has to do with the way protocols are stored, vs. the way to compiler picks members from extensions. The good news is conditional conformances have been accepted for a future version of Swift. ## Limitations on Downcasting Generics ### Downcast to concrete types If a generic has been hidden behind an `Any` or an `AnyObject` we can perform conditional down casting to restore the exact concrete type. ```swift let any:Any = Container(element:SomeType()) if let containedSome:Container = any as? Container { print("success!") //success! } ``` In this example, the `Container` type gets hidden by the `any:Any` variable. The conditional downcast correctly restores it. If a generic parameter is a class, we can't even perform a downcast to that parameter's super-type. ```swift class SomeClass : AProtocol { } class SubClass : SomeClass { } let any:Any = Container(element:SubClass()) if let containedSome:Container = any as? Container { print("success!") // no go } ``` In this example, conditional down casting to a `Container` does not work, because the actual type is a `Container`. ### Cannot downcast to protocol as generic parameter However, we cannot downcast to a type where a protocol takes the place of a generic parameter, even if the protocol was the original generic parameter constraint. ```swift if let containedSome:Container = any as? Container { //compile fail print("success!") } ``` Obviously, we won't be designing our code to need this behavior. ### Problems with `AnyObject` Since `AnyObject` is also kind-of a protocol, we can't down-cast to it either. ```swift if let containedSome:Container = any as? Container { //compile fail print("success!") } ``` If we needed to preserve type information of the generic parameter, apparently we should have written our function which returns the generic instance to itself be a generic which preserved the parameter type information. ## When to use generics This limitation became a good reminder that when designing interfaces, if our dependencies may be accessed from outside, we should consider a generic instead of just a protocol. Since generics carry concrete type information from instantiation to property access, and from method arguments to return types, we should probably use generics wherever these things might need to happen. ## Naming Generics Last, let's talk about naming. When we name the generic parameters, we should use the usefulness of the type as the name. ```swift //declaration of an array public struct Array : RandomAccessCollection, MutableCollection { public subscript(index: Int)->Element public var first: Element? { get } ``` Here's a fragment of the declaration of an `Array`. Notice that there really is a `struct` type named `Array`. It has a generic parameter, `Element`. All of the functions and computed properties which return instances of the elements use the generic parameter so their access will be type-safe. The name `Element` conveys the purpose of this generic parameter. Similarly, `Optional`s are also real types, in this case an `enum`. ```swift public enum Optional : ExpressibleByNilLiteral { case none case some(Wrapped) ``` It has two cases. One is `.none`, which is the same as `nil`, and the other is `.some`. The associated value of `.some` is the generic type we "wrapped" in the `Optional`. Thus the generic parameter name `Wrapped` conveys how the type is used. ## Summary Today we learned how to write constraints on generics for multiple protocols. We learned how to provide additional functionality on a generic by further constraining its parameters to another protocol. We learned that conditional conformances are not yet possible. We saw that we can downcast to generics with concrete parameters, but have lots of trouble when downcasting to protocols. Last, we learned how to name generic parameters, and saw examples built-in to Swift. Providing additional behavior on generics with specific types? Now that's Swift!