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

[Joe Groff]

> On Feb 29, 2016, at 11:28 PM, Rasmus Kjeldsen <rasmus.kjeldsen at gmail.com> wrote:
> 
> 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?

Not every protocol type is a natural model of the protocol it represents. When a protocol has `static` or `init` requirements, for instance, the protocol type can't conform to its own protocol, since it's an abstract type with no type-level implementations of its own. Contravariant `Self` and associated type constraints are also problematic. Furthermore, in our resilience model, public protocols are allowed to add new requirements in future versions that cause a formerly self-conforming protocol to no longer conform. For these reasons, we really need the ability to explicitly declare that a protocol type is intended to be usable as a model of its own protocol.

> 
> protocol P {}
> 
> extension P {
> 	static func a() {}
> }
> 
> extension protocol <P> {
> 	static func b() {}
> }
> 
> class C : P { }
> 
> C.a() // ok

Yeah.

> C.b() // ok or not allowed?

Good question. The type object `C.self: C.Type` is a subtype of `P.Type`, so one could argue that this should be allowed by implicit up-conversion.

> P.a() // not allowed

Yeah.

> P.b() // ok

Yeah.

> 
> 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?

Yeah, in that case `extension P` is extending all types that conform to P.

-Joe

> 
> Regards
> Rasmus
> 
>> On 28 Feb 2016, at 02:05, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Rasmus Kjeldsen via swift-evolution
>> <swift-evolution at swift.org <mailto: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 <mailto: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/0e01ed25/attachment.html>