<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="">On Dec 10, 2015, at 6:04 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><div><blockquote type="cite" class="">To mitigate these issues, I'd like to float the idea that protocol conformances *not be* inherited by default. If you declare a class as conforming to a protocol, only exactly that class can be bound to a type parameter constrained by that protocol:<br 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><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">protocol Runcible {}</div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">class A: Runcible { }</div><div class="">class B : A { }</div><div class=""><br class=""></div><div class="">func foo<T: Runcible>(x: T) {}</div><div class=""><br class=""></div><div class="">foo(B()) // calls foo with T == A</div><div class=""><br class=""></div></blockquote><div class="">Since subclasses are still subtypes of the base class, in many cases client code won't have to change at all, since derived instances can implicitly upconvert to their conforming base class when used in protocol types or generics that only the base class conforms to. </div></div></div></blockquote></div><br class=""><div class="">Very interesting approach, I think I like it. That said, this is subtle enough that we’d probably have to prototype it to see what falls out in practice on existing real world code.</div><div class=""><br class=""></div><div class="">-Chris</div></body></html>