[swift-evolution] [Proposal] Conditional Conformance on Protocols/Generic Types

Thorsten Seitz tseitz42 at icloud.com
Sun Jun 5 02:49:56 CDT 2016


> Am 04.06.2016 um 23:18 schrieb Austin Zheng via swift-evolution <swift-evolution at swift.org>:
> 
> Hello Dan,
> 
> You'll be pleased to learn that conforming generic types conditionally to protocols is on the roadmap (and is one of the highest priority items for the versions of Swift following 3.0): https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances- <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances->
> 
> However, it's unlikely that protocols will gain conditional conformance: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-via-protocol-extensions <https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-via-protocol-extensions>
"However, similar to private conformances, it puts a major burden on the dynamic-casting runtime to chase down arbitrarily long and potentially cyclic chains of conformances, which makes efficient implementation nearly impossible.“

I’ve been wondering what the problem with the implementation is. I mean instead of using an extension the same conformance could have been declared beforehand, i.e. instead of

protocol P { func foo() }
protocol Q { func bar() }
extension Q : P { func foo() { bar() } }

we could have written the allowed

protocol P { func foo() }
protocol Q : P { func foo() { bar() } }

with the exact same effect.

The only difference would be that the extension might have been in another module than Q. 
Is having to cross module boundaries causing the cited problems? Would the same problems exist if in the second example Q would be defined in another module?

-Thorsten


> 
> That document originates from a mailing list post made some time ago, and is a decent overview as to what sorts of type system features the Swift core developers are interested in building.
> 
> Best,
> Austin
> 
>> On Jun 4, 2016, at 2:12 PM, Dan Zimmerman via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Hey,
>> 
>> I was interested in adopting the ability for a type that's generic in some sense (either via generics or via associated types, in the case of protocols) to conform to other protocols conditionally based on its type parameter/associated type. For example:
>> 
>> ```
>> extension CollectionType: Equatable where Generator.Element: Equatable {}
>> 
>> func ==<Collection: CollectionType where Collection.Generator.Element: Equatable>(left: Collection, right: Collection) -> Bool {
>>  return zip(left, right).reduce(true) { accumulator, tuple in accumulator && (tuple.0 == tuple.1) }
>> }
>> ```
>> 
>> If this has already been proposed and knocked out/accepted please direct me to the right place.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> 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/20160605/ed883af3/attachment.html>


More information about the swift-evolution mailing list