[swift-evolution] Will existentials ever conform to their protocols?

[Joe Groff]

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

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