<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Fully agree with Kevin here. I would <i>really</i> hate to see final as the default for classes/methods. In addition to subclassing just to add custom behavior, everyone writes bugs, and sometimes (unfortunately) the clients of an API have no choice to fix the bugs besides subclassing and fixing them themselves. Additionally, it would be significantly harder (IMO) for newcomers to grasp the concept when subclassing is limited to certain classes but not others. If you actually need that performance gain, you can easily add the final yourself.</div><div><div><br></div><div>It is true that “it is not uncommon to have a need for a reference type without a need for inheritance”. However, that does not mean this should be the default, IMO. So while I agree in theory it would be nice, in practice I don’t want to prevent potential clients of Swift APIs from accomplishing their goals in the easiest way possible.</div></div><div><br></div><div><br>On Dec 7, 2015, at 11:21 AM, Kevin Lundberg via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><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>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=R83Kt0gRLonfxLfvm7HjfBLbNxx0bjwcHwRgJKRSCf2a7eQiUPgANaIaqpimUOqCxetZYXP5Y-2F0-2BYGk14C271quo6x7yzk-2BJoULD6rlS7Rb6zP0uiIesbPIjFvkdjwdODCOnHnrjmohd9CHjSr2c2lhVHl6E-2BomvupwPZ6Ae-2BLWb3zR5-2B8HDCmXa1nOvECgXAFQjj09QS-2FpB3muejhS6U1Zz06yDwFN6rBCbQDE7pTk-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>