<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><blockquote type="cite"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">There's a refinement of this idea we've discussed internally in the past. Instead of making classes final by default, we could make it so that public classes are not subclassable from other modules by default.</span></font></blockquote><div id="AppleMailSignature"><br></div>This would be much better than current behavior, but I still favor final by default. I really believe inheritance and overridability is part of an API contract that should be explicitly stated in code even for code within a module. This enhances readability, encourages thoughtful design, and prevents unintentional interfaces.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">There is one really interesting aspect of this idea though. It would allow public classes to be subclasses internally, but not outside the module. Restricting the ability to inherit and / or override to a specific access control scope might be extremely useful. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I think we could have both - final by default as well as access restricted inheritance and overriding.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"><br>Sent from my iPad</div><div><br>On Dec 7, 2015, at 1:19 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span><br><blockquote type="cite"><span>On Dec 7, 2015, at 11:12 AM, Javier Soto via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>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:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>"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."</span><br></blockquote><span></span><br><span>There's a refinement of this idea we've discussed internally in the past. Instead of making classes final by default, we could make it so that public classes are not subclassable from other modules by default. Inheritance is manageable within a module, where all of the involved subclasses are revlocked and potentially have access to each other's implementations anyway, and the benefits of `final` and closed class hierarchy analysis are easy to recover with whole module analysis so don't necessarily need explicit calling out for internal interfaces. The problems with inheritance rear their head more with public interfaces, once code outside your control can subclass your classes.</span><br><span></span><br><span>-Joe</span><br><span></span><br><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>