<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 14, 2016, at 11:39 PM, Chris Lattner 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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">To sum this all up, the core team is rejecting this proposal and requesting a revision to change the concrete syntax to “public open class Foo” instead of “subclassable class Foo". This approach satisfies the *<b class="">unwavering</b>* goal of requiring additional thought when publishing a class as public API, makes subclass-ability orthogonal to access control, and (admittedly as a bit of a swift-evolution process hack) asks the community for an in-depth discussion of the secondary points of the proposal: does it make sense to require every member to be marked as “overridable” in order to be overridden by an open subclass outside of the current module?</div></div></div></blockquote><div><br class=""></div><div>+1 on open instead of subclassable.</div><div><br class=""></div><div>As per the overridability I'm coming back and forth. There are certainly classes where you want just a few things to be overridable and then there are classes where you want almost everything overridable.</div><div><br class=""></div><div>I would personally prefer not overridable by default, but also an addition of a modifier on open that would allow to specify default overridability:</div><div><br class=""></div><div>// by default everything is overridable</div><div>open(override) class Bar</div><div><br class=""></div><div>Alternatives: open(members), open(all)</div><div><br class=""></div><div>This, however, requires a new keyword for "closing" a member within the module:</div><div><br class=""></div><div>// Not allowed overriding beyond the module.</div><div>closed func foo()</div><div><br class=""></div><div>BTW I'm not a fan of the keyword "overridable" at all. Imagine that you subclass the class in another module, override the method and expose it for yet another module and keep the overridability:</div><div><br class=""></div><div>overridable override func foo()</div><div><br class=""></div><div>I'd prefer the open keyword to be reused here.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><div class=""> -Chris</div></div><div class=""><br class=""></div></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=""></blockquote></div><br class=""></body></html>