<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Am 04.06.2016 um 23:18 schrieb Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello Dan,<div class=""><br class=""></div><div class="">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): <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-</a></div><div class=""><br class=""></div><div class="">However, it's unlikely that protocols will gain conditional conformance: <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-via-protocol-extensions" class="">https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-via-protocol-extensions</a></div></div></div></blockquote><div><br class=""></div>"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.“</div><div><br class=""></div><div>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</div><div><br class=""></div><div>protocol P { func foo() }</div><div>protocol Q { func bar() }</div><div>extension Q : P { func foo() { bar() } }</div><div><br class=""></div><div>we could have written the allowed</div><div><br class=""></div><div><div>protocol P { func foo() }</div><div>protocol Q : P { func foo() { bar() } }</div><div class=""><br class=""></div></div><div>with the exact same effect.</div><div><br class=""></div><div>The only difference would be that the extension might have been in another module than Q. </div><div>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?</div><div><br class=""></div><div>-Thorsten</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 4, 2016, at 2:12 PM, Dan Zimmerman via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hey,<br class=""><br class="">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:<br class=""><br class="">```<br class="">extension CollectionType: Equatable where Generator.Element: Equatable {}<br class=""><br class="">func ==<Collection: CollectionType where Collection.Generator.Element: Equatable>(left: Collection, right: Collection) -> Bool {<br class=""> return zip(left, right).reduce(true) { accumulator, tuple in accumulator && (tuple.0 == tuple.1) }<br class="">}<br class="">```<br class=""><br class="">If this has already been proposed and knocked out/accepted please direct me to the right place.<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>