<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=""><div class="">The problem is that this perpetuates the fundamental problem with type hierarchies: the further down the rabbit hole you go, the more fragile your types end up being. </div><div class=""><br class=""></div><div class="">I’d much rather design for inheritance rather than having it be opt-in by-default. I really like the inheritable only from within the module by default idea that Joe and Slava mentioned.</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Dec 7, 2015, at 11:21 AM, Kevin Lundberg 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=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">Resending to whole list:</div><div class=""><br class=""></div><div class=""><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">I can appreciate the desire for this, but I would not support it personally. In a former life developing C# code where this is the default behavior, I wanted to extend a class's behavior to make it work slightly differently, but since everything is final by default (sealed in C# parlance) I was prevented from doing so. The scope of my change was minimal and well defined, and it would not have negatively impacted the extending class's normal behavior. The code I was extending was open source so i ended up having to copy and paste the class and its dependencies into my project to do what I wanted. If I couldn't have done that then I'm not sure what the right approach would have been. </span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">In short, it is not always possible to know ahead of time how your clients will want to extend your API's functionality; artificially limiting this in my opinion will make it much harder to reuse components in previously unforeseen ways.</span></div><br class="">--<div class="">Kevin Lundberg</div></div><div class=""><br class="">On Dec 7, 2015, at 2:12 PM, Javier Soto via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="white-space:pre-wrap" class="">This was brought up in a different thread about private by default. Creating a new thread for this. Quoting Mathew from the other thread with a short summary about the motivation behind this:<br class=""><br class="">"It is not uncommon to have a need for a reference type without a need for inheritance. Superclasses should be intentionally designed to be subclasses and the author required to opt-in to subclassing and member overrides where that is required by the design."</div><div dir="ltr" class="">-- <br class=""></div>Javier Soto
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=AxVqvhl7qaAz-2FE20TrrgNT-2F44XdgxmRgRA416dJII-2BRlMUS99AeO-2Bu5B8C8pXRJNiR1-2B-2BHUgmO4ZcGgUue22WDgKd1nNotMU3dZ90bJfaTcNgUodcci9t7EAugJj6P-2F9D68127apMyjTVUgdHOhk-2BpI2QWa-2FPsOmf-2B7afLgMgemhUyhPC-2FwOXZJGiEK84pH7THLN8xxuFUd6BlAHznVxOVphtd0V5rLPMKrXsvRfk7Y-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=nE9rxSXA5G4kxsTVkgv43pXkLx-2B36P-2BPNJufHeY0dgcck-2FBiuYCaOBwLAa42DQO5fuTQKucECuCEJWaRonrVdxdszt6DNhKyPBy10ZCy2URMHMOUY23qoxW-2Bf1p41do1THCCqHvPVA3299Z9mqlfr2RoJZTx0zkFG4swoF-2FLU-2F98YlD892gyVVXpzMZpPksb6uKvZRf5UvlrtactlY3T1VkWhHXoa-2FbRffV-2BDpOEaYc-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</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>