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
···
On Jan 18, 2017, at 12:10 AM, Anton Zhilin via swift-evolution <swift-evolution@swift.org> 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