[swift-evolution] [Proposal] Allow static protocol extension methods to be called directly on the protocol

[Rasmus Kjeldsen]

Maybe the “extension protocol <P>” syntax is more confusing than to just let protocol types implicitly conform to the static methods of their own protocol?
Below is an example of what I mean:

protocol P {}

extension P {
	static func a() {}
}

extension protocol <P> {
	static func b() {}
}

class C : P { }

C.a() // ok
C.b() // ok or not allowed?
P.a() // not allowed
P.b() // ok

And if C.b() is not allowed, what about if we also do:

extension P {
	static func b() {}
}
C.b() // ok?

Should that be allowed?

Regards
Rasmus

> On 28 Feb 2016, at 02:05, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Rasmus Kjeldsen via swift-evolution
> <swift-evolution at swift.org> wrote:
>> 
>> I propose to allow static protocol extension methods to be used directly on the protocol.
>> This would enable the Factory-pattern to be elegantly implemented as in the example below:
>> 
>> protocol P {}
>> 
>> class A : P {}
>> class B : P {}
>> 
>> extension P {
>> 	static func factory(type: Bool) -> P { return type ? A() : B()}
>> }
>> 
>> let a = P.factory(false) // <- Not possible in Swift 2, factory() can
>> only be used on either A or B
>> 
>> Regards
>> 
>> Rasmus Friis Kjeldsen
>> 
>> 
>> 
>> 
> 
> 'extension P' extends all types that conform to P. We could introduce a new
> syntax for extending the protocol type, maybe:
> 
> extension protocol<P> { ... }
> 
> This might be an important part of fleshing out our support for protocol
> existential types. It would offer a way for protocol types to conform to
> their own protocols even when Self or associated types make that normally
> impossible. 
> 
> -Joe 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160301/c7809277/attachment.html>