<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Resending to whole list:</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><div><span style="background-color: rgba(255, 255, 255, 0);">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 id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);">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>--<div>Kevin Lundberg</div></div><div><br>On Dec 7, 2015, at 2:12 PM, Javier Soto via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div style="white-space:pre-wrap">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><br>"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">-- <br></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;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>