> On Jan 18, 2017, at 12:10 AM, Anton Zhilin via swift-evolution > <[email protected]> wrote: > > There is also a caveat with static members: > > protocol P { > static func foo() > } > > struct S : P { > static func foo() { } > } > > func bar<T: P>(x: T) { > T.foo() > } > > let p = S() as P > bar(p) // P.foo() does not exist
Right, part of the language design problem here is that not every protocol type is naturally a model of its protocol. In addition to static members, if you have any "Self" arguments in your method requirements, you wouldn't naturally be able to use those requirements, which expect a specific type modeling the protocol, on the type-erased protocol type. For many protocols, there's an obvious generalization—to compare two Equatables, first check that they're the same type, then call the == on the values of that type; for factory protocols with initializer requirements, there may be a reasonable default implementation type to provide if you ask to construct a P(). We'd want a way to provide that self-conformance if it doesn't fall out naturally from generalizing the protocol requirements. -Joe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
